Why is my site still not HTTPS? Certificate problems, in order

The symptom: your host promises free automatic HTTPS, and hours later the browser still warns, or the certificate simply never appears. Certificate issuance is a robot verifying control of your domain — and robots are literal. When it fails, it is almost always one of five things, in this order of frequency.

Likely causes, most common first

1. DNS is not actually pointing yet (the most common by far): certificate authorities verify domain control by resolving your hostname. If DNS has not propagated — or resolves to the wrong place — issuance cannot start. No amount of host-side retrying fixes a record that does not answer; fix DNS first (the DNS diagnostic), and issuance usually follows on its own.

2. You are looking at the wrong name (common): a certificate that covers example.com does not automatically cover www.example.com (or vice versa). The browser visiting the uncovered variant sees a name-mismatch error while the other variant works perfectly.

3. A CAA record blocks your issuer (occasional and confusing): CAA records name which certificate authorities may issue for the domain. If one exists and your host's CA is not on the list, issuance fails with an error that mentions authorization, not CAA — unless you know to look.

4. Mixed content (very common, and not an issuance problem at all): the certificate is fine, but the page loads images or scripts over http://, so the browser still flags it "Not secure". The padlock tests the whole page, not just the connection.

5. Issuance delay or rate limits (occasional): brand-new hostings can take a little while to request and receive certificates; authorities also rate-limit repeated failed attempts — hammering "renew" can make things worse.

Diagnosis, safely

Click the padlock (or the warning) and read the certificate detail: the browser tells you whether the cert is missing, expired, or for a different name — three different diseases. Then check the domain with an online SSL checker or openssl s_client -connect yourdomain.com:443 to see what is actually being served. Confirm DNS answers first — certificate robots check it the same way. Search the domain's DNS for CAA records before suspecting the host.

The fix, in the honest order

DNS answers correctly → both variants (apex and www) covered by the host's certificate settings → CAA records either removed or listing your host's CA → trigger issuance once, then wait the provider's stated window → if the padlock still complains, audit the page for http:// resources (the browser console lists every one) and fix those references. On this very site, the managed certificates issued without drama precisely because DNS was verified first — the boring order is the fast one.

When this fix will not work

Hosted names that cannot get public certificates (internal .local-style names); free hosting tiers with per-domain issuance limits; and browser-trust problems on very old devices — where the certificate is valid but the device's trust store is a decade stale. The last one is the environment's problem, not yours.

Official documentation (checked 11 September 2026): Let's Encrypt's docs on rate limits and CAA (letsencrypt.org/docs), MDN on mixed content (developer.mozilla.org), and your host's certificate/HTTPS reference. For what the certificate actually asserts, see what SSL/TLS and HTTPS really are; for the errors browsers show, certificate errors, explained.