SSL certificate expiry: check, monitor and renew

An SSL certificate is a small signed file that proves a server is allowed to answer for a hostname. "Expired" means the current time is later than the end date written inside that file. From that second, browsers stop trusting it.

The correct name today is a TLS certificate. TLS replaced the older SSL protocol, but most people still say SSL, so this guide uses both.

What is inside a certificate

A certificate follows a format called X.509, defined in RFC 5280. The parts that matter here are:

• The hostnames it covers, in a list called the Subject Alternative Name.
• A public key, which the browser uses to set up the encrypted connection.
• The issuer: the certificate authority (CA) that signed it. A CA is an organisation that browsers already trust.
• Two dates: notBefore and notAfter. The certificate is valid only between them.

What the browser does

When you open an HTTPS page, the server sends its certificate. The browser checks four things: the hostname matches, the signature leads back to a CA it trusts, the certificate has not been revoked, and the current time is between the two dates.

If the time check fails, the browser shows a full page warning in place of your site. Nothing is loaded. Apps, API clients and payment callbacks fail too, and they usually fail with no screen for anyone to click through.

If your site sends the Strict-Transport-Security header (HSTS), browsers also remove the option to continue past the warning. Visitors cannot get in until you fix the certificate.

The dates are checked against the visitor's own clock. A visitor whose computer has the wrong date can see an expiry error on a perfectly good certificate.

Connect to the server with openssl s_client and pass the certificate to openssl x509 -noout -dates. This reads the certificate the server sends to real visitors.

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

The output is two lines:

notBefore=Aug 14 09:12:37 2026 GMT
notAfter=Nov 12 09:12:36 2026 GMT

Read it like this. The certificate became valid on 14 August 2026 and stops being valid at 09:12:36 UTC on 12 November 2026. That is a 90 day certificate. On 12 October 2026 it has 31 days left: 19 more days in October plus 12 in November.

What each part of the command does

• -connect example.com:443 is the server and port to open.
• -servername example.com tells the server which site you want. One IP address often serves many sites, each with its own certificate.
• </dev/null closes the connection straight after the handshake, so the command does not wait for input.
• 2>/dev/null hides the connection messages.
• -noout -dates prints only the two dates and not the encoded certificate.

More commands worth keeping

Days left, as a number (Linux):

end=$(openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
echo $(( ($(date -d "$end" +%s) - $(date +%s)) / 86400 ))

Who issued it and which hostnames it covers:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -ext subjectAltName

A certificate file on disk:

openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -dates

A yes or no answer for scripts. This asks "will it expire in the next 30 days?" (2592000 seconds is 30 days). It exits with status 0 if the certificate is safe and 1 if it is not:

openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -checkend 2592000

A mail server that upgrades to TLS with STARTTLS:

openssl s_client -connect mail.example.com:587 -starttls smtp </dev/null 2>/dev/null | openssl x509 -noout -dates

One server behind a load balancer, by IP address:

openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -serial

If you do not have a terminal to hand, the SSL checker shows the same dates in the browser.

A new public certificate can last at most 200 days today, and certificates from Let's Encrypt last 90 days. Both numbers are going down on a published schedule.

The maximum for public certificates

The limit is set by the CA/Browser Forum, the group of certificate authorities and browser makers that writes the rules for public certificates. In April 2025 it passed ballot SC-081v3, which cuts the maximum in three steps.

The limit applies on the day a certificate is issued. A 398 day certificate issued in early March 2026 stays valid until its own end date, so you can still meet these until spring 2027.

Let's Encrypt

Let's Encrypt certificates last 90 days by default. Let's Encrypt has published its own schedule: the default drops to 64 days on 10 February 2027 and to 45 days on 16 February 2028.

What this means for you

Count the renewals. A 398 day certificate needed about 1 renewal a year. A 47 day certificate that is renewed with a third of its life left needs about 12 a year.

Renewing by hand does not survive that. Every certificate you own needs to renew without a person, and every one of those renewals needs something watching it.

Private certificates from your own internal CA are not covered by these limits. They still expire, and they are the ones most often forgotten, because no public tool can see them.

Automated renewal fails because it depends on things outside the renewal tool: open ports, DNS records, API tokens, a server reload, and every place that holds a copy of the certificate. When one of those changes, renewal breaks without an error anyone sees.

Most automation uses the ACME protocol. The CA asks you to prove you control the hostname by passing a challenge. There are two common ones, described in the Let's Encrypt challenge documentation:

• HTTP-01: the CA fetches a file from your server over port 80.
• DNS-01: the CA looks up a TXT record at _acme-challenge.example.com. Wildcard certificates need this one.

These are the failures that come up again and again.

Three of these in more detail

Renewed but not reloaded is the most confusing one, because every check on the server says the certificate is new. Web servers such as nginx read the certificate when they start or reload. Add a reload to the renewal itself:

certbot renew --deploy-hook "systemctl reload nginx"

Rate limits at Let's Encrypt include 5 certificates for the exact same set of hostnames in 7 days, and 5 failed validations for one hostname in an hour. A deploy script that requests a fresh certificate on every run can use these up in an afternoon. The rate limit documentation has the full list.

An expired certificate higher in the chain is rare but wide. On 30 September 2021 the root certificate "DST Root CA X3" expired, and older devices that relied on it began to reject sites using Let's Encrypt, even though those sites had valid certificates of their own.

Do not count on a warning email from your CA either. Let's Encrypt stopped sending expiry notification emails on 4 June 2025.

The chain is the list of certificates that links yours to a CA the browser already trusts. It breaks when your server does not send the middle certificates, or when one of them has expired.

A chain has three levels:

1. Leaf: your certificate, with your hostname in it.
2. Intermediate: a certificate owned by the CA, which signed yours. There can be more than one.
3. Root: the CA's top certificate. It is already stored in the browser or operating system. Your server does not need to send it.

Your server must send the leaf and every intermediate. The client then joins them up to a root it holds.

The missing intermediate

The common mistake is to configure the server with only the leaf. With Certbot, that means pointing at cert.pem when you should point at fullchain.pem:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

This mistake is hard to spot, because desktop browsers can often fill the gap themselves. The site looks fine on your laptop. Then curl, a mobile app or another server's API client fails with "unable to verify the first certificate" or "unable to get local issuer certificate".

How to test the chain

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Look at two places in the output:

• "Certificate chain" near the top. Entry 0 is your leaf. You should see at least one more entry after it.
• "Verify return code" near the bottom. You want 0 (ok).

A hostname mismatch means the name in the address bar is not in the certificate's list of names. The certificate can be in date and correctly signed and still fail this check.

Browsers compare the hostname with the Subject Alternative Name list. They no longer read the older Common Name field. Print the list with:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

What a wildcard covers

A wildcard name such as *.example.com covers exactly one level of subdomain. It does not cover the bare domain and it does not cover two levels.

Common causes

• The certificate has www.example.com but not example.com, or the reverse. Request both names.
• A new subdomain points at an old server that answers with its default certificate for another site.
• The DNS record points at the wrong IP address. You reach a different server, and it sends its own certificate. Check the record first. The guide to DNS records shows how.
• You connected by IP address. Public certificates are normally issued for hostnames, so https://203.0.113.10 does not match.

Each code names the one check that failed, so it tells you where to look. Only the date codes are about expiry.

If one visitor reports a date error and your own check shows a valid certificate, ask them what date their device shows. A wrong clock is the cause more often than you would guess.

Monitor the certificate that each public hostname really serves, checked from outside your network, and alert at 30, 14 and 7 days before the end date. Those three thresholds give you a notice, a warning and an emergency.

What each threshold means

The meaning depends on how the certificate renews. Many ACME clients renew a 90 day certificate when about 30 days are left.

As lifetimes get shorter, fixed day counts stop fitting. A 45 day certificate renewed at two thirds of its life is renewed with 15 days left, so "14 days left" already means renewal failed. For short certificates, set the first alert a day or two below the point where renewal should have happened.

What to put on the list

• Every hostname, not only the main one. Include www, api, app, status, staging sites and anything a customer or a partner system connects to.
• The served certificate, not the file. A file check passes in the "renewed but not reloaded" case. An outside check does not.
• The public address. If a CDN or load balancer sits in front, that is the certificate visitors get.
• Other TLS ports. Mail on 465, 587 and 993, and any database or message queue that uses TLS.
• The renewal job itself. Add a heartbeat to it, so you hear when it stops running. The cron job monitoring guide shows how.

17 3 * * * certbot renew -q && curl -fsS -m 10 --retry 5 -o /dev/null https://pulsx.net/api/beat/<your-token>

certbot renew exits with status 0 when nothing is due, so this ping means "the renewal job ran and nothing failed".

PULSX tracks SSL certificate expiry on every HTTPS monitor, so adding a site for uptime covers its certificate too. It is free for 20 monitors and you can sign up without a card.

The runbook is: confirm the problem from outside, find where the certificate lives, renew, reload, then verify from outside again. Do not skip the last step.

Before it expires: a routine check

1. List what Certbot manages and when each certificate ends: certbot certificates
2. Test renewal without changing anything: certbot renew --dry-run
3. Confirm the timer exists: systemctl list-timers | grep -i certbot
4. Compare the list of names with the hostnames you really use. Anything missing is a forgotten subdomain.

When it has expired or is about to

1. Confirm from outside. Run the openssl s_client command from the top of this guide. Note the notAfter date and the serial number.
2. Find where TLS ends. Is it a CDN, a load balancer, or the web server itself? That is the place that needs the new certificate.
3. Renew. Run certbot renew --cert-name example.com and read the full error if it fails.
4. Fix the cause. Use the failure table above: port 80, the DNS challenge, the CAA record, a rate limit.
5. Check the config and reload. nginx -t && systemctl reload nginx
6. Copy it to the edge if a load balancer or CDN holds its own copy.
7. Verify from outside. Run the openssl command again. The notAfter date and the serial number must both have changed, and "Verify return code" must be 0 (ok).
8. Check the neighbours. Other hostnames set up at the same time often expire in the same week.

If Certbot says the certificate is not due

If step 3 reports that the certificate is not yet due for renewal, but visitors still see the old one, the renewal already worked. The server was never reloaded, or the edge has an old copy. Go to steps 5 and 6.

Avoid --force-renewal in a loop. Each forced run counts towards the rate limit of 5 certificates for the same names in 7 days.

Afterwards

Write down the cause while it is fresh, add the missing monitor, and add a reload hook if that was the gap. The incident postmortem guide has a format you can copy.