Skip to content

← Blog

Sysadmins' 6-Step Fix for Expired Intermediate Certificates

By Nick Phillips, Founder

Sysadmins’ 6-Step Fix for Expired Intermediate Certificates

Decorative expired certificate title card

An expired intermediate certificate breaks the chain even if the leaf is perfectly valid, because RFC 5280 requires every certificate on the path to sit inside its own validity window. The immediate fix: serve the correct full chain, reload the affected service, then verify with openssl s_client or curl. Watch for errors like “unable to get local issuer certificate” or “NET::ERR_CERT_AUTHORITY_INVALID.”

TL;DR:

  • Ensuring the full certificate chain is current is critical because an expired intermediate breaks validation even if the leaf certificate is valid.
  • Reloading the server with a correctly assembled fullchain file and purging caches are essential steps to fix expired intermediate issues across platforms.
  • Comparing the Subject Key Identifier and Authority Key Identifier on new intermediates prevents chain failures during certificate rotations.
  • Regularly monitoring and maintaining an inventory of your intermediates and subscribing to CA notices helps prevent unexpected chain breaks.
  • Verifying the chain with tools like openssl s_client or curl confirms the fix, but client-side cache issues may still cause false negatives.
Otterwatch
otterwatch.dev
Catch Certificate Expiry Earlier
Otterwatch watches your SSL certificates and sends a plain, friendly warning before expiry, while quietly checking that your sites remain up.
Visit Otterwatch

Table of Contents

Your emergency checklist to restore trust now

When an intermediate expires, speed matters, but so does doing things in the right order. Here is the sequence we would run if a client called us in a panic.

  1. Check what the server is actually serving: run openssl s_client -connect yourdomain.com:443 -showcerts and look at which intermediate is in the response.
  2. Confirm the intermediate in that output matches a currently valid one from your CA, not a cached or legacy file sitting in an old bundle.
  3. Rebuild the chain file by concatenating leaf and valid intermediate (and root, if required) into a single fullchain file, using the CA-provided fullchain bundle when one exists.
  4. Point your server config at that fullchain file and reload or restart the web server, proxy, or appliance (a graceful reload avoids dropping live connections where supported).
  5. Purge any CDN or appliance edge cache that might still be serving the old chain to visitors.
  6. If the server-side fix will take time, tell affected users to restart their browser or clear local keychain or certificate caches as a stopgap, not a solution.

Pro Tip: Keep a known-good fullchain.pem saved outside your deployment pipeline. When a chain breaks at 2 a.m., having a tested backup file cuts your fix time dramatically.

Escalate immediately if you see widespread client failures across unrelated browsers, broken OCSP or CRL access, or anything that smells like key compromise rather than simple expiry.

Why an expired intermediate breaks everything downstream

Certificate chain interrupted at intermediate layer

RFC 5280 lays out the rule plainly: path validation succeeds only when every certificate between the leaf and the trust anchor is within its validity period. One expired link anywhere in that chain, and the whole thing fails, regardless of how fresh your leaf certificate looks.

In practice, we see a handful of repeat offenders:

  • A server is still serving an old intermediate that was swapped out by the CA, often because the fullchain file was never updated after renewal.
  • Someone configured the cert file and the chain file separately and the chain file got missed during a server config change.
  • Clients vary in how they fetch or cache intermediates; some browsers pull a missing intermediate from the Authority Information Access extension, others simply fail.
  • Teams pin a specific intermediate in code or config, an anti-pattern that breaks the moment the CA rotates it. If you want the fuller picture of how trust gets established in the first place, our certificate chain explainer walks through it.

Fixing it by platform: Apache, Nginx, IIS, and more

The underlying fix is the same everywhere (serve the right chain, reload the service) but the mechanics differ enough to trip people up.

  1. Apache: point SSLCertificateFile at a fullchain file that concatenates your leaf and the current intermediate. If you still have SSLCertificateChainFile set from an older config, remove it or confirm it matches, then run apachectl graceful to reload without dropping connections.
  2. Nginx: set ssl_certificate to your fullchain.pem (leaf plus intermediate) and double check ssl_certificate_key points to the matching private key, then run nginx -s reload.
  3. IIS and Windows: import the correct intermediate into the local machine certificate store, rebind the renewed certificate to the site in IIS Manager, and restart the IIS service for the change to take effect.
  4. Exchange: after updating the chain, rebind the certificate to the relevant services and restart IIS and Exchange services together, since a partial restart often leaves stale connections.
  5. vCenter: back up your current certificates first, prepare the new chain bundle, stop the affected services, replace the chain following vendor KB steps exactly, then restart.
  6. CDNs and appliances: upload the fullchain or intermediate bundle through the provider’s dashboard and purge the edge cache, then confirm the edge configuration actually picked up the new chain.

Our practical fix playbook walks through several of these in more depth if your stack needs extra hand-holding.

Rotating an intermediate without breaking leaf certificates

Not every intermediate update is the same kind of change, and conflating them is how outages happen. A rollover keeps the same key and just issues a new certificate; a key rotation generates an entirely new key pair, which is a bigger deal for anything signed under the old one.

  • Check whether the Subject Key Identifier (SKI) on the new intermediate matches the Authority Key Identifier (AKI) your leaf certificates expect; a mismatch means those leaves will not chain to the new intermediate and need re-issuance.
  • Where possible, run the old and new intermediates in parallel for a transition window and watch CRL and OCSP responses from both before fully cutting over.
  • HashiCorp’s rotation guidance covers the staging steps for Vault-based PKI operators in more detail, including testing with a handful of leaf certs before rolling to production.

Pro Tip: Before any intermediate swap, diff the SKI/AKI values first. It takes thirty seconds and saves you a re-issuance scramble later.

How to confirm the chain is actually fixed

Run openssl s_client -connect yourdomain.com:443 -showcerts and look at the “Certificate chain” section: it should list your leaf at position 0 and a currently valid intermediate right after it, with no gaps.

  • Use curl --verbose https://yourdomain.com to see the TLS handshake and chain details from the command line.
  • Check a browser’s security panel (the padlock icon) for a second opinion, and test on macOS Keychain Access or Windows certmgr.msc if you suspect a locally cached certificate.
  • Test from more than one network. Community reports around the Let’s Encrypt R3 intermediate expiry showed inconsistent client behavior tied to caching, not the server fix itself.

A fix that looks broken in one browser but works in openssl s_client usually points to a client-side cache issue, not a server misconfiguration. Our SSL debugging checklist has a longer walk-through of this diagnostic split.

Preventing the next expiry before it happens

Most of these incidents are avoidable with a bit of housekeeping rather than heroics.

  • Keep a simple inventory of every intermediate in your chains and subscribe to your CA’s notice list so rotations do not catch you cold.
  • Let your ACME client or CI/CD pipeline assemble the fullchain artifact automatically rather than hand-editing bundles.
  • Monitor leaf and intermediate expiry together, plus unexpected changes to the served chain, with early alerts well in advance rather than a single warning close to expiry.
  • Let’s Encrypt’s own guidance on issuance chain changes is worth bookmarking if you are on their infrastructure, since rotations are a recurring event, not a one-off.

For small teams, a focused monitor that flags expiry and chain changes without burying you in dashboards tends to beat a general-purpose tool nobody checks. Our guide to avoiding expiration warnings goes deeper on setting these thresholds.

What running certificate monitoring taught me about expiry panic

Most expired-intermediate incidents trace back to the same small handful of causes: a stale fullchain file, a missed CA rotation notice, or a chain config nobody revisited in years. The fix is rarely clever. It is boring, early, and plain. A single clear alert a month out beats a wall of red dashboards the day something breaks, especially for small teams without a dedicated security engineer watching every chain.

— Nick Phillips

Otterwatch: a calmer way to catch this before it breaks

We built Otterwatch because most certificate monitoring is built for large ops teams, full of graphs nobody reads until something is already on fire. Our approach is narrower on purpose: we watch your SSL certificates, including intermediates, and flag expiry and chain changes early, with a plain-language heads up instead of alarm language.

Otterwatch

  • Monitoring is free for a limited number of domains, with no credit card required to start.
  • Reachability is checked too, so you get a sense of uptime alongside certificate health without a second tool.
  • Our Pro plan at $15 per month adds deeper monitoring and change-detection for teams managing more than five domains.

If you want a quick read on where your current chain stands, our free SSL certificate checker gives you an answer in seconds, no account needed.

FAQ

What happens if a certificate is expired?

Once a certificate, leaf or intermediate, passes its expiry date, clients reject the entire connection as untrusted per RFC 5280’s path validation rules. Browsers typically show a security warning, while APIs and mail servers may fail silently or log a handshake error.

How to fix expired certificate?

Confirm what your server is actually serving with openssl s_client -showcerts, then replace the expired certificate or intermediate with a current one assembled into a proper fullchain file. Reload or restart the affected service and verify the fix with curl --verbose or a browser security panel before considering the incident closed.

What happens if a digital certificate is expired?

The same path validation failure applies to any digital certificate in the chain, not just the leaf: an expired link anywhere between your site’s certificate and the trusted root breaks the whole chain. This is why checking the full chain, not just the certificate you remember renewing, matters during troubleshooting.

How do I renew an expired certificate?

For a leaf certificate, request a new one from your CA and deploy the updated fullchain bundle it provides. For an intermediate, your CA typically handles rotation on its end, so your job is usually just updating your fullchain to include the new intermediate, a process HashiCorp’s PKI rotation guidance describes in more operational detail for Vault-managed setups.

Sources

For readers who want the primary sources behind this guide: RFC 5280 is the standard defining certificate path validation and revocation behavior. Let’s Encrypt’s issuance chain guidance covers how intermediate rotation works in practice for one of the largest public CAs. HashiCorp’s rotation documentation is useful for Vault-based PKI operators handling their own intermediate lifecycle, and vendor knowledge bases remain the best source for platform-specific remediation steps beyond what any general guide can cover.

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 →