SSL certificate expiry explained

The dates that matter

A certificate has a start time and an expiry time, commonly represented as Not Before and Not After. A certificate should only be accepted while the current time falls inside that validity period and the rest of the validation checks also succeed.

Expiry is therefore only one part of certificate health. The hostname, trust chain and server configuration matter too.

Check the certificate the server is actually presenting

It is possible to renew a certificate successfully but leave an older certificate active on a load balancer, reverse proxy or another edge server. The useful check is therefore the live TLS connection, not just the certificate file sitting on disk.

For hosts that use Server Name Indication, the hostname supplied during the TLS handshake also matters because one IP can serve different certificates for different names.

Hostname coverage and SANs

Modern certificates list valid hostnames in the Subject Alternative Name extension. A certificate can be unexpired and trusted but still fail for a particular hostname if that name is not covered.

Wildcard names also have specific matching behaviour. For example, a wildcard for *.example.com does not automatically cover every deeper hostname level.

What to check before an expiry date

1. Renew early enough. Leave time to handle validation or deployment problems.
2. Deploy everywhere. Check each relevant edge, proxy or service endpoint.
3. Verify hostname coverage. Make sure the renewed certificate contains the names clients use.
4. Check the chain. The server should provide the certificate chain clients need to establish trust.
5. Retest from outside. Confirm the public service is presenting the expected replacement.