Every SSL/TLS certificate has an end date. When that date passes, browsers stop trusting the site and show visitors a warning page. The website itself is still running, so uptime checks that only ask for a status code may not notice at all. Certificate expiry is one of the most preventable causes of an outage, and this guide shows how to prevent it.

What an SSL/TLS certificate does

A certificate does two jobs when a browser opens an https:// address:

  • It proves identity. It says that this server is authorised to answer for this domain name, vouched for by a certificate authority the browser trusts.
  • It enables encryption. It carries the public key that the browser and the server use to set up an encrypted connection.

The term SSL is old. Modern connections use TLS, but people still say "SSL certificate" and so does this guide.

A certificate holds a start date (notBefore) and an end date (notAfter). Outside that window, it is not valid. This is defined in the X.509 standard, RFC 5280.

Why expiration matters

When a certificate expires:

  • Browsers show a full-page warning and make it hard to continue.
  • Search crawlers, payment providers, and API clients may refuse the connection.
  • Mobile apps and integrations that talk to your server may fail without any visible message.
  • Visitors often assume the site is hacked.

Nothing is wrong with the server. That is why the problem is easy to miss and quick to cause real damage.

How to check a certificate's validity period

You can check any public site yourself, without special tools.

In a browser

The exact menu names vary between browsers and versions. In most desktop browsers:

  1. Open the website.
  2. Click the icon at the left of the address bar (a padlock or connection icon).
  3. Choose the entry about the connection or the certificate, and open the certificate details.
  4. Read the "Valid from" and "Valid to" dates.

With OpenSSL

On Linux and macOS, OpenSSL is usually installed. This command connects to the site and prints the dates:

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

Replace example.com with your domain. The result looks like this (the dates here are examples):

notBefore=Sep 26 22:49:11 2026 GMT
notAfter=Dec 25 22:56:35 2026 GMT

What each part does:

  • openssl s_client -connect example.com:443 opens a TLS connection to port 443 and prints what the server sends.
  • -servername example.com sends the host name during the handshake (SNI, Server Name Indication). Many servers host several sites on one address, and use the name to choose which certificate to present. Without it, you may be shown a different site's certificate.
  • </dev/null closes the input at once, so the command ends instead of waiting.
  • 2>/dev/null hides the connection details, which go to the error stream.
  • openssl x509 -noout -dates reads the certificate from the pipe and prints only its start and end dates.

To ask a yes-or-no question instead, use -checkend with a number of seconds. This one asks whether the certificate will still be valid in 30 days (2,592,000 seconds):

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

It prints Certificate will not expire and exits with 0 if the certificate will still be valid then. If it will have expired by then, it exits with a non-zero status. That makes it easy to use in a script.

Note

This command shows the dates of the certificate the server presents on that port. It is not a complete test. It does not check that the chain is complete, that the name matches, or that a browser would trust the result. It also says nothing about whether the site itself is available.

How certificate renewal works

A certificate cannot be extended. Renewing means getting a new certificate for the same names, with new dates, from the certificate authority, and then installing it where the server can use it.

Two steps matter, and people often remember only the first:

  1. Issue. The authority checks that you control the domain and gives you a new certificate.
  2. Deploy. The new certificate and key are put where the web server reads them, and the server is told to load them.

Until the second step is done, the server keeps serving the old certificate, and the old end date still applies. A renewed file on disk is not a renewed certificate in production.

Automatic renewal

Most certificate authorities now expect renewal to be automated. Let's Encrypt, for example, issues certificates that last 90 days by default, and its integration guide recommends renewing when about a third of the lifetime is left, so that a failed attempt can be retried.

Typical tools, such as Certbot and the ACME clients built into many hosting panels and web servers, do this on a schedule. They try the renewal regularly, replace the certificate files when it is due, and can run a command afterwards, such as reloading the web server.

Whatever you use, set it up so that you can see it working:

  • Know where it runs and how often.
  • Know who is told when it fails.
  • Run a dry run, if the tool supports it. Certbot has certbot renew --dry-run.

Certificates are getting shorter

Certificate lifetimes are being reduced across the industry, which makes manual renewal less and less practical:

  • The CA/Browser Forum, the body that sets the rules for public certificates, approved a schedule that lowers the maximum validity from 398 days to 47 days. Certificates issued on or after 15 March 2026 may last up to 200 days, from 15 March 2027 up to 100 days, and from 15 March 2029 up to 47 days.
  • Let's Encrypt has announced that its default profile will move to 64 days in February 2027 and to 45 days in February 2028.

If you renew by hand once a year, plan to automate. Check the current rules of your own authority, because schedules can change.

Note

Let's Encrypt no longer sends expiration reminder emails. If you used them as your safety net, you need a monitor of your own.

Why automatic renewal can fail

Automatic does not mean reliable. These are the common reasons that renewals fail without anyone noticing:

  • The scheduled job stopped. The server was rebuilt, the timer was lost, or the job was never enabled.
  • The domain check fails. The authority must reach your site or your DNS records to confirm control. A changed firewall, a moved DNS zone, a redirect that now catches the challenge, or a CDN in front can break this.
  • The new certificate is not loaded. The file is replaced, but the web server is never reloaded, so it keeps the old one in memory.
  • A different server holds the certificate. A load balancer, a CDN, or a second host serves its own copy that no job updates.
  • A name was added or removed. The certificate no longer covers all the host names in use.
  • The account or credentials expired. An API token for DNS validation was revoked, or the contact email on the account is dead.
  • Rate limits or authority changes. Too many attempts, or a change in the issuer's rules, can reject a request.

The second and third are the most common in practice, and neither shows up in the certificate dates until it is too late.

Certificate chains and deployment problems

A server should send its own (leaf) certificate and the intermediate certificates that link it to a trusted root. If an intermediate is missing, some clients can still build the path and others cannot. The site then looks fine in your browser and fails in an app, a command-line tool, or an older phone.

Signs of this problem:

  • The site works in a desktop browser but fails with curl or from a script.
  • openssl s_client ends with a message about being unable to verify the first certificate.
  • Only some devices complain.

To look at the chain the server sends, add -showcerts:

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

At the end of the output, find the line starting Verify return code. 0 (ok) means that OpenSSL could build a trusted path.

Other deployment slips to look for: the certificate and key do not match, an old certificate is served on one of several servers, or a site is reached by a name that the certificate does not list.

Monitor certificate expiration

Even with automation, watching the end date is the safety net. It catches every failure above, because it looks at what is served, not at what should be.

A good expiry check:

  • Reads the certificate that visitors get, on the real address.
  • Warns early enough to act, with days to spare, not hours.
  • Warns the person who can fix it.
  • Warns again if the problem is not fixed, or at least does not let the warning be lost.

In UptimeWire

For every website whose address starts with https://, UptimeWire checks the certificate separately from the uptime check. Here is how it behaves:

  • Own schedule. Certificate checks run every few hours, on their own schedule, not at the uptime interval. A warning can therefore arrive hours after the threshold has been crossed, and not at the exact moment.
  • Warning lead time. You choose how many days before expiry to be warned. The default is 30 days, and the setting is per website. A warning is sent when the certificate has fewer days left than that.
  • Sent once. The warning is sent when the check enters the warning state, not on every check after that.
  • Invalid certificates. If the certificate cannot be validated at all (for example, it has expired or is for the wrong name), you are warned at once and do not wait for the threshold.
  • Channels. Certificate warnings go by email, and by Telegram if you have connected it. Chat and webhook channels do not carry them.

UptimeWire does not renew or replace certificates. It tells you that the time has come to act.

Important

Monitoring does not replace renewal. A warning that nobody reads, or that goes to a channel that does not carry it, protects nothing. Make sure the email address is one that someone checks.

What to do when a certificate has expired

  1. Confirm it. Check the dates with a browser or with the OpenSSL command above, on the real address.
  2. Find where the certificate is served. It may be your web server, a load balancer, a CDN, or a hosting panel.
  3. Renew it. Run the renewal tool, or request a new certificate from your authority. If automation failed, read its log to find out why.
  4. Deploy it. Install the new certificate and reload the service that serves it.
  5. Check again from the outside. Read the dates on the live address, and check the chain.
  6. Find the cause. Fix why the automation failed, or the same thing will happen at the next renewal.
  7. Tell people, if needed. If customers saw the warning, a short note on a status page or by email is worth it.

Prevention checklist

  • Every public host name is listed, with the certificate that covers it and where it is served.
  • Renewal is automatic, and you know where it runs.
  • Someone receives the failure message of the renewal job.
  • The web server is reloaded after the certificate is replaced.
  • The chain is complete (Verify return code: 0 (ok)).
  • The end date is monitored from outside, with a warning lead time of at least two weeks.
  • The warning email goes to a mailbox that a person reads.
  • You check the dates after any change of server, CDN, or hosting.
  • Domain registration and DNS are monitored too, since they fail in the same quiet way. See the Complete Guide to Website Uptime Monitoring.

For the other side of the problem, noticing when a site is unreachable for any reason, read How to Monitor Website Availability.