How to check when an SSL certificate expires

The quick way: the padlock and an online check

In any browser, click the padlock in the address bar, open the certificate details, and read "valid from" and "valid to". That takes ten seconds and tells you what your own browser sees. Its limitation is that it covers only the certificate served to you, from the edge node or server you happened to reach, at the moment you looked.

An online SSL check does the same handshake from outside your network and reports the expiry date, the issuer, the names the certificate covers, and whether the chain it was served is complete. Browsers hide that last point, so the outside check tells you something the padlock cannot.

The manual way with openssl

One command prints the validity window:

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

The -servername flag sends SNI, which matters because most servers host several certificates on one address and will hand you the wrong one without it. The output gives notBefore and notAfter in UTC, plus who the certificate is for and who issued it.

To see the whole chain the server sends, rather than just the leaf:

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

Read the "Certificate chain" block at the top: you should see the leaf, then one or more intermediates. A "verify error: unable to get local issuer certificate" line means the server is not sending the intermediate, which many browsers paper over and many API clients, mobile apps and older systems do not.

Leaf, chain and what expires

Three certificates are involved in a normal HTTPS connection, and each has its own expiry date:

• The leaf is the certificate issued for your domain. It is the short-lived one, typically 90 days for automated issuance and up to about a year for a purchased one, and it is what people mean by "the certificate".
• The intermediate signs the leaf and must be sent by the server alongside it. It lasts for years, and it is precisely because it changes so rarely that its expiry catches teams by surprise.
• The root lives in the client's trust store, not on your server. When a root expires or is distrusted, older devices that never received the update start failing while current ones are fine, producing an outage that looks impossible from your own laptop.

So validate the chain, not just the date on the leaf. A leaf with two months left on a broken chain is already failing for some clients.

Why expiry is the most common preventable outage

Certificate expiry is an unusually damaging failure. It fails completely rather than gradually, because a browser refuses the connection outright and shows a full-page warning instead of the site. The moment it happens was fixed the day the certificate was issued, and nobody was watching that date. It also takes down everything that uses the name at once, not only the website: APIs, mobile app backends, webhooks and integrations. Failed payment callbacks and broken integrations often cost more than the visible downtime.

It is also entirely preventable, which is why it is the failure most worth automating a check for.

How auto-renewal still fails

Automated issuance removed most expiries and introduced a set of failures that are harder to see:

• The renewal ran but nothing reloaded. A new certificate sits on disk while the web server keeps serving the old one from memory until it is reloaded.
• The validation challenge broke. A redirect rule, a firewall change or a new CDN in front of the origin blocks the HTTP challenge path, so renewal keeps failing for weeks with no visible symptom.
• DNS validation lost its credentials. An API token was rotated or expired and the DNS challenge can no longer create its record.
• The renewal timer is not running. A container was rebuilt without the cron job or systemd timer, or the machine was migrated and the schedule did not come with it.
• Only one node renewed. Behind a load balancer, one server has the new certificate and another still serves the old one, so failures look intermittent.
• Renewal emails went to someone who left. The purchased-certificate version of the same problem.
• The certificate renewed but not for every name. A subdomain added later is missing from the new certificate, so that one hostname fails.

Every one of these is invisible from inside the renewal system and obvious from outside. That is the argument for checking the live handshake rather than trusting the automation's own logs.

Automating the check

Reading a date tells you today's answer, and the whole problem with expiry is that it arrives on a day nobody chose to check. Scheduled certificate monitoring performs the real handshake from outside on an interval, warns a set number of days before notAfter, and catches the chain and hostname problems a calendar reminder never would. HostTracker alerts by email, SMS, voice call, Slack, Telegram and more, so the warning reaches someone before the expiry does. Domain and TLS monitoring runs the check continuously, the SSL check tool does a one-off, and how to check if a port is open deals with a handshake that fails before a certificate is even offered.