When does your TLS certificate expire, and what happens when it does?

Your certificate is valid today. You know because the padlock is there and nobody's complained. So here's the only question that matters: what date does it expire, and is anything actually going to renew it before then?

If you can't answer that in one breath, you're relying on a renewal you've never watched run. Certs don't fade. They work perfectly right up to a timestamp, and then every browser on earth stops trusting them at the same instant.

The overnight wall

When a cert expires, your site doesn't slow down or degrade. It hits a full-screen interstitial. NET::ERR_CERT_DATE_INVALID in Chrome, a red warning in Safari and Firefox, and a button most visitors will never click that says "proceed anyway." To a normal person that screen says one thing: this site is broken, possibly dangerous, leave.

The mechanism is unforgiving on purpose. Browsers check the cert's notAfter date against the clock on every connection. One second before, trusted. One second after, hard-blocked, no content rendered. It usually happens at the worst time, because nobody schedules an expiry for a Tuesday afternoon. It happens at 2am, or over a holiday, or the weekend you're away, and your first signal is a customer asking why your site is "showing a virus warning."

The slower version: an old TLS floor

Expiry is the loud failure. There's a quieter one that scanners catch and humans rarely do: the cert is fine, but your server still negotiates TLS 1.0 or TLS 1.1.

Those versions are deprecated and broken. Browsers dropped support years ago, so visitors on a current Chrome or Safari may already be getting connection errors you never see, because your own browser negotiated a newer version and looked fine. An attacker, meanwhile, is happy to find an old TLS floor. Downgrade attacks and known weaknesses in those versions exist precisely to pry open connections that should have been sealed. A modern server should negotiate TLS 1.2 at minimum, and 1.3 where it can.

How to check without waiting for the outage

You can read the expiry date yourself in seconds.

1. Click the padlock in your browser, open the certificate details, and read the "valid until" date. Put it in a calendar with a reminder a week ahead.
2. From a terminal: echo | openssl s_client -connect yoursite.com:443 2>/dev/null | openssl x509 -noout -dates. That prints notBefore and notAfter straight from the live cert.
3. Don't trust your own browser to tell you about old TLS. It picks the newest version available, so it can't show you that TLS 1.0 is still on the menu for someone else.

The expiry date is a fact already sitting in your live certificate, and SurfaceCheckr reads it the same way a visitor's browser does: it opens a real connection, pulls the notAfter date, flags whether you're inside a warning window, and probes which TLS versions your server will still negotiate. We won't renew anything for you, and we have no login or backend access to do it with. We just hand you the date and the version floor from outside, before a customer does it for you.

Stop renewing by hand

Manual renewals fail because they depend on a human remembering. Automate it and the expiry stops being an event.

# you, once a year, by hand:
#  1. generate CSR
#  2. paste into the CA portal
#  3. download the cert
#  4. install it, reload the server
#  5. forget for ~360 days

If you're behind a managed platform or CDN, the cert is usually handled for you, but custom domains and apex records are exactly where that automation quietly doesn't apply. Verify it rather than assume it.

While you're confirming the cert renews, make sure plain HTTP isn't still serving content around it, because a site that answers over http:// undoes the cert entirely, and a missing HSTS header leaves the first request exposed even when the cert is perfect.

Go read your "valid until" date right now. If you had to look it up, nothing is watching it for you.