SSL renewal failed: diagnose before you retry

A free certificate renews by itself, with nobody clicking anything. When it expires anyway, the spontaneous conclusion is that the automatic service has failed. That is rarely true. Renewal is not an action by the host: it is a dialogue between the certificate authority and your domain, repeated at every expiry, and it succeeds only if the domain answers the way it did the first time.

But a site changes over time. Someone switched DNS servers, added a redirect rule in the .htaccess file, enabled a web application firewall, put the domain behind a CDN or published a CAA record. Each of these moves is legitimate, and each can block validation while the site keeps displaying normally. The error shows up weeks later, at expiry, far from the change that caused it. Retrying issuance without fixing anything only produces the same failure. You need to read the signal, find the condition that moved, restore it, then retry once.

To issue or renew a certificate, the authority must make sure that whoever asks controls the domain. It proceeds in four steps, and the failure is always in one of them.

First, it resolves the name: DNS must answer and return the address of the right server, over IPv4 as well as IPv6. Then, with file validation, it requests http://your-domain.com/.well-known/acme-challenge/ on port 80 and expects the exact content placed by the ACME client. Third, it looks up the domain's CAA records to check that none forbids it from issuing. Finally, it follows any redirects, but rejects an error response or a blocking page.

This sequence explains the diagnostic tree: does the domain point to the right server, is the challenge reachable, does a redirect or a firewall intercept it, does a CAA record exclude the authority, is a proxy in a compatible mode. The next steps test these five points in that order.

This is the most frequent cause, and the quietest. After a migration, a change of host or a zone cleanup, the domain keeps displaying thanks to the cache or a correct A record, while an AAAA record still points to the old server. The authority prefers IPv6 when it exists: it queries the old machine, which no longer knows the challenge file, and validation fails even though everything looks fine from your computer.

The check is simple: compare dig +short A your-domain.com and dig +short AAAA your-domain.com with the real address of the server. If you do not use IPv6, delete the AAAA record rather than leaving it pointing elsewhere. Also check that the domain uses the name servers where you just fixed the zone; the procedure for editing a record is detailed in the guide on adding or modifying a DNS record. Then wait for the caching delay announced by the old value to elapse before retrying.

The challenge is an ordinary HTTP request that the authority sends from its own servers. Anything that answers in its place, or answers something other than the expected file, makes validation fail. Three setups regularly cause the problem.

The first is the redirect that changes domain: a rule sending all traffic from your-domain.com to another address, including the challenge path, sends the authority looking for the file on a site that does not have it. The second is the security rule that refuses files whose name starts with a dot: it protects .env or .git, but it also blocks .well-known. The third is the web application firewall or the country filter, which treats the authority as an unknown visitor and answers 403.

The fix is not to disable protection, but to exclude precisely the /.well-known/acme-challenge/ path from redirect and blocking rules. A redirect from HTTP to HTTPS remains acceptable, as long as it keeps the requested path and ends on the same domain.

A CAA record is an allow list published in DNS: it lists the authorities allowed to issue for the domain. It is a good security tool, but it goes stale silently. Someone publishes 0 issue "an-authority.example" during an audit, then the hosting moves to another authority, or AutoSSL changes provider, and issuance is refused with a message that mentions CAA.

To fix it, read the result of dig CAA your-domain.com +short, identify the authority your service uses (on cPanel, the Issuer column of the SSL Certificates page), then add an issue line with its name. If you do not need this restriction, delete the record. Remember that a CAA is read by walking up the tree: the main domain's record applies to subdomains. And for a certificate covering a wildcard subdomain, a separate issuewild line may be needed.

Putting a domain behind a CDN in proxy mode changes what the authority sees. It no longer talks to your server but to the CDN's, which may answer in your place with an edge certificate, a verification page or its own security rule. Depending on the mode chosen, renewal of the origin certificate works or does not.

Two settings matter. First, the encryption mode between the CDN and the origin: in flexible mode, the CDN talks to the origin in clear text, which causes a redirect loop if your server forces HTTPS; in strict mode, it requires a valid origin certificate, so an expiry becomes visible at once as an origin error. Second, the protections active on the challenge path: they must be lifted for /.well-known/acme-challenge/, or you can switch to validation by DNS record, which does not depend on web traffic. During diagnosis you can also temporarily disable the proxy on the single record concerned, retry issuance, then re-enable it.

A failing renewal almost always means that a validation condition has changed: the name no longer points to the right place, the challenge path is blocked or diverted, an authority is excluded, a proxy has slipped between it and the server. The reading order is constant: DNS resolution, access to port 80, response on the challenge path, CAA record, proxy mode. Once the cause is restored, a single retry is enough. ServOrbit.com web hosting includes free SSL renewed automatically; when validation fails, the cause can be read in the AutoSSL log and fixed with the commands above.