Overview

Before requesting a TLS certificate from Let's Encrypt, your domain must resolve to the public IP address of your Oracle Cloud VM. Let's Encrypt performs an HTTP challenge to verify that you control the domain, which requires DNS to be correctly configured first.

Before you begin

Replace all occurrences of example.com and 203.0.113.10 in this guide with your own domain name and the actual public IP of your Oracle VM.

Create DNS Records

Log in to your domain registrar or DNS provider and add the following records.

TypeHost / NameValueTTL
A@ (root domain)203.0.113.10 (your VM IP)300–3600
CNAMEwwwexample.com300–3600
Remove parking records first

Many registrars pre-configure parking A records or CNAME records that redirect to their own servers. Delete all existing A and CNAME records before adding your own to avoid conflicts.

Verify DNS Resolution

After saving your records, use the following commands to check whether the domain resolves correctly. You can run these from any Linux machine.

bash
dig +short example.com

host example.com

nslookup example.com

All commands should return the Oracle VM public IP address.

Verify HTTP Access

Once DNS resolves correctly, confirm that Nginx is serving requests for the domain over HTTP.

bash
curl -I http://example.com

A successful response will return an Odoo login page (HTTP 200 or 303 redirect). If you get a connection timeout, check the firewall configuration in Chapter 8.

DNS Propagation

DNS changes are not instant. After you save your records, it can take anywhere from a few minutes to several hours for the changes to propagate across all resolvers.

DNS ProviderTypical Propagation Time
CloudflareUsually < 1 minute
Google Cloud DNSUsually a few minutes
Route 53 (AWS)Usually a few minutes
Generic registrar DNS15 minutes – several hours
Local ISP resolversUp to 24 hours (due to TTL caching)
Do not request a certificate until DNS propagates

If you run Certbot before DNS is correct, the ACME challenge will fail. Let's Encrypt enforces rate limits, and repeated failures can temporarily block you from requesting certificates for the same domain.

To test using a specific resolver (bypassing your local cache):

bash
dig @8.8.8.8 +short example.com

dig @1.1.1.1 +short example.com

Common Issues

SymptomLikely CauseResolution
Registrar parking pageOld default DNS records still activeDelete the registrar's default A/CNAME records and wait for TTL to expire
404 or wrong site from NginxIncorrect server_name in NginxVerify server_name matches your domain exactly, then reload Nginx
Connection timeout on port 80Firewall blocking HTTPOpen TCP 80 in the Oracle Security List and in iptables (see Chapter 8)
Different IP on different devicesCached DNS responseWait for TTL to expire, or test via dig @8.8.8.8
Back to top