Certificate Expiry Checker

The Certificate Expiry Checker extracts validity dates from X.509 certificates and calculates exactly how many days, hours, and minutes remain until expiration -- helping prevent outages caused by expired SSL/TLS certificates, one of the most common causes of service disruption. Paste one or more PEM certificates and get a color-coded countdown for each.

Understanding Certificate Expiry

Expired certificates are one of those problems that should never happen but somehow always do. Every X.509 certificate has a built-in expiration date, and when that date passes, clients will refuse to connect. Browsers show a full-page warning, API clients throw TLS errors, and mobile apps silently fail. The result is always the same: users cannot reach your service, and your team scrambles to figure out what went wrong. The answer is almost always a certificate that nobody remembered to renew.

The reason this keeps happening is that certificate renewal is often a manual process managed by a person who might leave the team, or it is automated but the automation breaks silently. Let's Encrypt certificates expire every 90 days, and commercial certificates last 397 days at most. In either case, you need a way to check how much time you have left. Running openssl x509 -enddate on each certificate works, but it is tedious when you have dozens of certificates across multiple servers, load balancers, and CDN endpoints.

This checker simplifies that workflow. Paste a single certificate or an entire chain, and you immediately see the Not Before and Not After dates with a clear countdown. Certificates approaching expiry are highlighted in yellow or red so you can prioritize renewals. For teams that do periodic certificate audits, this is faster than SSH-ing into each server and running OpenSSL commands one at a time.

How to Check Certificate Expiry

1. Paste one or more PEM-encoded certificates (starting with -----BEGIN CERTIFICATE-----)
2. The checker displays Not Before and Not After dates for each certificate
3. Review the countdown showing days remaining, color-coded by urgency
4. Identify certificates that need renewal attention first

Example Expiry Check Output

Pasting a certificate chain with three certificates:

Status Color Coding

When to Use This Tool

• Routine certificate audits -- paste all your certificates to get a sorted view by expiration date, identifying which need renewal first
• Pre-deployment verification -- confirm a newly issued certificate has an adequate validity period before installing it on production servers
• Incident investigation -- quickly determine if a TLS handshake failure was caused by an expired certificate
• Renewal planning -- build a renewal schedule based on actual expiration dates across your infrastructure
• Batch checking -- paste an entire certificate chain or bundle to check all certificates at once rather than running individual openssl x509 -enddate commands
• Monitoring gap coverage -- spot-check certificates on systems where automated monitoring is not yet deployed

How Certificate Validity Works

Every X.509 certificate contains two date fields that define its validity window:

• Not Before (notBefore) -- the certificate is not valid before this date. Attempting to use a "not-yet-valid" certificate causes TLS handshake failures just like an expired one.
• Not After (notAfter) -- the certificate expires at this exact moment. After this timestamp, clients must reject the certificate.

Common Validity Periods

Since September 2020, the CA/Browser Forum limits publicly trusted leaf certificates to a maximum of 397 days. This means regular renewal is unavoidable for all production HTTPS certificates.

Clock Skew Considerations

Certificate validation depends on the client's system clock. A server with a clock set 48 hours behind will treat certificates as valid for an extra 48 hours -- and will reject certificates as "not yet valid" for 48 hours after issuance. NTP synchronization is critical for reliable TLS.

Managing Certificate Expiry in Practice

The single best thing you can do to avoid certificate-related outages is to automate renewal. Tools like certbot, ACME clients, and cloud provider certificate managers handle renewal and deployment automatically, removing the human-memory dependency that causes most expiry incidents. If you use Let's Encrypt, certbot renews certificates at 30 days before expiry by default and can reload your web server configuration automatically.

For certificates that cannot be auto-renewed -- commercial EV certificates, certificates for systems without ACME support, or certificates managed by external teams -- you need a tracking system. A shared spreadsheet is better than nothing, but a monitoring tool that sends alerts at 30, 14, and 7 days before expiry is far more reliable. Many teams use this checker as part of a monthly audit routine: export certificates from all servers, paste them into the tool, and review the countdown for anything approaching the danger zone.

Do not forget about intermediate and root certificates in your chain. While these expire far less frequently than leaf certificates, an expired intermediate will break every leaf certificate it signed. Some of the largest certificate outages in history were caused by intermediate CA certificates expiring without anyone tracking them. Always check the full chain, not just the leaf.

Frequently Asked Questions

Why do certificates expire? Certificate expiration serves several security purposes. It limits the exposure window if a private key is compromised. It forces periodic re-validation of domain ownership. It ensures organizations adopt current cryptographic standards. Shorter lifetimes (like Let's Encrypt's 90-day certificates) encourage automation and reduce the risk from key compromise.

How far in advance should I renew certificates? Renew at least 30 days before expiration. Let's Encrypt recommends renewing at 60 days (one-third of the 90-day lifetime). For manual renewal processes, start at least 2 weeks early to allow time for approval, issuance, and deployment. Automated systems (certbot, ACME clients) typically renew at 30 days remaining.

Can I check a live server's certificate expiry without having the PEM file? You can retrieve the certificate using OpenSSL: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates outputs the Not Before and Not After dates. Paste the full PEM output into this tool for a more detailed view.

What happens when an intermediate certificate expires? If an intermediate CA certificate in your chain expires, all leaf certificates signed by it become untrusted -- even if the leaf certificates themselves have not expired. This is why checking the entire chain is important, not just the leaf certificate.

Why does my new certificate show "not yet valid"? The Not Before date on a certificate can be set to a future time. If the issuing CA's clock and your clock are slightly out of sync, or if the CA intentionally sets a future start date, the certificate will be invalid until that time arrives. Ensure your server's clock is synchronized via NTP and wait for the Not Before date to pass.

How do I automate certificate expiry monitoring? For small environments, a cron job running openssl x509 -checkend 2592000 (checks if the certificate expires within 30 days) and sending an email notification works well. For larger environments, tools like Prometheus with the blackbox exporter, Nagios/Icinga check_ssl_cert plugins, or dedicated certificate management platforms provide comprehensive monitoring with dashboards and alerting.

Related Tools

• X.509 Certificate Viewer - View full certificate details beyond just expiry dates
• PEM Bundle Splitter - Split certificate chains to check each certificate individually
• Certificate Fingerprint Generator - Generate fingerprints for tracking certificates across environments
• SAN Extractor - Verify which domains a certificate covers before renewal
• CSR Viewer - Inspect a Certificate Signing Request before submitting for renewal