How to Check When an SSL Certificate Expires (and Get Warned in Time)

An expired SSL certificate is one of the most avoidable outages there is. You know the date in advance, often months ahead, and yet it still takes down websites and APIs all the time, usually because auto-renewal broke quietly and nobody was watching.

This guide shows four ways to check when a certificate expires, explains why certificates now expire much sooner than they used to, and covers how to get warned before it matters.

Why do SSL certificates expire, and why sooner now?

A certificate vouches that a server really is example.com. Expiry limits how long a stolen key or a mistakenly issued certificate stays useful, and forces owners to re-prove they still control the domain.

The maximum lifetime keeps shrinking. In April 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules, adopted ballot SC-081. It cuts the maximum validity of public TLS certificates in stages:

The 200-day limit is already in force. A certificate you used to renew once a year now needs replacing about twice a year, and by 2029 it'll be every six to seven weeks. Doing that by hand stops being realistic, so automated renewal becomes mandatory in practice. That makes checking that the automation actually worked more important, not less.

What happens when a certificate expires?

• Websites show a full-page browser warning ("Your connection is not private"). Most visitors leave.
• APIs fail outright. Clients refuse the connection before any data is exchanged. curl reports SSL certificate problem: certificate has expired, Node.js reports CERT_HAS_EXPIRED, and mobile apps just show a generic network error. Every integration breaks at once.

There's no grace period. A certificate valid until 14:00 UTC is rejected at 14:00:01.

Method 1: Check the expiry date in your browser

Fine for a website you're looking at:

1. Open the site and click the padlock or site-settings icon left of the address bar.
2. Choose the option to view the connection or certificate details. The wording varies by browser.
3. Look for Expires on or Valid to.

This doesn't help for an API endpoint that serves JSON rather than a page, or for a host that sits behind a redirect.

Method 2: Check with OpenSSL

On macOS or Linux, and Windows with Git Bash or WSL:

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

It prints a line like notAfter=Dec 25 22:56:35 2026 GMT. The -servername part matters: servers that host several sites pick the certificate based on it, and leaving it out can show you the wrong certificate.

To ask "does it expire within the next 14 days?" in a script, use -checkend with a number of seconds:

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

It prints Certificate will not expire or Certificate will expire and exits non-zero in the second case, which makes it easy to wire into a CI job.

Method 3: Check with curl

If curl is installed, verbose mode prints the certificate's dates as part of the handshake:

curl -vI https://example.com 2>&1 | grep -i "expire date"

The exact output depends on which TLS library your curl was built with, so if nothing matches, run it without the grep and look through the connection details.

Method 4: Check online, for any website or API

The Wrklyst API Monitor reads the certificate on every HTTPS check. Enter any URL, a website or an API endpoint, and click Run check. Alongside the status code and response time it shows SSL certificate expires in N days with the date, highlighted once 14 days or fewer are left.

Two details that make this more useful than a browser check:

• It reads the certificate of the server that actually answered. If example.com redirects to api.example.com, you see the certificate that the final hop presented, which is the one your clients depend on.
• It works for endpoints that aren't web pages, including authenticated ones. Add a bearer token or API key on the Auth tab if the endpoint needs it. See How to Test an API Online.

If the certificate is already broken, the check fails with the reason, e.g. The TLS certificate has expired, The TLS certificate does not match that hostname, or The TLS certificate chain could not be verified.

How do I get warned before it expires?

Checking once only tells you about today. To find out before it's too late, check on a schedule:

• Your own automation. Run the -checkend command above daily from cron or CI and alert on a non-zero exit.
• A monitor. In the API Monitor, click Monitor this, add your email, and pick a daily or weekly report. Every check records the certificate's expiry, and the report includes a line showing the days left, highlighted at 14 days or fewer. Signed in, your dashboard shows an SSL column for every monitor. If the certificate does lapse, the next check fails and you get a "down" alert by email and in Slack, Discord or Teams if you've connected them.

Be clear about what the monitor does and doesn't do: the early warning appears in your report and on your dashboard, not as a separate expiry-only alert. If you want to see it every day, choose the daily report.

Why does auto-renewal still fail?

Automated renewal (Let's Encrypt, cloud-managed certificates) removes most of the risk, but these are the usual ways it breaks:

• The validation path changed. HTTP validation needs /.well-known/acme-challenge/ to be reachable. A new redirect rule, a firewall or a CDN setting can block it.
• DNS moved. DNS validation needs an API token for the DNS provider. Move providers or rotate the token and renewals silently stop.
• The new certificate was never loaded. Renewal succeeded on disk, but the web server, load balancer or CDN is still serving the old one, because nothing reloaded it.
• A forgotten host. The main site renews, but api., status. or a legacy subdomain was set up by hand years ago.
• Rate limits or account problems at the certificate authority, such as too many failed attempts or an expired payment method on a paid certificate.

Notice that in almost every case the renewal job thinks it succeeded or never ran, and nothing tells you. Checking the certificate your server actually serves, from outside, is what catches all of them.

A quick checklist

• List every hostname that serves HTTPS, including API, status and legacy subdomains.
• Check each one's expiry date with any method above.
• Put the ones your users or integrations depend on under a scheduled check.
• Expect renewals about twice a year now, and more often from 2027.
• After any DNS, CDN or load-balancer change, check the certificate that's actually being served.