SSL Renewed but Still Expired? Fix It

Short answer: the renewal almost always worked, but the server answering visitors is still handing out the old certificate. The new file is on disk and the web server has not loaded it, or a CDN, load balancer or second server is serving a different copy. Ask the live server which certificate it presents, then reload the service or fix the layer that holds the old one.

How do I see which certificate the server is really serving?

Do not trust the hosting panel, which only shows what is stored. Ask the live server. From a terminal:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate -issuer

The output looks like this (your dates and issuer will differ):

notAfter=Jan 14 09:12:03 2027 GMT
issuer=C = US, O = Let's Encrypt, CN = R11

If notAfter is a past date, the server is serving the old certificate, whatever the panel says. If it is in the future, the problem is on the visitor's side or on a different hostname. Run it for both example.com and www.example.com, because they can be served by different virtual hosts with different certificates.

If you do not want to open a terminal, the domain and SSL expiry checker shows the same expiry date for any hostname.

Why does the old certificate keep showing after renewal?

What you see	Likely cause	Fix
New file on disk, old date live	Web server never reloaded	Reload nginx, Apache or the control panel service
Works on one hostname, expired on another	Separate virtual host or SNI entry	Point every vhost at the new files
Works for some visitors, expired for others	Several servers behind a load balancer	Deploy the certificate to every node
Site behind Cloudflare shows expired	Origin certificate expired, or edge certificate stuck	Renew the origin certificate, then check the edge one
Renewed but chain error	Only the leaf file installed	Install the full chain file

Renewal tools such as Certbot write new files into place but do not always restart the service that reads them. Certbot's documentation describes renewal hooks, including a deploy hook that runs a command after a successful renewal, which is the usual place to put the reload. Check the current docs for exact behaviour on your version.

What are the exact fix steps on a typical WordPress host?

Run the openssl command above and note the notAfter date.
Confirm the new certificate exists on the server. With Certbot, run certbot certificates and check the expiry it reports.
Check that the web server config points at the renewed files. For Let's Encrypt that is usually fullchain.pem and privkey.pem under /etc/letsencrypt/live/yourdomain/, not a copy made last year.
Test the config and reload: nginx -t && systemctl reload nginx, or the Apache equivalent.
On shared hosting or cPanel, confirm the certificate is installed for the domain, not just issued.
Run the openssl command again. The date should now be in the future.

What if the site is behind Cloudflare?

Visitors talk to Cloudflare's edge certificate, and Cloudflare talks to your origin. Cloudflare's SSL/TLS docs describe several encryption modes, and as I read them, Full (strict) validates the origin certificate, so an expired origin certificate can cause errors even when the edge certificate is valid. Their Origin CA page covers the origin certificate options. Renew the origin certificate first, then re-test the public hostname. If you changed nameservers recently, confirm the edge certificate shows as active for both the apex and www.

What if my browser still shows expired and the server is fine?

If openssl shows a valid date, the server is fixed. Try a private window, another device or mobile data. Some clients hold on to an old chain or lack a newer root, and a missing intermediate looks like an error in some browsers and not others. Also check the visitor's device clock, since a wrong date makes any certificate look expired.

Is there a real example of a renewed certificate still failing?

Yes, a public one. On 30 September 2021 the Let's Encrypt root certificate DST Root CA X3 expired. Let's Encrypt's documentation about that expiry says older devices that did not trust its newer root could show certificate errors, even though the sites had valid, freshly renewed certificates. That is the chain and old-client case in the table above. It was a public incident affecting many sites, not a quietwatch customer. The fix on a given site is to serve the full chain and to test with the openssl command, then with an older device if you can.

Can an expired certificate affect indexing and Search Console?

I have not found Google documentation saying an expired certificate alone removes a page from the index, so treat that as unconfirmed. What is documented is that Googlebot must be able to fetch a page to read its rules. Google's robots meta tag documentation describes noindex as a rule you can set in a meta tag or in an X-Robots-Tag HTTP header, and its robots.txt introduction describes robots.txt as the file that tells crawlers which URLs they may access. Its sitemap overview describes a sitemap as a way to tell Google which URLs you want crawled. If the certificate is broken, those fetches may fail too.

So after fixing the certificate, spend two minutes on the other silent causes. In Search Console, run URL Inspection on the home page and read the live test result. Then confirm there is no stray noindex tag, no X-Robots-Tag header from a Cloudflare rule, no blocking line in robots.txt, and that the sitemap still loads.

What should I tell the client?

Keep it short and factual: "The certificate was renewed, but the server was still presenting the old one until it was reloaded. It is fixed now and the new certificate is valid until [date]." Do not blame the client's host without evidence. Add the date of the next renewal so the client knows it is handled. Browsers put a full-page warning in front of an expired certificate, so visitors leave, and Google's Search Central guide, titled "Secure your site with HTTPS", recommends serving pages over HTTPS.

How does quietwatch catch this daily?

quietwatch looks at the certificate each of your client sites actually presents and warns you before the date arrives, which is the check behind what quietwatch checks every day. Because it reads the live certificate, it also catches the case where a renewal went through but the old one is still being served.

Where are the sources for these claims?

All posts · The fourteen checks

SSL certificate renewed but still showing expired? Here is why