SSL Certificate Expiry Checker for PEM Certificates

How to use the certificate expiry checker

1. Get the certificate as PEM. From a live server, run openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -outform PEM.
2. Paste the block, with its BEGIN and END lines, into the box.
3. Leave the check date empty to compare against the current time on your device, or enter a UTC date to see the status on that day.
4. Read the status and days remaining, then review the warnings for weak signatures, small keys or missing SANs.

How the days remaining are calculated

Every certificate stores two UTC timestamps, Not before and Not after. This ssl certificate expiry checker subtracts the check time from Not after and rounds down to whole days. For the example certificate, Not after is 2026-03-01 12:30:45 UTC. Checked on 2026-02-15 at midnight UTC, the difference is 14 days and about 12.5 hours, so the result is 14 days.

After expiry the value turns negative and counts whole days since the certificate ended. All times are UTC, so a certificate that ends at midnight UTC is already expired that evening in the Americas.

What the status values mean

The same date field lets you plan ahead. Enter the date of a release or a holiday freeze to see whether a certificate will still be valid then.

Warnings and why they appear

The Warnings row is None for a healthy certificate. Otherwise it lists one or more of these:

• Weak signature algorithm: MD2, MD4, MD5 and SHA-1 signatures are obsolete. Public CAs stopped issuing SHA-1 TLS certificates in 2016 and browsers reject them.
• RSA key below 2048 bits: 1024-bit RSA can be attacked with enough resources and is not accepted by public CAs.
• No Subject Alternative Names: modern clients match the hostname against SANs, so a certificate without them fails hostname checks.

The Self-signed row compares the encoded issuer and subject. Root CA certificates are self-signed by design, while a self-signed server certificate triggers trust warnings in browsers. To see every field, open the same file in the SSL certificate decoder.

Certificate lifetimes and renewal timing

Lifetimes keep getting shorter. Let's Encrypt issues 90-day certificates, and public CAs have been limited to 398 days since September 2020. The CA/Browser Forum has approved a schedule that lowers the maximum to 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029.

With short lifetimes, automated renewal matters more than reminders. A common rule is to renew when one third of the lifetime is left, which is 30 days for a 90-day certificate. The 30 day threshold in the status row is a practical warning for longer certificates.

Mistakes when checking expiry

• Checking the wrong certificate. A server sends the leaf first, then intermediates. An intermediate can expire years after the leaf, so check each one.
• Trusting the device clock. If the clock is wrong, so are the days. Set a check date when in doubt.
• Pasting only part of the block. A missing line makes the base64 invalid and the tool reports an error instead of a guess.
• Forgetting the load balancer. The file on disk can be new while the device still serves the old certificate. Check what the server presents.

If you only have a binary .cer file, convert it with the certificate converter first. For a pending request, decode it with the CSR decoder.

Worked examples