SSL Certificate Expiry: Why Certificates Expire and How to Monitor Them

An SSL certificate (technically a TLS certificate) expires on a fixed date written into the certificate itself, after which browsers and clients stop trusting it. An expired certificate is effectively an outage: visitors see a security warning instead of your site, and most API clients, mobile apps and webhooks fail with a TLS error.

Why certificates expire

• Key rotation. Regular replacement limits the damage if a private key is compromised without anyone noticing.
• Fresh validation. A certificate proves that someone controlled a domain at the time of issuance. Domains change hands; expiry forces that proof to be renewed.
• Faster adoption of new standards. Short lifetimes mean changes to algorithms and rules reach the whole ecosystem quickly.
• Revocation is unreliable. Revocation checks are not consistently enforced by clients, so expiry acts as the backstop.

Certificate lifetimes are getting shorter

The direction is clear: certificates will need renewing several times a year, then roughly every month and a half. Manual renewal, with a calendar reminder and someone uploading files, stops being practical. Automation through the ACME protocol, which Let's Encrypt and many other certificate authorities support, is becoming the norm.

What happens when a certificate expires

• Browsers show a full-page warning such as "Your connection is not private". Most visitors leave.
• API clients, SDKs, mobile apps and server-to-server integrations fail the TLS handshake and stop working.
• Incoming webhooks from payment providers and other services fail delivery.
• HSTS-enabled sites cannot be bypassed by users at all.

Certificate types and what they mean for renewal

• Domain validated (DV) certificates prove control of a domain only. They are issued automatically, often free, and are what Let's Encrypt provides. They are the easiest to renew automatically.
• Organization validated (OV) and extended validation (EV) certificates include verified company details and usually involve a manual vetting step, which makes renewal more likely to be forgotten.
• Wildcard certificates (for example *.example.com) cover all first-level subdomains. With ACME they require DNS-based validation, and one expired wildcard can break many hostnames at once.
• Multi-domain (SAN) certificates list several hostnames in one certificate; renewal fails if validation fails for any one of them.

Whatever the type, the expiry date is set in the certificate and cannot be extended; a new certificate must be issued and installed.

Why automated renewal still fails

Automation reduces expiry incidents but does not eliminate them. Common reasons renewal silently stops working:

• The renewal job or timer was removed during a server migration.
• HTTP-01 validation fails because a redirect, firewall or CDN rule blocks /.well-known/acme-challenge/.
• DNS-01 validation fails because the DNS API credential expired or was rotated.
• The certificate renewed on disk, but the web server was never reloaded and still serves the old one.
• A load balancer, CDN or second server holds its own copy that was not updated.
• Rate limits at the certificate authority after repeated failed attempts.

This is why you should monitor the certificate that is actually served to users, not just trust that the renewal job ran.

How to check a certificate's expiry date

From a terminal, openssl shows the dates of the certificate a server presents:

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

The notAfter line is the expiry date. The -servername flag matters on servers that host several sites, because without SNI you may see a different certificate. In a browser, click the padlock or site information icon and open the certificate details.

How to monitor SSL certificates

Effective certificate monitoring has three parts:

1. Validate on every check. An external HTTPS monitor should fail when the certificate is expired, untrusted, or does not match the hostname, so you hear about a broken certificate within minutes rather than from customers.
2. Track the expiry date of each certificate and review upcoming expiries, especially for certificates that are not auto-renewed.
3. Monitor the renewal process itself. Add a heartbeat ping after your renewal command succeeds, so a broken renewal job is caught before the certificate runs out.

In Uptime Tracker, every HTTPS monitor validates the certificate: an invalid, expired, untrusted or wrong-hostname certificate fails the check and triggers an alert, and the certificate's expiry date is visible on every HTTPS monitor. Separate advance-warning emails before expiry are not offered yet, so combine this with automated renewal and a heartbeat on the renewal job. For example, run the renewal check hourly and ping on success; renewal clients such as certbot only request a new certificate when the current one is close to expiry. See SSL certificate monitoring and how to monitor cron jobs.

0 * * * * certbot renew --quiet && curl -fsS -m 10 https://uptimetracker.live/api/v1/heartbeats/YOUR_TOKEN > /dev/null

Do not forget the domain

A certificate is only useful if the domain itself stays registered. Domain registrations expire too, usually yearly, and a lapsed domain takes down the website, email and certificate validation at once. A domain expiry monitor warns you ahead of the registration date.

SSL certificate checklist

• Every public hostname has a certificate from an automated (ACME) process where possible.
• Renewal runs on a schedule and is monitored with a heartbeat.
• The web server or proxy reloads automatically after renewal.
• Certificates on load balancers, CDNs and secondary servers are included in the process.
• An external HTTPS monitor validates the served certificate on every check.
• Manually managed certificates have an owner and a reminder well before the expiry date.
• Domain registration has auto-renew enabled and is monitored for expiry.
• The full certificate chain is served, so clients without cached intermediates can connect.