SSL Certificate Expired: How to Fix It

Diagnose the warning before renewing

A privacy warning is not always an expired certificate. Record the exact hostname and error, then check the certificate dates, hostname coverage, and chain. example.com, www.example.com, and api.example.com can serve different certificates.

Check the certificate actually served to visitors

Run the public SSL checker and read Valid until, hostname match, and chain validity. A timeout or failed handshake does not establish that the certificate is expired. In that case, investigate DNS, connectivity, and TLS configuration too.

With OpenSSL installed, the following command works in a POSIX shell such as Bash or WSL. Replace example.com in both places. SNI selects the certificate for that hostname; the output describes the leaf certificate, not the trust status of the entire chain.

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -issuer -serial -fingerprint -sha256

• notBefore is the start of validity; notAfter is the expiry timestamp. GMT here means UTC.
• Record the serial number or SHA-256 fingerprint so you can distinguish the old certificate from its replacement.
• If no certificate is returned, keep the connection error for diagnosis. Do not interpret empty output as a healthy result.

Example: reading an expired result

This is an illustrative result, not a live check of example.com. At the stated check time, notAfter is exactly two days in the past. The hostname can still match even though the certificate is expired; that does not make the connection valid.

Hostname:       example.com
notBefore:      Jul  5 12:00:00 2026 GMT
notAfter:       Oct  3 12:00:00 2026 GMT
Days remaining: -2
Hostname match: Yes
Expiry status:  Expired

Renew, deploy, and verify in that order

Use the system that owns this certificate. Avoid creating a second renewal process before you understand why the existing one failed.

1. Find the owner: managed hosting, CDN, load balancer, or an ACME client on your server. Review renewal logs for failed domain validation or deployment.
2. Renew or reissue through that owner. On managed hosting, use its certificate controls or support. On a Certbot-managed server, use its documented renewal workflow; renew --dry-run tests future renewal but does not install a production replacement.
3. Deploy the certificate with its matching private key and required intermediate certificates to every relevant TLS endpoint. Never upload your private key to a public checker or support message.
4. Validate the service configuration, then reload or redeploy as required by your platform. Confirm that the operation succeeded and the correct hostname is bound to the replacement.
5. Run an external check again. Confirm a future expiry date, hostname coverage, and a trusted chain; then check HTTPS responses and redirects without bypassing TLS verification.

Renewed certificate, but the website still shows the old one?

Compare the live serial number or fingerprint with the replacement. If they differ, renewal may have succeeded while deployment did not. Clearing an HTTP cache does not replace the certificate presented during a TLS handshake.

• Server or reverse proxy: check the configured certificate path and whether the reload succeeded. An updated file on disk may not be loaded by the running service.
• CDN: the visitor-facing edge certificate and the origin certificate are separate. Renewing one does not necessarily update the other; check the provider's deployment status.
• Multiple servers: verify each load balancer or TLS-terminating node. One node serving the old certificate can cause intermittent failures.
• DNS and IPv6: compare A and AAAA destinations. IPv4 and IPv6 clients may reach different deployments; after a DNS change, resolvers may still use the previous destination until its TTL expires.
• Only one device fails: check its clock, trust store, and any TLS-inspecting proxy. Compare the issuer and fingerprint with an external result before blaming the website certificate.

Verify the fix before closing the incident

For a command-line validation, use the command below in Bash or WSL. It checks hostname and certificate verification with your local OpenSSL trust store and stops on verification errors. A connection opening by itself is not proof of a valid certificate.

Also test from a browser or external checker. One successful connection only covers the endpoint reached at that moment; it does not prove that every region, IP address, or client trust store sees the same result.

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -brief </dev/null

• The public endpoint serves the expected replacement certificate with a future expiry date.
• The hostname matches, and chain verification succeeds without insecure overrides.
• HTTPS pages and each redirect target work. A broken TLS connection cannot be repaired by an HTTP redirect.
• The renewal failure is understood, and the deployment or reload step is included in future renewals.

Prevent the next expiry incident

Keep automatic renewal enabled, test it, and monitor the public endpoint independently. Assign a person or team to renewal failures and confirm that alerts reach a monitored inbox. A reminder is useful only if someone can act on it.

Website Certs is free during beta. Use a one-time SSL check to verify the repair, then add the domain to monitoring. Test notification delivery and review your monitoring schedule rather than assuming that account creation alone enables alerts.