How to check an SSL certificate's expiry date, and why it is shrinking

Four ways to see the expiry date

In the browser

Every browser hides the viewer a click or two deep, and the menu wording shifts between versions, but the route is always the same: click the icon at the left of the address bar, open the connection or security details, and choose the option that shows the certificate.

• Chrome and Edge: the icon left of the address, then the connection details, then the certificate entry. The Details tab lists "Valid from" and "Valid to".
• Firefox: the padlock, then the connection details, then "More information" and "View Certificate". Validity sits under "Not Before" and "Not After".
• Safari: click the padlock, choose "Show Certificate", and expand the details to find the expiry line.

Look at three fields, not one: the validity dates, the issuer (the CA that signed it), and the subject alternative names (SAN), which are the host names the certificate is allowed to answer for. A certificate with a perfect date and the wrong name still produces a warning.

From a terminal with openssl

This is my default when I am on a server, because it shows what the server really hands out and works on any port.

The -servername part matters: without it, a server hosting many sites may return its default certificate instead of the one for your name. The output looks like this:

Both dates are in GMT, which is UTC for practical purposes. If you only want a yes or no for monitoring scripts, -checkend takes a number of seconds and sets the exit status:

2,592,000 seconds is 30 days. The command prints "Certificate will expire" and exits with 1 if the certificate dies inside that window, otherwise it prints "Certificate will not expire" and exits with 0. Wire that into a daily job and you have a monitor in one line.

Logged versus served: what a browser-based lookup can and cannot say

Publicly trusted CAs record the certificates they issue in public Certificate Transparency (CT) logs. Our checker queries those logs from your browser, picks the latest certificate that covers the host, and shows the issuer, the SAN list, the dates and a countdown. That is useful and fast, but it is a record of issuance, not a snapshot of the live handshake.

The gap shows up in real setups. A load balancer may still serve an older certificate on one node, a CDN may present its own, and a renewal that was issued but never installed will look healthy in the logs while visitors still get the old one. When the logged certificate and the browser warning disagree, trust the browser, and use openssl or the certificate viewer to see what is actually served.

Turning dates into days left

Work in UTC and round down, because a certificate that has 10 days and 8 hours left should be treated as having 10 days. A worked example with a hypothetical shop certificate:

• Valid to 2026-10-18 at 07:59:59 UTC.
• Checked at 2026-10-08 at 00:00 UTC.
• Difference: 10 days 7 hours 59 minutes 59 seconds, so 10 days left.

With the thresholds in the figure, that lands in amber. A 90-day certificate that close to the end tells me automatic renewal has probably stopped, so I go and look at the renewal job rather than wait for it to catch up.

Why certificates now expire sooner

The CA/Browser Forum ballot SC-081v3 cuts the maximum lifetime of publicly trusted certificates in steps. I describe it simply as the 200-day limit now in force, dropping to 100 days and then 47 days. The exact dates are in this table, and certificates issued before a step keep the older limit until they expire (DNSimple's announcement summarises the change).

The practical consequence is simple: renewal can no longer be a yearly chore you remember. It has to be automated, and the automation has to be watched. Let's Encrypt has also stopped sending its expiry reminder e-mails (they used to arrive about 20 and 7 days before the end), so silence from the CA no longer means everything is fine (their explanation).

My rule of thumb for ACME clients: renew when about a third of the lifetime is left, and alert when fewer than a quarter remains. With today's limit that means renewing around day 130 of 200 and shouting at day 150; as lifetimes shrink, both numbers shrink with them, so set them as fractions rather than fixed day counts.

Names: wildcard and SAN coverage

Dates are only half the story. A certificate is valid for the names in its SAN list, and a wildcard covers exactly one extra label.

The bare domain is the classic trap: a wildcard-only certificate leaves https://example.com with a name-mismatch error while www works. Make sure the bare name is listed as its own SAN entry.

If the certificate has already expired

1. Confirm which name and which certificate. Check www and the bare domain separately, and any other host such as a mail or API name.
2. Get a new certificate from your CA or hosting panel, or run your ACME client manually and read its error output.
3. Install the full chain (your certificate plus the intermediates), not the single file. Missing intermediates produce errors on some devices and not others.
4. Reload the web server or the load balancer, and clear the CDN cache if one sits in front.
5. Re-check from a second network, then find out why automation failed: a blocked challenge port, a changed DNS record, a CAA record that does not list the CA, or a cron job that was lost in a server move.

Last, check the clock on the device that shows the warning. A laptop with a wrong date makes a perfectly good certificate look expired or not yet valid.

Related reading: how to read DNS records explains the CAA record that limits who may issue, and is a website down for everyone or just me walks through the rest of the diagnosis when the certificate turns out to be fine.