/guides · /guides/renewed-cert-still-shows-old

The renewal ran, and the site still serves the old certificate

Before you clear anything in your browser, find out what the server hands a stranger. That single check decides whether you have a certificate problem or a cache problem.

Updated October 2026 · 5 min read

Check from outside first

Run an SSL certificate check on the hostname. It connects over TLS from somewhere that is not your machine, has no browser cache and no session with your server, and reports the certificate it was actually handed — issuer, validity window, covered names, and whether the chain is complete.

That gives you a clean split. If the checker shows the new expiry date, the renewal worked and the stale certificate is on your side: your browser is reusing a connection, or a corporate proxy sits in the middle. If the checker shows the old date, the server really is serving the old certificate, and nothing you do in your browser will change that.

Renewal is two steps, and only one of them ran

Issuing a certificate and serving it are separate operations. Your renewal client fetches a new certificate and writes it to disk, and that part is usually what succeeded — the file is new, the timestamp is right, and reading it locally shows the correct dates. The web server, meanwhile, read that file into memory when it started and has not looked at it since.

So the certificate on disk is new and the certificate being served is old, and both of those statements are true at the same time. That is the single most common cause, and the fix is to reload the service so it re-reads the file. A reload is enough; a restart is not required and drops connections.

The other three

If a reload did not change what the checker reports, work through these in order.

CauseHow it looksWhat to check

Not reloadedFile on disk is new, served is oldReload the web server, then re-run the checker

Serving a different fileReload changed nothingThe path in the server config, against the path the renewal writes

Something in frontOrigin is new, public is oldA CDN or load balancer holding its own copy of the certificate

One node of severalIntermittent, changes on refreshEvery node behind the balancer, not just the one you deployed to

The second one catches people who have changed setup at some point. Renewal writes to the path it was configured with, the server reads from the path in its own config, and if those drifted apart the renewal has been succeeding into a file nobody serves. Both sides print their path; compare them literally rather than from memory.

The third is the one that looks most like magic. If a CDN terminates TLS, the certificate the public sees is the CDN's, and renewing at your origin changes nothing visible. Check the certificate the CDN is serving in its own dashboard.

Why it is urgent even though it works

A certificate that is still valid for a week is not a warning, it is a deadline. There is no grace period: at the expiry moment browsers refuse the connection with an interstitial most visitors will not click through, and automated clients — payment callbacks, webhooks, mobile apps — simply stop. What TLS is doing covers why the failure is total rather than gradual.

This is also why automated issuers renew at thirty days rather than at the last minute. The margin exists so that a fortnight of silent failures costs you nothing, and the only thing that spends it is not noticing.

Once it is fixed, the check worth keeping is the one you just ran: an external look at the expiry date, on a date you choose rather than the one your renewal client believes in. A renewal that runs and is never served looks exactly like a renewal that works, right up until it does not.