Your Domain Resolves and HTTPS Still Fails

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

You pointed the record. dig returns the right answer. http:// loads. And https:// gives you a certificate warning, a 525, or nothing at all.

DNS propagation and certificate issuance are two different clocks, and the second does not start until the first has finished. A certificate for your hostname cannot be issued until requests for that hostname already reach the server that will hold it. "The DNS is correct" is not the end of the wait — it is the beginning of a second one.

Almost every stuck case is one of three things, told apart in about a minute.

Why a certificate cannot be issued early

A public certificate authority will not take your word that you control a name. The common proof is the HTTP-01 challenge: it asks for http://your-host/.well-known/acme-challenge/<token> and expects the token back, and that request has to arrive at the machine asking for the certificate.

So the order is fixed: the record points, the request arrives, the challenge passes, the certificate exists, https:// works. Anything done before the record resolves is waiting, not fixing.

One consequence catches people out: port 80 has to stay open and answer. A redirect from HTTP to HTTPS is fine — authorities follow them — but refusing plain HTTP, or blocking /.well-known/ at a firewall or an auth layer, removes the road the challenge travels on.

The three states, and how to tell which you are in

1. Not resolving yet. Nothing else can be true until this is. What you are waiting on is the TTL of the record you replaced — look that number up and it is your worst case, rather than treating propagation as weather.

2. Resolving, no certificate yet. http:// answers and https:// does not. The challenge is in flight or blocked. Give it a few minutes; if it stays, check that port 80 reaches you and that /.well-known/ is not behind auth, a firewall rule, or a catch-all route in your own application.

3. A certificate exists and it is the wrong one. The connection completes but the name on it is not yours. This state looks worst and is usually shortest to fix: something in front is terminating TLS and has not been told about this hostname.

The Cloudflare chicken-and-egg, specifically

A proxied domain has Cloudflare terminating TLS for the visitor and making its own connection to your origin. Its SSL/TLS mode decides what it demands of that leg, and one setting deadlocks on a first deploy.

Full (strict) requires a valid, publicly trusted certificate at the origin, and before first issuance there is not one. Cloudflare refuses the connection, the origin never sees the traffic, the challenge never completes, and the certificate that would satisfy Full (strict) is never created.

The way out is an ordering rather than a workaround: start on Full, and move to Full (strict) once the origin certificate exists. Full still encrypts the leg to your origin; it simply does not yet demand a trusted certificate on it. What you must not do is drop to Flexible, which fetches your application over plain HTTP — the padlock is then Cloudflare's alone and the traffic behind it is not encrypted.

Cloudflare forwards /.well-known/acme-challenge/ to the origin without redirecting it, which is why a proxied domain can get a certificate at all. It is the same property that makes proving a domain by request rather than by DNS lookup work through a proxy when a DNS check does not.

One script that tells you which state you are in

Save it as tls-state.sh. It asks the three questions in order, so the first failure is the one to act on.

#!/bin/sh
# usage: ./tls-state.sh app.example.com
H="$1"

echo "== 1. does it resolve? =="
dig +short "$H" || echo "no answer"

echo
echo "== 2. does plain HTTP answer, and is the challenge path reachable? =="
curl -sS -o /dev/null -w 'http           -> HTTP %{http_code} after %{num_redirects} redirect(s)\n' \
     -L --max-time 10 "http://$H" || echo "http: no answer"
curl -sS -o /dev/null -w 'challenge path -> HTTP %{http_code}\n' --max-time 10 \
     "http://$H/.well-known/acme-challenge/probe" || echo "challenge path: no answer"

echo
echo "== 3. what certificate is actually served? =="
echo | openssl s_client -connect "$H:443" -servername "$H" 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates 2>/dev/null \
  || echo "no handshake — nothing serves a certificate for this name yet"

How to read it. No answer at step 1 and everything after is noise. Step 2 failing while step 1 works means the challenge cannot reach you — port 80, a firewall, or your own catch-all route; a 404 on the challenge path is fine, connection refused or 403 is not. A subject at step 3 that is not your hostname means something in front is terminating TLS and does not know this name.

What to do while you wait

Nothing, mostly, and that is the useful advice. The common failure here is not a misconfiguration — it is somebody changing three settings in five minutes, each resetting a clock and none of them the problem. Change one thing, wait out the TTL you looked up, run the script again.

The wait is a good moment to settle what outlives it: who can actually open the address once it works, and whether your record will follow the host if it moves your application.

FAQ

Why does my domain work over HTTP but not HTTPS? Because the certificate has not been issued yet. Issuance requires that requests for the hostname already reach the server, so it can only begin after DNS resolves. HTTP working is the signal that a certificate can now be obtained, not that it already has been.

How long should certificate issuance take? Usually under a minute once traffic arrives, and it is worth waiting several before changing anything. If nothing has happened after that, the challenge is being blocked rather than being slow.

Does Cloudflare's proxy stop a certificate being issued? Only in Full (strict) before the first certificate exists, which is a deadlock: it demands a trusted origin certificate in order to pass the traffic that would create one. Start on Full and switch afterwards. Never use Flexible — it leaves the origin leg unencrypted.

Do I need port 80 open if my site is HTTPS-only? For an HTTP-01 challenge, yes. Redirecting port 80 to HTTPS is fine, because certificate authorities follow redirects, but refusing it outright removes the path the challenge uses. The alternative is a DNS-01 challenge, which proves control with a TXT record and needs no open port.

What happens on aidrop.it? The certificate is issued once requests for the name reach the cluster, so a hostname pointed a minute ago can take a few more before it answers over HTTPS. There is nothing to configure, and pressing verify again is safe.

Cover: https://commons.wikimedia.org/wiki/File:Manuscript_certificate_Wellcome_L0042065.jpg from the Wellcome Collection, CC BY 4.0, via Wikimedia Commons. Cropped to 16:9 within the original frame. Alt text: A handwritten manuscript certificate with a wax seal attached at its foot.