How to Fix an Expired Intermediate SSL Certificate

Most certificate problems announce themselves. This one does not. When an intermediate certificate in your chain expires, your own certificate stays valid, your monitoring stays green, and the site keeps loading perfectly on the machine you check it from. Meanwhile some share of your visitors cannot reach you at all, and the ones who can see nothing wrong.

That combination is what makes an expired intermediate worth understanding separately from an expired certificate. The failure is real, it is total for the clients it affects, and almost every signal you would normally trust tells you the site is fine.

Quick answer:

An expired intermediate certificate breaks the chain of trust between your certificate and the Certificate Authority’s root, even though your own certificate is still inside its validity period. Certificate validation checks the dates on every certificate in the path, not just yours, so one expired link invalidates the whole chain. It often goes unnoticed because desktop browsers can usually obtain a current replacement intermediate on their own, while older OpenSSL versions, API clients and other non-browser software cannot, and mobile clients manage it far less reliably, so the site breaks for some visitors and not others.

The fix is on the server: download your CA’s current chain bundle, replace the expired intermediate in your chain file, keep the order leaf first then intermediates, test the configuration, and reload the web server. Do not reissue your certificate, it is not the problem.

What an Expired Intermediate Certificate Actually Breaks

A browser does not trust your certificate directly. It trusts a small set of root certificates shipped in its trust store, and everything else has to connect back to one of them through a chain:

1. The leaf certificate, issued for your domain. This is the one you ordered, renewed, and think of as “your certificate”.
2. One or more intermediate certificates that signed it. Certificate Authorities issue from intermediates rather than directly from their roots, so this link is present in essentially every real chain.
3. The root certificate, which signed the intermediate and which the client already trusts.

Every one of those certificates carries its own notBefore and notAfter timestamps, and path validation checks all of them. This is not a browser quirk, it is how RFC 5280 path validation is specified and how it is implemented. In BoringSSL, the library behind Chrome’s certificate verifier, the validity check runs inside the per-certificate processing step that the path loop calls for every certificate it walks. There is no exemption for intermediates.

So an intermediate that passed its notAfter date invalidates the path it sits in, and the connection is refused, no matter how healthy your own certificate is.

Your certificate stays valid the whole time

This is the detail that sends people down the wrong path. You open the certificate, read its expiry date, see months of life left, and conclude the certificate is not the problem. That reading is correct. The certificate is not the problem, and renewing it changes nothing, because a renewal replaces the leaf and leaves the expired intermediate exactly where it was.

Reissuing a certificate to fix an expired intermediate is one of the most common wasted afternoons in certificate troubleshooting. The expired link is a file your CA already publishes and you already have a copy of. It needs replacing, not repurchasing.

An expired root is a different problem

Roots expire too, and they behave differently, which is why the two get confused. A root certificate sits at the end of the chain as the trust anchor, and whether its expiry date is enforced is a decision each client makes rather than a fixed rule. Chrome’s verifier only applies the validity check to a trust anchor when that anchor is configured to have its expiry enforced, and several platforms historically did not enforce it at all.

An intermediate gets no such treatment. It is inside the path rather than anchoring it, so its dates are always checked. That asymmetry explains a result that otherwise looks contradictory: an expired root can sit in a trust store for years hurting nothing, while an expired intermediate takes a site down the moment it lapses.

Which Error Your Visitors Actually See

There is no browser error called “expired intermediate certificate”. That phrase describes a cause, not a message, and the message your visitors get depends on how their client tried to build the chain. In Chrome the same underlying problem can surface as either of two different codes, which is a large part of why it gets misdiagnosed.

• NET::ERR_CERT_DATE_INVALID when the client managed to build a complete path to a trusted root through the expired intermediate. The path exists, so the only complaint is the date, and Chrome reports the date error. See how to fix NET::ERR_CERT_DATE_INVALID.
• NET::ERR_CERT_AUTHORITY_INVALID when the client discarded the expired intermediate and then had no usable issuer left, so it could not reach a trusted root at all. See how to fix NET::ERR_CERT_AUTHORITY_INVALID.

Chromium’s verifier collects every problem it found into a set of status flags, then reduces them to the single error the user is shown. Its own comment on that step is that a certificate may have several errors and it reports the most serious one. In that ranking the untrusted-authority status is tested before the date status, so when a broken chain produces both, the authority error is what gets printed.

The practical consequence is worth stating plainly. An expired intermediate can produce an error that says nothing about dates at all. If you are staring at NET::ERR_CERT_AUTHORITY_INVALID and your certificate is genuinely valid and genuinely from a well-known CA, an expired intermediate belongs on your list of suspects alongside a missing one.

What other clients report

Other software is often more informative than Chrome here, so a second opinion is genuinely useful:

• Firefox names the problem outright with SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE, which says the certificate is not trusted because the issuer’s certificate has expired. If you have that code, you already have your diagnosis. Firefox’s SEC_ERROR_EXPIRED_CERTIFICATE is the different case where the leaf itself expired.
• Safari prints no code and reports only that the connection is not private or that the certificate is not valid.
• OpenSSL is the most precise of all, because it tells you which certificate in the chain failed and why. That is the diagnostic used below.
• Application and API clients usually surface whatever their TLS library said, so you will see phrasing like “certificate has expired” or “unable to get local issuer certificate” in application logs rather than a browser code.

Why It Can Break for Months Before You Notice

An expired intermediate is unusual among server misconfigurations: a large part of the internet quietly repairs it for you, which is exactly what stops you from finding out.

Certificates carry an Authority Information Access extension containing a URL where the issuing CA publishes its intermediate. Chrome’s path builder is wired to use it: the verifier adds an AIA-backed issuer source so the builder can discover intermediates by downloading them, and it does that only when a network fetcher is available to it. Desktop Chrome has one. The builder also explores candidate paths rather than stopping at the first chain it assembles, and keeps the first valid one it finds, preferring any path that reaches a trust anchor over one that dead-ends.

Together those two behaviours produce the invisibility. Desktop Chrome tries the path your server sent, sees the expiry, fetches your CA’s current intermediate from the AIA URL, builds a valid second path with it, and loads the page with no warning at all.

Plenty of clients cannot do that:

• Android is the usual place this surfaces first. The platform certificate validator that every native app relies on does not perform AIA fetching at all. Chrome and WebView on Android do attempt it, but only on a best-effort basis. Android does keep a cache of intermediates it has seen, which is why a broken chain can appear to work for a while, but that cache lives in memory inside each app and is gone as soon as the app restarts.
• Firefox does not fetch on demand either. It preloads a set of intermediates the CAs disclosed in advance, which covers many cases but not all.
• Command-line tools, API clients, Java applications, payment callbacks, webhooks and monitoring agents generally do no repair whatsoever. They take the chain they are given and reject it.

The reported symptom is therefore rarely “my certificate expired”. It is that the site works for you and not for a customer, that payments started failing, that a partner’s integration broke without either side deploying anything, or that Android users complain while desktop users do not. Treat “works for me but not for them” on an HTTPS site as a chain problem until proven otherwise.

None of these repair mechanisms is a fix or something to rely on. They are fallbacks that a large share of clients do not implement, and they silently mask a server sending a broken chain.

The Two Incidents That Made This Famous

Expired intermediates are not a hypothetical failure mode. Twice in recent years a single certificate expiring broke a substantial slice of the internet, and both cases show the same pattern: browsers were mostly fine, everything else was not.

AddTrust External CA Root, May 30, 2020

Sectigo, formerly Comodo, issued certificates chaining up to its USERTrust RSA Certification Authority root, which was itself cross-signed by a much older AddTrust External CA Root for compatibility with legacy devices, and servers commonly sent that cross-signed certificate as part of the chain. When AddTrust expired on May 30, 2020, browsers that already trusted USERTrust directly took the shorter path and were unaffected, while OpenSSL 1.0.x and GnuTLS followed the chain to AddTrust and failed on it, breaking API calls and scripts for days on servers that browsers insisted were healthy.

DST Root CA X3, September 30, 2021

Let’s Encrypt’s ISRG Root X1 was cross-signed by the older DST Root CA X3 so that devices which had not yet picked up the newer root, older Android versions above all, would still trust it. DST Root CA X3 itself expired on September 30, 2021 at 14:01:15 GMT and took every path that still ran through it. Browsers and current libraries switched to ISRG Root X1 and carried on, while OpenSSL 1.0.2 hit a path-building quirk that failed even for clients which trusted ISRG Root X1, so servers, scripts and embedded devices broke at once. Moving to OpenSSL 1.1.0 or later was one remedy.

Both carry the same lesson for a site owner: the only reliable way to know your chain is intact is to inspect what your server actually sends, since your own browsers will not tell you.

Diagnose It: Read the Whole Chain and Its Dates

Do not diagnose this in a browser. The desktop browser is the one client most likely to be hiding the problem from you. Ask the server directly instead.

1. Read the verify error and, crucially, its depth

Start with a plain connection:

openssl s_client -connect example.com:443 -servername example.com < /dev/null

OpenSSL walks the chain and prints a depth line for each certificate before reporting any error against it. That depth number is the single most useful thing on the screen, because it tells you which certificate is at fault:

• depth=0 is your leaf certificate. An expiry error here means your own certificate lapsed, which is the ordinary renewal case.
• depth=1 is the intermediate that signed it. An expiry error here is the subject of this guide.
• depth=2 and above are further intermediates and the root.

An expired intermediate produces output of this shape, with the failing certificate named immediately above the error and its expiry date immediately below:

depth=1 C = US, O = Example CA, CN = Example CA Intermediate R3
verify error:num=10:certificate has expired
notAfter=May 30 10:48:38 2026 GMT
...
    Verify return code: 10 (certificate has expired)

Three verify return codes come up repeatedly with chain problems, and they mean different things:

• 10 (certificate has expired) with depth=1 or higher: an intermediate in the chain is past its notAfter date. This page.
• 21 (unable to verify the first certificate): the server sent the leaf but no intermediate at all. That is a missing chain rather than an expired one.
• 20 (unable to get local issuer certificate): no path to a trusted root could be built from what was sent, which is also what an expired intermediate looks like once a client discards it.

Two flags are worth knowing about before you trust this output. The -servername flag sends your hostname via SNI, which is what a browser does. Since OpenSSL 1.1.1 s_client fills SNI in automatically from the hostname you pass to -connect, so a bare command is not an SNI-free test, and if you actually want to test without SNI you have to ask for that explicitly with -noservername. Separately, plain s_client does not check that the certificate matches the hostname, and will report Verify return code: 0 (ok) on a certificate issued for an entirely different domain. Add -verify_hostname when that matters:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com < /dev/null

On macOS, the bundled openssl is LibreSSL, which rejects this flag with unknown option -verify_hostname. That is the smaller of two problems. Against the same expired intermediate that makes OpenSSL report depth=1 and code 10, LibreSSL never walks past depth 0 and reports code 21 instead, which is the code this page describes as a missing intermediate rather than an expired one. Taken at face value it points you at the wrong fault. Install OpenSSL through Homebrew and run that binary for everything on this page. Confirm you are actually calling it: /usr/bin comes first on the default PATH, so run openssl version after installing, and if it still says LibreSSL use the full path /opt/homebrew/bin/openssl on Apple silicon or /usr/local/bin/openssl on Intel. That matters more here than on most pages, because the wrong binary does not fail, it reports a different fault.

2. Print every certificate the server sends, with its dates

The verify error stops at the first problem it hits. To see the whole picture, including an intermediate that is still valid but due to expire next month, print the full chain with dates:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null 2>/dev/null \
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
  | openssl pkcs7 -print_certs -text -noout \
  | grep -E "Subject:|Issuer:|Not Before|Not After"

You get one block per certificate the server put on the wire, in order:

        Issuer: C = US, O = Example CA, CN = Example CA Intermediate R3
            Not Before: Jun  2 00:00:00 2026 GMT
            Not After : Dec 30 23:59:59 2026 GMT
        Subject: CN = example.com
        Issuer: C = US, O = Example CA, CN = Example CA Root
            Not Before: Mar 30 00:00:00 2016 GMT
            Not After : May 30 10:48:38 2026 GMT
        Subject: C = US, O = Example CA, CN = Example CA Intermediate R3

Read it as pairs. The first block is your leaf, valid into December. The second is the intermediate that signed it, and its Not After is in the past. That is the whole diagnosis in one screen, and it is the picture you cannot get from looking at your own certificate alone.

The chain should also be continuous: each certificate’s Issuer must equal the Subject of the next block down. A break there is a different fault, usually a wrong or out-of-order intermediate rather than an expired one.

To check a chain file on disk before you deploy it, read it the same way without connecting to anything:

openssl crl2pkcs7 -nocrl -certfile fullchain.crt \
  | openssl pkcs7 -print_certs -text -noout \
  | grep -E "Subject:|Issuer:|Not After"

3. Confirm from outside your network

Run the domain through our free certificate chain checker. It connects from outside, reports every certificate in the chain with its dates, and flags an expired or missing intermediate explicitly. Checking from outside matters more here than on most errors, because a server frequently has the correct intermediate sitting in a local trust store while never putting it on the wire, so the chain looks complete from the machine that is getting it wrong.

Test the www and non-www forms, and any subdomain on the same certificate. It is common to fix one virtual host and leave a second one pointing at the old chain file.

Fix It: Replace the Intermediate from Your CA’s Current Bundle

The repair is a file swap, not a certificate purchase. Your leaf certificate and its private key stay exactly as they are.

1. Get your CA’s current chain

Download the current bundle from your Certificate Authority. Every CA publishes its in-force intermediates, and the file usually arrives with your certificate under a name ending in .ca-bundle, chain.pem or intermediate.crt. If you still have the original delivery email or the order in your account portal, re-download rather than reusing a copy from an old server build, since the old copy is very likely the expired one.

Take the intermediate that matches the issuer named in your leaf certificate. If you are unsure which that is, read it off the leaf:

openssl x509 -in example_com.crt -noout -issuer

2. Rebuild the chain file in the right order

Concatenate your certificate and the new intermediate into one file. Order is not optional: leaf first, then each intermediate working up toward the root. The root itself is left out, because clients that trust it already have it.

cat example_com.crt example_com.ca-bundle > fullchain.crt

Each certificate in the file must be a complete PEM block, and the two files must not run together on the same line. If the original certificate file does not end with a newline, the last line of one certificate and the first line of the next end up concatenated and the file becomes unparseable. The result should look like this, with each marker line intact:

-----BEGIN CERTIFICATE-----
(your domain certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(the current intermediate certificate)
-----END CERTIFICATE-----

Verify the rebuilt file before deploying it, using the on-disk command from the previous section. Confirm your domain comes first, that the intermediate’s Not After is now in the future, and that each certificate’s issuer matches the subject of the one after it.

3. Point nginx at the rebuilt chain

Nginx has no separate directive for the chain, so the file given to ssl_certificate must already contain the leaf and the intermediates:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/certs/fullchain.crt;
    ssl_certificate_key /etc/ssl/private/example_com.key;
}

4. Point Apache at the rebuilt chain

On Apache 2.4.8 and later, SSLCertificateFile loads the intermediates from the same file. Apache’s own documentation states that the older SSLCertificateChainFile directive became obsolete in 2.4.8, when SSLCertificateFile was extended to also load intermediate CA certificates from the server certificate file.

If your configuration still carries SSLCertificateChainFile, that is worth checking carefully, because a stale chain file referenced by a deprecated directive is a classic way to end up serving an intermediate nobody has looked at in years. Move the intermediates into the chain file and remove the directive:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on

    SSLCertificateFile    /etc/ssl/certs/fullchain.crt
    SSLCertificateKeyFile /etc/ssl/private/example_com.key
</VirtualHost>

5. On IIS and Windows

IIS does not configure the chain in the site binding. It builds the chain from the Windows certificate store, so the replacement happens there: import the current intermediate into the local machine’s Intermediate Certification Authorities store, and delete the expired one from that same store so Windows stops offering it. Leaving both in place is what produces the intermittent version of this problem, where the server sometimes builds the good chain and sometimes the bad one.

6. Anything else that terminates TLS

The certificate has to be fixed wherever TLS is actually terminated, which is often not your web server. A load balancer, CDN, reverse proxy, WAF, or an appliance in front of the origin each holds its own copy of the chain, and updating the origin behind one of them changes nothing that visitors see. Mail servers and application servers presenting the same certificate need the same treatment.

Our SSL certificate installation tutorials cover the equivalent steps on control panels, load balancers and appliances.

7. Test the configuration, reload, then verify from outside

Test the syntax before applying it. A web server that will not start after a certificate change turns a partial outage into a total one:

sudo nginx -t
sudo systemctl reload nginx

On Apache:

sudo apachectl configtest
sudo systemctl reload apache2

The reload is the step that gets missed. A running web server holds its chain in memory and keeps serving the expired intermediate until it is told to re-read the file, which is why the fix can look complete on disk while every affected client still fails. Reload rather than restart where you can, so current connections are not dropped.

Then re-run the full-chain command from a machine outside your network and confirm the intermediate’s Not After has moved into the future, and that the verify return code is 0. Checking from the server itself can succeed on a chain that is still broken for everyone else.

When the Expired Intermediate Is on the Client, Not the Server

There is a second, less common version of this problem where the server is configured correctly and the stale certificate is sitting on the machine showing the error. It is worth recognising, because no amount of server work will clear it.

The classic example dates from July 26, 2014, when DigiCert customers began reporting untrusted certificate errors. The certificate that expired was a cross-signed one: a certificate whose subject was DigiCert High Assurance EV Root CA but which had been issued by the older Entrust.net Secure Server Certification Authority, so that legacy devices could follow a compatibility chain up to a root they already trusted. It had not been needed for years, but copies of it remained installed on individual machines, and those machines kept building paths through it until it was removed.

The naming is what makes this confusing, and it is worth being explicit: the actual DigiCert High Assurance EV Root CA root certificate is self-signed, has been valid since 2006, and does not expire until November 2031. It did not expire in 2014 and is still in use. What expired was a separate cross-signed certificate that happened to share its subject name. A certificate is identified by its issuer and serial number, not by its subject name alone, and several certificates can carry the same name while having entirely different dates.

The AddTrust and DST Root CA X3 cases had a client-side half too. For OpenSSL 1.0.x systems the recommended remedy was precisely this: remove the expired certificate from the local trust store so the client stopped trying to build a path through it.

You are in this case, rather than the server case, if the error appears on one machine while other machines load the same site normally, and the external SSL Checker scan comes back clean.

Removing a stale intermediate on Windows

Back up the certificate before removing it, by exporting it from the store, so you can restore it if the error turns out to have another cause.

1. Press Windows + R, type mmc and press Enter to open the Microsoft Management Console.
2. Choose File, then Add/Remove Snap-in.
3. Select Certificates in the left column, click Add to move it to the right column, then choose Computer account, then Local computer, then Finish and OK.
4. Expand Intermediate Certification Authorities, then Certificates, and sort by the Expiration Date column to bring expired entries together. Legacy cross-signed certificates may instead sit under Third-Party Root Certification Authorities.
5. Find the expired certificate by name and expiry date, right-click it and choose Delete.

On a server, restart the web service afterwards so it rebuilds its chain from the updated store. Some guidance suggests opening the certificate’s Properties and selecting Disable all purposes for this certificate instead of deleting it. That is a reasonable, more reversible option, and it does stop Windows using the certificate to build chains. It is a different action from deleting, though, so do one or the other rather than expecting them to be interchangeable.

Removing a stale intermediate on macOS

1. Sign in with an administrator account, open Applications, then Utilities, then Keychain Access.
2. Choose View, then Show Expired Certificates, so expired entries stop being hidden.
3. Check the login keychain and the System keychain under the Certificates category, and search for the expired certificate by name.
4. Right-click it and choose Delete, then quit Keychain Access and reload the site.

Expired entries are hidden by default in Keychain Access, which is why the certificate causing the problem can be invisible until you turn that view on.

On Linux and OpenSSL trust stores

On Debian and Ubuntu, remove or disable the certificate under the system CA directory and rebuild the bundle with sudo update-ca-certificates. On RHEL, Fedora and their derivatives, the equivalent is sudo update-ca-trust. Applications that ship their own bundled trust store, which many language runtimes and container images do, need updating separately, since they will keep using their own copy regardless of what the system store says.

What Will Not Fix an Expired Intermediate

These steps circulate on nearly every page about certificate errors. None of them can change the dates on a certificate your server is sending, so none of them resolves this. They are listed so you can rule them out rather than work through them.

• Clearing your browser cache and cookies. This is the most widely repeated advice for the Firefox expired-issuer error, and it rests on a misunderstanding. Browsers do not store server certificates in the browsing-data cache. The server transmits its whole chain during the handshake on every new connection, so there is no stale copy to clear. Clearing the cache cannot change what arrives on the wire.
• Renewing or reissuing your certificate. The most expensive dead end on this list, for the reason set out earlier: a renewal replaces the leaf and leaves the intermediate exactly where it was.
• Disabling your antivirus. Security products that inspect HTTPS re-sign traffic with their own root, and when that goes wrong the browser cannot trace the issuer to a trusted root. That is an issuer failure, not a date one, and it appears as NET::ERR_CERT_AUTHORITY_INVALID. If your external scan shows an expired intermediate, no antivirus setting will move its dates. Check the certificate viewer first: if Issued By names your security product, you are on the wrong guide.
• Changing your DNS server. DNS resolves a hostname to an IP address and plays no part in certificate validation. It cannot affect which certificates a server sends or what dates they carry.
• Setting your device clock back. This does make an expired certificate validate again, and it is a bad idea in every case. You are switching off the check rather than repairing anything, and a wrong system clock goes on to break other HTTPS connections, software updates and two-factor codes on the same machine. It also does nothing for your visitors, who still cannot reach the site.
• Switching browsers. A site that loads in one browser and fails in another has not been fixed. It has found a client that repairs the chain for you, which is the mechanism that hid the problem in the first place.

Monitor the Whole Chain, Not Just Your Certificate

Almost all expiry monitoring watches the leaf certificate and nothing else, which is the exact blind spot that lets an intermediate lapse unnoticed.

The standard one-liner for checking expiry is a good illustration. It exits non-zero when a certificate will expire within the given number of seconds, here 14 days:

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

That command is useful, but it has a limitation few people notice: openssl x509 reads only the first certificate it is given, so even when the server sends a full chain, only the leaf is ever checked. A monitor built on it would have reported everything healthy right up to the moment AddTrust and DST Root CA X3 expired.

To watch the whole chain, check the dates on every certificate the server sends using the full-chain command from the diagnosis section, and alert on the earliest Not After rather than the leaf’s. Two habits close the gap:

• Test with a client that does not repair chains. A scheduled check from a plain command-line tool, or an external scan such as the SSL Checker, sees the chain as your strictest visitors see it. A desktop browser does not.
• Re-check after every certificate change. Renewals are when stale intermediates get reintroduced, usually by a deployment script that rebuilds the chain file from a bundle saved years ago.

ACME certificate automation helps here for a reason that is easy to miss: because ACME clients fetch the current chain from the CA on every renewal, they keep your intermediates fresh as a side effect, which is the part manual renewal routinely gets wrong. Our ACME tutorials cover the common clients. Confirm the renewal hook reloads whatever terminates TLS, since a chain that updates on disk but never reaches the running server leaves the old intermediate in front of your visitors.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.