SSL Certificate Expiration: How to Check It and Why It Matters

An SSL/TLS certificate expires on a fixed date written inside it, and once that moment passes browsers stop trusting the connection and block the site by default. The expiry lives in the notAfter field (shown as "Valid to" in most viewers), and checking it takes seconds. What makes expiration worth real attention is the failure mode: there is no grace period, no soft warning for visitors, just a hard stop the instant the clock runs out. If you want the broader context for why certificates carry an expiry at all, SSL/TLS certificates explained covers the trust model behind it.

Certificates are time-bound by design, a property baked into the X.509 profile in RFC 5280, and the maximum lifetime is capped by industry policy rather than left to whoever issues them. That cap has been shrinking for years, which changes how you should manage renewals. First, though, here is where the date lives and how to read it.

Where the expiry date lives

The notAfter value sits inside the certificate itself, so any of the standard tools surface it. The browser padlock shows it under certificate details. An online checker prints it alongside a days-remaining countdown. On the command line, openssl reads it directly:

openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

For step-by-step instructions on each of those approaches, see how to check a website's SSL certificate. The key point is that the countdown is public information; anyone, including your visitors' browsers, can read exactly when your certificate dies.

What breaks when it lapses

When the date passes, the browser does the enforcing. Visitors hit a full-page interstitial warning them the connection is not private, and clicking through is deliberately awkward (sometimes blocked entirely by policy). The practical effect is downtime, even though your server is healthy and still serving traffic.

Consequence	Who feels it
Full-page browser block	Every visitor on a modern browser
Lost user trust	Customers who see a scary warning and leave
API and integration failures	Apps and services that refuse expired certificates
Search and ranking impact	Crawlers that flag or skip the broken site
Emergency manual renewal	Your team, usually at a bad hour

The expired-certificate warning is one of the most common reasons a site appears "down" without any code change. If you are decoding a specific message a browser shows, common SSL errors maps the wording to the cause.

Validity periods keep getting shorter

Certificate lifetimes have fallen sharply over the last decade, driven by the CA/Browser Forum, the body whose Baseline Requirements set the rules every public certificate authority follows. The current maximum is 398 days, and the Forum has approved a phased reduction that will tighten that ceiling further in the years ahead.

Era	Approximate maximum validity
Earlier years	Multi-year certificates (up to several years)
Mid 2010s onward	825 days, then reduced
Current	398 days (CA/Browser Forum)
Trend	Shorter still, via approved phased reductions

Shorter lifetimes are a security improvement: a compromised or misissued certificate stays dangerous for less time, and key material rotates more often. The trade-off is operational. Renewing by hand once a year was a forgettable chore; doing it every few months across many domains is a recipe for the one you miss taking a site down.

Automation is the real fix

Because the cap is dropping, manual renewal does not scale. The answer is the ACME protocol, the automated issuance standard that tools like Let's Encrypt use to reissue certificates on a 90-day cycle without anyone touching a server. A client requests, validates domain control, installs, and repeats well before expiry. Set it up once and the countdown quietly resets itself.

Automation still needs a backstop. Renewal can fail silently: a DNS change breaks validation, a cron job dies, a firewall rule shifts. Independent monitoring that alerts you days before notAfter catches those gaps before visitors do. The two together, automated renewal plus external expiry alerts, are what keep a site from ever showing that warning.

Don't get caught out

Expiration is predictable, which makes it preventable. Know your notAfter date, automate renewal where you can, and watch the countdown from outside your own infrastructure.

Run a free SSL check at the site root to see exactly when any domain's certificate expires, along with its issuer and protocol.