SSL certificate expiry checker

Why expiry checks matter more every year

An expired certificate turns a working site into a scary one in an instant. Browsers show a full-page warning, API clients refuse to connect and mail servers may drop deliveries. It is one of the most common and most avoidable outages. This page connects to the host, reads the certificate it serves and tells you the expiry date, the days left and the names the certificate covers.

Lifetimes are shrinking too. The CA/Browser Forum, where browsers and certificate authorities agree the rules, has decided that publicly trusted certificates may be valid for at most 200 days when issued from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Renewing by hand once a year is already off the table, and by 2029 a manual renewal would come round every few weeks.

How to check and track expiry

1. Check each public nameEnter every hostname that serves HTTPS, including www, API and mail hosts. A wildcard certificate may cover many of them, but each endpoint can serve a different certificate.
2. Read the days leftA healthy certificate reads “Valid and trusted” with the days remaining. At 30 days or fewer the headline turns into “Expires in 23 days” with a Renew soon label. Under 15 days usually means your renewal process is broken.
3. Set a reminder or automateAdd calendar reminders, and set up automatic renewal so you never depend on them.

Understanding the dates

The days left tell you what to do next. The ring on the result shows them against the certificate's whole lifetime, so a 90-day certificate with 10 days left looks nearly empty. The bands below suit 90-day certificates. As lifetimes shrink, scale them down, since renewal is usually due with about a third of the life left.

• Intermediate and root expiry. Every certificate in the chain has its own dates, and the Chain tab lists them. A leaf with months left can still fail if an intermediate on the server has expired.
• Several certificates behind one name. A load balancer may serve different certificates from different nodes. Check again if the date seems to change between attempts.
• Not the domain expiry. The certificate and the domain registration are separate. Check the registration with the domain expiration checker.

Why renewals fail

• Validation can't complete. HTTP validation needs port 80 open and the right path. DNS validation needs working API credentials for your DNS host.
• Renewed but not reloaded. The new file exists, but the web server still serves the old one from memory. Add a reload hook to the renewal.
• Hosting changed. A migrated site kept the old server's cron job, or none at all.
• CAA blocks the CA. A new CAA record, or a switch of certificate authority without updating it, makes issuance fail. A CAA lookup shows which authorities are allowed.
• Rate limits. Repeated failed attempts can trigger a certificate authority's limits. Fix the cause before you retry.
• Forgotten endpoints. Staging sites, mail servers, VPN gateways and admin panels often have manual certificates that nobody tracks.

How the check works and the standards

LookupOwl performs a TLS handshake with the correct server name, reads the leaf certificate's validity period and subject alternative names, and counts the days remaining in UTC. Automatic issuance and renewal use the ACME protocol (RFC 8555). Validity rules are set by the CA/Browser Forum Baseline Requirements (ballot SC-081), and certificate fields are defined in RFC 5280. For the chain, key and protocol details, use the full SSL checker.

# The expiry date, from a terminal
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate
# Exit code 0 if valid for at least 30 more days
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -checkend $((30*86400))