Skip to content

← Blog

Sysadmins' Runbook: Avoid Token Breaks from Client Certificate Expiry

By Nick Phillips, Founder

Sysadmins’ Runbook: Avoid Token Breaks from Client Certificate Expiry

Certificate renewal runbook title card

Client certificate expiry means the certificate’s “Not After” date has passed, and once that happens, mutual TLS handshakes and other client-cert-protected connections start failing authentication. The fix is straightforward: check the expiry date now with a quick command or scan, and if you don’t already have monitoring in place, set it up before this becomes a 2 AM problem.

TL;DR:

  • Monitoring should be set up to detect upcoming certificate expiry at thresholds like 60, 30, 14, and 7 days to prevent unexpected outages.
  • Renew certificates at least one month before expiry for ACME-managed certs, or 40 to 60 days ahead for manual renewals, to avoid failures.
  • When certificates expire, mutual TLS handshakes fail, causing connection errors, authentication issues, and invalidated OAuth tokens tied to the certificates.
  • Check expiry dates regularly with local commands, remote scans, browser inspection, or automated tools, ensuring served certificates match expectations.
  • The industry trend toward shorter validity periods, such as 47-day options from Let’s Encrypt, increases renewal frequency, emphasizing the importance of automation and proactive management.
Otterwatch
otterwatch.dev
Keep Certificate Expiry in Sight
Otterwatch watches your SSL certificates and sends a plain, friendly warning before expiry, while quietly checking that your sites are up.
Visit Otterwatch

Table of Contents

What client certificate expiry is and common validity lengths

Every X.509 certificate carries two dates that define its life: Not Before, which marks when it becomes valid, and Not After, which marks the moment it stops being trusted. Once you pass Not After, the certificate is dead weight. It doesn’t matter how strong the key is or how clean the chain looks; clients and servers will reject it outright.

Lifetimes vary a lot depending on who issued the cert:

  • Let’s Encrypt leaf certificates run 90 days, with a shorter 47-day option now available for domains that opt in.
  • Commercial CAs typically issue leaf certs valid for up to 397 days, the current ceiling for public TLS certificates.
  • Intermediate and root CA certificates live much longer, often a decade or more, since they anchor trust for everything below them.

The industry is moving toward shorter lifetimes across the board, which means renewal frequency is going up. If your renewal process still depends on someone remembering to do it manually, that gap is going to catch you eventually.

Why certificates expire in the first place

Expiry isn’t bureaucratic friction. It’s a deliberate control, and it does two jobs at once.

  • On the security side, a fixed lifetime limits how long a compromised private key stays useful, and it forces periodic upgrades as algorithms and key sizes evolve.
  • On the operational side, expiry forces subject details, like domain names or organizational attributes, to stay current, and it lets certificate authorities retire outdated policies without waiting forever for old certs to age out.

Shorter lifetimes tighten both benefits, but they also raise the bar for automation. A 90-day cert that fails silently is a problem in three months. A 47-day cert gives you half the runway to notice.

What happens when a client certificate expires

The moment a client certificate passes its Not After date, mutual TLS handshakes involving that certificate stop succeeding. Any endpoint that requires client-cert authentication, whether it’s an internal API, a partner integration, or a device management channel, will reject the connection instead of authenticating it.

From the user or application side, this shows up as connection errors, 401 or 403 responses, or in worse cases, an app that fails quietly because nobody built proper error handling around cert failures. Certificate-related outages are one of the more preventable categories of service disruption, largely because the failure date is knowable well in advance, unlike most infrastructure incidents.

There’s a less obvious consequence too: if the certificate was tied to an OAuth access token under RFC 8705’s mutual-TLS binding, rotating or losing that certificate invalidates the bound tokens. Sessions built on top of that authentication don’t just pause, they need to be reestablished from scratch.

What happens when a client certificate expires — overview diagram

How to check client certificate expiry

You have a few ways to check expiry, ranging from a five-second local command to fleet-wide automated scans.

  1. Local file check: run openssl x509 -enddate -noout -in cert.pem to pull the Not After date straight out of a PEM file on disk.
  2. Remote server check: run openssl s_client -connect host:port | openssl x509 -noout -dates to see both Not Before and Not After for whatever certificate a server is presenting live.
  3. Browser inspection: click the padlock icon in any browser to view certificate details, including expiry, for a quick ad-hoc look without touching a terminal.
  4. PEM parsing tools: dedicated expiry-checker utilities extract validity dates and flag how much time is left, which is handy when you’re checking one cert instead of scripting a whole fleet.
  5. Automated fleet checks: ACME clients like certbot, cloud certificate managers, and scheduled exporters can track expiry across hundreds of endpoints and feed the results into your monitoring stack; our own walkthrough on building a certificate expiration check script covers a practical setup.

Pro Tip: Run the remote openssl s_client check against production hosts periodically, not just staging. It’s the only way to be sure the certificate actually being served matches what you think is installed.

Renewal best practices: timing, retries, and deployment

Timing is where most renewal failures start. Automated ACME workflows can generally cut things closer, since they’re designed to retry quickly, but manual or approval-gated renewals need much more lead time.

  • For ACME-managed certificates, renewing about a month before expiry gives enough buffer for a failed attempt or two.
  • For manual or MDM-driven renewals, Microsoft’s certificate renewal guidance recommends starting 40 to 60 days out, with retry intervals spaced every few days so a single transient failure doesn’t sink the whole renewal.
  • Set alert thresholds at multiple points, commonly 60, 30, 14, and 7 days out, so you get escalating nudges instead of one warning that’s easy to miss.
  • Before calling a renewal done, walk through the full sequence: generate the new key, confirm the chain trust resolves cleanly, deploy to every endpoint that needs it, then validate that authentication and service health actually recover.

That last step trips people up more than any other part of the process. Issuance isn’t renewal, deployment isn’t renewal, only a validated, working connection is.

Operational edge cases: tokens, long connections, and MDM flows

A few scenarios don’t behave the way a simple “swap the cert” mental model suggests.

Under RFC 8705, OAuth access tokens can be bound to a specific client certificate. Rotate the certificate and those bound tokens stop working, so your renewal runbook needs a token refresh step, not just a cert swap.

Certificate rotation and token refresh flow

Long-lived TLS sessions are another quiet risk. An IETF draft on in-connection certificate updates describes a mechanism for updating certificates without tearing down an existing TLS 1.3 connection, but support isn’t universal yet. Until it is, plan for reconnects: build connection draining into your rollout and test that persistent APIs and messaging channels reestablish cleanly after a swap.

Windows MDM flows have their own wrinkle. Automatic renewal there can generate an entirely new key pair and delete the old certificate once the new one is issued.

A renewal isn’t finished the moment a new certificate is issued. It’s finished when the client has installed it, the server accepts the issuing chain, and authentication succeeds end to end.

Test the full path, not just the issuance step.

Monitoring and alerting for certificate expiry

Good certificate monitoring is less about catching every possible edge case and more about making sure the alerts you do send are ones people actually act on.

  • Set alerts at multiple thresholds, and include the specific host, days remaining, and a direct link to fix it, not a generic “a certificate is expiring somewhere” notice.
  • Pair expiry checks with chain validation and basic reachability checks, since a cert that hasn’t expired but is misconfigured or unreachable will still cause outages that a pure expiry check misses.
  • Lean on automation for anything that can be automated. Monitoring should be the safety net for certificates that, for whatever reason, can’t be put on an ACME or MDM auto-renewal path.

Pro Tip: If an alert doesn’t tell you which host and how many days you have left, it’s noise. Rewrite it before you ship it. Our breakdown of alert types worth setting up has more on getting the content right, not just the timing.

Practical checklist for a certificate that’s near or past expiry

When you’re staring down an expiring or already-expired cert, work through this in order:

  1. Inventory every endpoint, service, and downstream consumer that relies on the certificate, since missing one is how partial outages happen.
  2. Obtain the replacement certificate and confirm its chain resolves correctly before deploying it anywhere.
  3. Install it everywhere it’s needed, then validate trust and authentication on each endpoint individually rather than assuming one success means they all worked.
  4. Refresh any bound tokens and notify clients that need to reconnect, particularly for mTLS or OAuth flows tied to the old certificate.
  5. Watch post-deploy health closely for the next few hours; a clean deploy that silently fails validation somewhere is the most common way these incidents drag on longer than they should.

Why we built certificate monitoring around expiry first

We built Otterwatch because most monitoring tools bury certificate expiry under dashboards meant for teams with dedicated ops staff. Otterwatch checks your SSL certificates and gives you a plain heads up well before Not After arrives, with uptime checks running quietly alongside. Free monitoring for a limited number of sites means a small team can get coverage without setting up anything complicated first.

— Nick Phillips

A calmer way to keep track of expiry dates

Manual openssl checks and cron jobs work, but they only work if someone maintains them. Otterwatch A service watches your certificates and reachability from one calm interface, with plain email alerts instead of dashboards full of red. It’s free for a small number of domains with no credit card required, and a paid plan adds deeper monitoring and change-detection for teams managing larger numbers of certificates. If you want to see where a certificate stands right now, run it through the free SSL certificate checker, or set up ongoing alerts on the pricing page. It’s a solid fit for solo operators and small teams who want expiry handled without babysitting a script, and pairing that with a routine technical health check covers the rest of your stack too.

Sources

FAQ

How long does a client certificate last before expiring?

It depends entirely on the issuer. Public CAs cap leaf certificates at up to 397 days, while Let’s Encrypt issues 90-day certificates by default, with a shorter 47-day option available for domains that opt in.

Why is certificate expiration moving toward 47 days?

Shorter lifetimes limit how long a compromised key stays usable and push the industry toward more automated renewal instead of manual, error-prone processes. Let’s Encrypt’s 47-day option is part of that broader shift toward shorter validity windows.

Does every certificate have an expiration date?

Yes. Every X.509 certificate includes a Not Before and Not After date, and once Not After passes, clients and servers will reject the certificate regardless of how it was configured otherwise.

What should I do immediately if my certificate has already expired?

Get a replacement certificate issued and installed on every affected endpoint as fast as possible, then validate that authentication actually succeeds rather than assuming installation alone fixed it. If the certificate was tied to OAuth access tokens under RFC 8705, refresh those tokens too, since they invalidate when the bound certificate changes.

Catch the next cert expiry before your users do.

Otterwatch checks your SSL certificates daily and emails you 30 days before they expire. Five sites free.

Start watching →