How to Check an SSL/TLS Certificate and Prevent Expiry Outages

An expired TLS certificate is one of the most common, most avoidable outages on the web. The moment a certificate passes its "not after" date, browsers and API clients stop trusting it and present a full-page security warning instead of your site. There is no grace period and no soft failure: a checkout flow, a mobile app backend, or an internal dashboard simply stops working for everyone at the same instant.

The frustrating part is that these outages are entirely predictable. The expiry date is printed inside the certificate itself, so the failure is scheduled in advance and visible to anyone who looks. This guide covers what a certificate actually contains, how to inspect one and count its remaining days with the SSL / TLS Check checker, how the certificate chain works, and how to automate renewal and alerting so an expiry never surprises you again.

Although people still say "SSL," the protocol in use today is TLS; the certificate format (X.509) is the same regardless of the name. A certificate is a signed document that binds a public key to one or more identities. The key fields are the subject (the entity the certificate is issued to), the issuer (the certificate authority that signed it), the validity window expressed as "not before" and "not after" timestamps, and the public key itself.

The identities a certificate covers live in the Subject Alternative Name (SAN) extension, not in the legacy Common Name field. Modern clients ignore the Common Name entirely and validate the hostname against the SAN list, so a certificate for "example.com" that lacks "www.example.com" in its SAN will fail on the www host even though the rest is valid. Certificates also carry a serial number, a signature algorithm, and extensions describing how the key may be used.

Your server certificate is rarely signed directly by a root CA. Instead it is signed by one or more intermediate certificates, which are in turn signed by a root that ships in the browser or operating system trust store. To validate the connection, a client must build an unbroken chain from your leaf certificate up to a trusted root.

A surprisingly common failure is a missing or misordered intermediate. The certificate may be perfectly valid, but if the server does not send the intermediate, some clients cannot complete the chain and reject the connection. This often looks like "works in my browser, fails on my phone" because desktop browsers sometimes cache intermediates that mobile clients do not. Always serve the full chain (leaf plus intermediates, root omitted), and confirm it resolves with the SSL / TLS Check tool, which reports each certificate in the chain and flags broken links.

Chain problems can also masquerade as redirect or status errors. If a site forces HTTPS but the certificate fails, your monitoring may surface it as a connection error rather than an expiry; pairing an SSL check with the Website Status and Redirect Checker tools helps you tell a TLS failure apart from an application-level one.

The fastest way to inspect a live certificate is to query the server over the network and read back the parsed fields. The SSL / TLS Check checker connects to your hostname, performs the TLS handshake, and shows the subject, issuer, SAN list, signature algorithm, and both validity dates, then calculates exactly how many days remain before expiry. That single number is the one you should be watching.

If you prefer the command line, OpenSSL gives you the same data locally. Running "openssl s_client -connect example.com:443 -servername example.com" prints the presented chain, and piping that into "openssl x509 -noout -dates" shows the not-before and not-after timestamps. Remember to pass the server name (SNI), because most hosts serve different certificates per hostname and will hand you the wrong one if you omit it.

Publicly trusted TLS certificates have a hard maximum lifetime, currently capped at roughly 398 days (about 13 months). The trend is firmly toward shorter lifetimes: the industry is moving to 90-day and even 47-day maximums over the next few years, with the goal of limiting the damage window if a key is compromised and forcing renewal to be a routine, automated event rather than an annual scramble.

The practical consequence is that manual renewal is no longer viable. If a human has to remember to reissue a certificate every few weeks, an expiry outage is a matter of when, not if. Short-lived certificates are only safe when renewal is fully automated, which is exactly what the ACME protocol was designed to enable.

ACME (Automatic Certificate Management Environment) is the protocol that lets a server prove control of a domain and obtain a certificate without human involvement. Let's Encrypt is the best-known free ACME certificate authority, but many CAs now support the same protocol. A client such as Certbot, acme.sh, Caddy, or your cloud load balancer requests a certificate, satisfies a challenge to prove domain control, and installs the result automatically.

The two common challenge types are HTTP-01, where the CA fetches a token from a well-known path on port 80, and DNS-01, where you publish a TXT record the CA verifies. DNS-01 is required for wildcard certificates and works even when port 80 is closed, but it depends on your DNS being correct and propagated; if validation fails, confirm the challenge record actually resolves with the DNS Lookup lookup tool before retrying.

Best practice is to renew well before expiry, not at the last minute. Most clients attempt renewal when a third of the lifetime remains (around 30 days for a 90-day certificate), which leaves ample room to retry if a renewal fails. Run the renewal on a schedule, reload the web server afterward so it picks up the new certificate, and treat a failed renewal as an alertable event.

Even with automation, you should monitor expiry independently. Automation can silently break: a cron job gets disabled, an API token expires, a DNS challenge starts failing, or a certificate is renewed but never reloaded into the running server. External monitoring catches the gap between "renewal succeeded" and "the live site is actually serving the new certificate."

Set up a recurring check that connects to each hostname and reads the remaining days from the presented certificate, then alert when it drops below a threshold such as 21, 14, and 7 days. Tiered warnings give you escalating urgency without alert fatigue. Run periodic spot checks with the SSL / TLS Check tool against your production hostnames, and include every SAN and subdomain, since it is easy to automate the apex domain and forget a service running on a separate certificate.

A valid, well-monitored certificate is the foundation, but it is not the whole picture. HTTP Strict Transport Security (HSTS) tells browsers to only ever connect over HTTPS, which prevents downgrade attacks and accidental plaintext requests. Note that HSTS makes a certificate failure more severe, because users cannot click through the warning, so reliable renewal becomes even more important once HSTS is enabled.

Round out your configuration with the rest of the security headers: a Content Security Policy, X-Content-Type-Options, Referrer-Policy, and a sensible permissions policy. The Security Headers scanner grades your responses and shows exactly which headers are missing or misconfigured, and pairing it with the SSL / TLS Check check gives you a complete view of your transport security in one pass.

How long are SSL/TLS certificates valid? Publicly trusted certificates currently last a maximum of about 398 days, and the limit is shrinking toward 90 days and below. Internal or private-CA certificates can be configured for longer, but the public web is moving decisively toward short, automatically renewed certificates.

What is the difference between SSL and TLS? They refer to the same goal of encrypting a connection, but SSL is the obsolete predecessor and TLS is the modern protocol actually in use. The certificate format is identical; "SSL certificate" is just the popular name for what is technically a TLS certificate.

My certificate is valid but some clients still reject it. This is almost always a chain problem. The server is likely not sending the intermediate certificate, so clients that do not have it cached cannot build a path to a trusted root. Serve the full chain and verify it with the SSL / TLS Check tool.

Why did my site break right at midnight? A certificate stops being trusted the instant its "not after" timestamp passes, with no grace period. That is why monitoring remaining days and renewing weeks ahead, rather than on the expiry date, is essential. Use the SSL / TLS Check checker to read the exact expiry timestamp for any host.