How to check SSL certificate expiration and get alerted in time

To check when an SSL certificate expires, you have three options: click the padlock in your browser, run one openssl command, or read the handshake output of curl. Each takes under a minute and tells you the notAfter date of the certificate the server is presenting right now. That is the easy part. The hard part is that certificates now live 90 days, soon 47, so a date you checked last quarter says nothing about today. This guide covers the one-off check first, then how to put the date under daily monitoring so that a broken renewal reaches you before it reaches your users. It is about the certificate, not the domain name: domain expiration is a registry matter with its own calendar.

Read the expiry date in the browser

Click the padlock (or the site information icon) left of the address. In Chrome, open "Connection is secure" then "Certificate is valid"; in Firefox, "Connection secure" then "More information" and "View certificate"; in Safari, "Show certificate". The certificate viewer shows a validity period with two dates. The second one, labelled "Valid until" or "Not after", is the expiry. Browsers display it in your local time zone, but the certificate stores it in UTC, so a certificate that "expires at 01:59" may already be dead for a user two time zones east.

This is enough to check a third-party site or to answer a colleague who saw a warning. It is not enough to check your own infrastructure, because a browser only shows you one hostname at a time and only the one you thought of.

Check with openssl and curl on the command line

The openssl command to know

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

The output gives notBefore, notAfter, the issuer and the subject. Keep the -servername flag: it sends the hostname in the TLS handshake (SNI), and without it a server hosting several sites hands you its default certificate, which may be a different one from the site you wanted to check. Many "the certificate is fine on my machine" mysteries come from checking without SNI.

Test a threshold in a script

openssl s_client -servername example.com -connect example.com:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -checkend 1209600 \
  || echo "example.com expires within 14 days"

-checkend takes a number of seconds (14 days here) and exits with a non-zero code if the certificate will have expired by then. That exit code is what a cron job or a CI step needs.

curl and a local file

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

curl prints the dates of the certificate it negotiated, which is handy on a machine without openssl. For a certificate file in a deployment pipeline, before it is even served:

openssl x509 -in cert.pem -noout -enddate

Why a one-off check is no longer enough

Certificate lifetimes have been shrinking for a decade, and the CA/Browser Forum has voted the next steps.

Certificate	Maximum lifetime
Let's Encrypt (default)	90 days
Any public certificate since March 2026	200 days
Any public certificate from March 2027	100 days
Any public certificate from March 2029	47 days

At 47 days, nobody renews by hand. Renewal is automated, and automation fails in silence: a DNS challenge breaks after a DNS migration, someone adds a CAA record that excludes the issuer, an API token expires, a subdomain outlives the person who owned it. The cron job logs an error nobody reads, and the old certificate keeps working until the day it does not. The guide to failed Let's Encrypt renewals lists the causes; the one on what happens when a certificate expires covers the damage. The point here is simpler: with short certificates, what you monitor is the renewal, and the only reliable witness is the certificate served from outside.

Put the expiry date under monitoring with Domain Sentinel

Add the domain to your watchlist and enable TLS certificate monitoring. Leave the hostname empty to check the domain itself, or enter www or api if HTTPS lives there. From then on, Domain Sentinel connects to that host every day, reads the certificate as a browser would, and keeps a snapshot whenever something changes: issuer, dates, fingerprint. You get an email 14, 7, 3 and 1 days before expiry, and an alert at the next check if the certificate has expired, is self-signed, is issued for another name, or comes from a different issuer than before. A "Check now" button runs the same check on demand.

The limits, stated plainly: one hostname per watched domain, no automatic discovery of your subdomains, and no renewal on your behalf. Build your inventory of public hostnames yourself (site, www, api, mail), the guide to certificate transparency monitoring shows how, and add each one. This is not uptime monitoring either: it reads the certificate, it does not check that the page loads, a distinction the comparison of DNS monitoring and uptime monitoring explains.

What the alert thresholds mean for your certificates

The thresholds are fixed at 14, 7, 3 and 1 days, and the absence of a 30-day alert is deliberate. Let's Encrypt renews a 90-day certificate when 30 days remain, so an alert at 30 days would fire on every healthy cycle and train you to ignore it. Fourteen days means the renewal that should have happened did not, and you still have two weeks.

Your certificate	How to read the alerts
One-year certificate, renewed by hand	14 days is comfortable for a manual renewal; treat the 7-day alert as urgent
90-day certificate, automated	Any alert means the automation broke; the issuer change alert is your confirmation that a renewal actually happened
47-day certificate	Same logic, with less slack: check the renewal job the day the 14-day alert arrives

Do it now

Run the openssl command against your main hostname and read notAfter. List every hostname that serves HTTPS, including the ones you forgot about, and add each to a watchlist with TLS monitoring on. Then stop checking dates by hand: with 90-day certificates, the calendar is not the thing to watch, the renewal is.