SSL Studio A DNS Studio tool
Studio tools

How to check when an SSL certificate expires

The expiry date is on the certificate itself — here are four ways to read it, from a two-click browser check to a scriptable one-liner.

Every SSL certificate states, to the second, when it stops being valid. Browsers enforce that moment ruthlessly — one second past and visitors get a warning page instead of your site — so knowing the date, and knowing it early, is the whole game. Publicly trusted certificates last at most 398 days and free Let’s Encrypt certificates just 90, which means expiry dates come around often. Here are four reliable ways to check one, from quickest to most thorough.

1. In your browser (any site, two clicks)

Browsers will show you the certificate of the site you are on:

This is perfect for a one-off look, with two limitations: you see the certificate your browser negotiated (which may come from a CDN edge near you), and nothing about it is monitored — you would have to remember to look again.

2. With the SSL Studio expiry checker (any domain, no install)

Our SSL expiry checker reads the certificate directly from the server and answers the question in its first line: “Expires in 42 days — 15 August 2026”, as a countdown with the exact date. Because it runs the full certificate check behind the countdown, it will also tell you if something other than expiry needs attention — a name mismatch or an incomplete chain will not hide behind a healthy number of days. Switch to Tech mode and you get the raw Not Before/Not After timestamps, the SAN list, the chain and fingerprints — useful when you need to quote exact values in a ticket.

It also checks domains you do not control — handy before pointing an integration at a third-party API, or when a supplier’s “SSL problem” needs a neutral second opinion.

3. With OpenSSL (command line, scriptable)

To read the dates straight from a live server:

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

Output:

notBefore=May 17 09:14:22 2026 GMT
notAfter=Aug 15 09:14:21 2026 GMT

The -servername flag matters: it sets SNI, so a server hosting many sites returns the certificate for the right one. Two more variants earn their keep in scripts: 

# Fail (non-zero exit) if the cert expires within 30 days — ideal for cron:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -checkend 2592000

# Read a certificate file on disk instead:
openssl x509 -noout -enddate -in /etc/ssl/certs/example.pem

On Windows without OpenSSL, PowerShell can do the same via [Net.Sockets.TcpClient]/SslStream, though installing OpenSSL is usually less code.

4. Continuously, with monitoring

Checks one to three share a weakness: they happen when you remember. The durable answer is a monitor that checks daily and alerts at thresholds (30, 14, 7 days) — via your uptime monitoring, a cron job around openssl -checkend, or your certificate platform’s own notifications (Let’s Encrypt emails expiry warnings to registered addresses when renewal has not happened). Alert thresholds should assume automation exists and has failed: with ACME renewing at 30 days out, an alert at 21 days means “the robot missed two attempts” — early enough to fix calmly. The background on why automation occasionally stops is covered in why certificates expire.

Reading the result well

However you check, the goal is the same: make expiry boring. Automate renewal, monitor externally, and keep a bookmark to the expiry checker for the days when you need the answer in five seconds.