SSL certificate expiry explained

What does certificate expiry mean?

Every TLS certificate (still commonly called an SSL certificate) carries two dates: not before and not after. A browser connecting to your site checks that the current time falls between them. Outside that window the certificate is invalid, regardless of whether the private key is secure or the domain still belongs to you. There is no grace period and no partial failure: at the expiry time, HTTPS connections start failing everywhere at once.

Validity periods have become shorter over the years; certificates from automated authorities are typically issued for around ninety days, and the industry is moving towards shorter lifetimes still. That is good for security, but it means renewal happens often and a broken renewal process bites quickly.

The result is not a subtle error: browsers show a full-page warning, and most API clients, mobile apps, webhooks and partner integrations fail outright at the same moment.

Chain and hostname validation

Expiry is only one of several checks a client performs. A certificate is trusted because it is signed by an intermediate certificate, which is in turn signed by a root that the client already trusts. This is the certificate chain. If the server sends the wrong intermediate, omits it, or the intermediate itself has expired, clients cannot build a path to a trusted root and reject the connection even though the leaf certificate is current.

Hostname validation checks that the name the client connected to appears in the certificate's subject alternative names. A certificate for www.example.com does not cover example.com or api.example.com unless those names are listed. Hostname mismatches typically surface after a migration, a new subdomain, or a load balancer that serves the wrong certificate for a given name.

A thorough certificate check therefore verifies three things: that the chain validates to a trusted root, that the hostname matches, and how many days remain before the leaf certificate expires.

Why 30, 14 and 7-day reminders matter

A single alert at expiry is useless, because by then the outage has already begun. Reminders need to arrive early enough to act, and more than once in case the first is missed. A thirty-day warning leaves time to re-issue a certificate through a slow process, raise a ticket with a provider, or discover that the person who set up renewal has left. A fourteen-day warning confirms the problem has not been fixed and is past the point at which automated renewal should have succeeded, since ACME clients typically renew with about thirty days remaining. A seven-day warning is urgent, and alerts at three days and one day are the last chance before the site breaks.

The escalating schedule also separates routine renewal from a missed one: if the day count keeps falling past the point where it should have reset, something is wrong.

How automated renewal can still fail

ACME clients such as Certbot and the built-in renewal in many web servers and load balancers have made expiry much rarer, but automation is not a guarantee. Common failures include:

• The renewal job never runs: the cron entry or systemd timer was lost in a rebuild, or the container that ran it was replaced.
• The domain validation challenge fails: a firewall or redirect blocks the HTTP challenge path, or the DNS API credentials used for a DNS challenge expired.
• Renewal succeeds but the new certificate is never deployed: the web server or load balancer is not reloaded, or the file is copied to the wrong place.
• The certificate was issued manually once, long ago, and automation was never set up for that particular hostname.
• A wildcard or multi-domain certificate is renewed without one of the names it previously covered.

How MoniterMySite handles this

MoniterMySite has a dedicated SSL certificate monitor that reads the certificate on a hostname, records the issuer, subject and expiry date, and reports the number of days remaining. Expiry alerts are sent 30, 14, 7, 3 and 1 day before a certificate expires, plus at your own threshold, which defaults to 14 days and can be set between 1 and 90 days. HTTP(S) monitors can also validate the certificate on every check, so an expired certificate, a self-signed or broken chain or a hostname mismatch fails the check with a descriptive error.