SSL Certificate Expired: What Happens and How to Fix It
An expired TLS certificate causes clients to distrust the connection; renewal must be followed by verification that every public endpoint serves the new certificate.
How it works
Certificates have not-before and not-after validity dates. A browser warning can result from expiry, a certificate that is not yet valid, or a different certificate being served than the one you renewed.
A certificate is usable only between its not-before and not-after dates. An expiry warning commonly means the public endpoint still presents a certificate past not-after, but a device clock that is far wrong can also make a valid certificate appear expired or not yet valid. Read the exact error before assuming the renewal process failed.
Automation can fail before issuance or after it. ACME validation may not reach the expected host because DNS, HTTP routing, or a challenge path changed. A scheduled renewal job may lack permission, stop running, or write a new certificate that is never deployed to the web server. Treat renewal and deployment as separate checks.
Copies of a certificate can live on a CDN, load balancer, reverse proxy, and several application servers. Renewing one origin file does not guarantee every listener reloaded it. An old certificate on one edge can create intermittent reports when different users reach different infrastructure.
After renewal, inspect the public hostname for issuer, SANs, validity dates, and fingerprint. Compare that result with the newly issued certificate, then test every public listener and CDN configuration. If an old fingerprint persists, find the endpoint that serves it rather than requesting a succession of new certificates.
Expiry monitoring should warn early enough for ownership, renewal, and deployment checks. The checker provides a point-in-time public TLS observation; it does not monitor continuously, validate application content, or replace the certificate-management process for the service.
Why expiry errors persist
Automated renewal can fail because of an unreachable validation path, changed DNS, a stopped renewal job, or missing deployment permissions. A renewed certificate can still appear expired when a CDN, load balancer, proxy, or one backend continues to serve the old file.
A substantially incorrect client clock can also make a currently valid certificate look expired or not yet valid, though this is less common than a deployment issue. Check the exact browser error and the server certificate before changing configuration.
Renew and verify methodically
Renew through the certificate authority or the platform that manages the certificate, then deploy it to every listener and edge. Inspect the public hostname's issuer, dates, SANs, and fingerprint after the change. If results differ by network, check the CDN and DNS path rather than issuing repeated certificates.
Monitor expiry ahead of time and keep ownership of renewal alerts clear. A valid certificate is necessary for transport security but does not by itself prove the website or application is safe.
Practical guidance
- Check the public certificate dates before assuming renewal succeeded.
- Verify every CDN, proxy, and load-balancer endpoint.
- Investigate an incorrect local clock only after checking the served certificate.
Common question
Why is the warning still shown after renewal? A different public endpoint may still be serving the old certificate.