How is this different from SEC_ERROR_EXPIRED_CERTIFICATE?

One word — issuer — and it moves the problem up the chain. SEC_ERROR_EXPIRED_CERTIFICATE means the certificate the website itself presents, the leaf, is past its notAfter date; you renew that cert and you're done. SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE means the leaf can be perfectly in-date, but something that *signed* it — an intermediate CA, or the root at the top — has expired, and Firefox won't trust a chain anchored on an expired link. The Firefox message spells it out: 'The certificate is not trusted because the issuer certificate has expired.' That's why the fix is different: renewing the leaf does nothing if the problem is the CA certificate above it. You have to fix the chain the server sends, or the trust store the client uses to complete it.

Firefox shows the error but my leaf certificate isn't expired. How?

Because certificate validation checks every link, not just the one you're looking at. A chain is leaf → intermediate → root, and each certificate has its own validity dates. Your leaf can have eleven months left while the intermediate that issued it, or an old root the chain terminates in, expired last week. The most common shape is a server still stapling an outdated intermediate — often a cross-signed one that used to bridge to an older root — instead of the current chain. Firefox builds the path the server hands it, hits the expired issuer, and stops. The certificate you see in the address bar looks fine; the expired one is a link or two above it, which is exactly why people find this error so confusing.

Only old phones and machines hit it — newer ones are fine. Why?

Because they're completing the chain to different roots. This is the exact pattern of the AddTrust External CA Root expiry on 30 May 2020: certificates from that CA family (Sectigo, formerly Comodo) could chain either to the old, now-expired AddTrust root or to the newer USERTrust RSA Certification Authority root that's valid until 2038. Newer devices had the USERTrust root in their trust store and built a clean, in-date path. Older devices — dated Android, old macOS, anything with an OpenSSL before 1.1.1 that had a chain-building bug — kept selecting the expired AddTrust path and broke, even for the same server and the same leaf certificate. When only old clients fail, the server is almost always sending a legacy chain, and the fix is to serve the modern intermediate that points at the in-date root.

Views: 26

SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE (Firefox)

SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE means a root or intermediate in your chain expired, not the leaf. Find it in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Firefox blocks the site with SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE and the line “The certificate is not trusted because the issuer certificate has expired.” Note the exact word: issuer. Firefox is not saying the website’s certificate expired. It’s saying that something that vouched for it — the CA certificate one or more steps up the chain — is the thing that’s out of date.

This trips people up because they immediately check the site’s certificate, see a comfortable expiry date months away, and conclude Firefox is wrong. Firefox isn’t wrong. A certificate is only as valid as the chain that anchors it, and if any link in that chain has expired, the whole path fails. The expired certificate is sitting above the one you’re looking at.

Symptoms

The exact code is SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE, distinct from the leaf-level SEC_ERROR_EXPIRED_CERTIFICATE.
The website’s own (leaf) certificate is still valid when you inspect it — the expiry is elsewhere in the chain.
It very often hits older devices and OSes while current ones load the site fine.
Command-line tools disagree: a modern openssl s_client may verify cleanly while an old one, or an old library, reports the expired issuer.
It can appear suddenly on a site that “didn’t change anything” — because a CA certificate in the chain crossed its own expiry date on a calendar, not because anyone touched the server.

What SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE Actually Means

TLS trust is a chain: your leaf certificate is signed by an intermediate CA, which is signed by (or cross-signed toward) a root the client already trusts. Every certificate in that chain — leaf, each intermediate, and the root — carries its own notBefore/notAfter validity window. Firefox, via its NSS library, walks the chain and checks all of them. If the leaf is in date but an issuer above it has expired, you get SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE. The trust didn’t fail because your cert is bad; it failed because the thing backing your cert is no longer valid.

The subtlety that makes this genuinely hard is that a single leaf certificate can often be built into more than one chain. CAs cross-sign: an intermediate can be signed by both an old root and a new root, so that clients with either root in their store can still reach a trust anchor. When one of those roots expires, the certificate is still fine — as long as the client picks the chain to the other, in-date root. Whether it does depends on what’s in the client’s trust store and how good its chain-building logic is. That’s why the same server can work in one browser and fail in another on the same day.

The canonical example is the AddTrust External CA Root, which expired on 30 May 2020. A huge number of certificates from Sectigo (formerly Comodo) chained through it. Modern clients had the newer USERTrust RSA Certification Authority root (valid until 2038) and built a clean path; older clients, and notably anything running an OpenSSL version before 1.1.1 with its chain-selection bug, kept choosing the expired AddTrust path and broke. Same certificates, same servers — the failure was entirely about which root each client reached for.

Top Causes

The server is sending a stale intermediate - The chain the server staples includes an old intermediate — frequently a cross-signed one that used to bridge to a now-expired root — instead of the current chain that points at an in-date anchor. This is the most common and the most fixable cause: replace the served chain with the modern one your CA provides.
An old root expired and the client has no alternative - The chain terminates in a root that has passed its expiry, and the failing client’s trust store doesn’t contain the newer replacement root. Newer devices have it; the old ones don’t, which is why the failure clusters on outdated OSes.
An old client with a chain-building bug - Even when a valid alternative path exists, old TLS libraries (pre-1.1.1 OpenSSL, dated Android/macOS stacks) can pick the expired branch and fail. Here the certificate and even the served chain may be fine; the client is simply too old to choose correctly.
A genuinely expired intermediate that was never rotated - Rarer, but real: an internal or smaller CA let an intermediate lapse without reissuing. Every certificate under it fails until the intermediate is renewed and redeployed.

Diagnose with DechoNet

SSL Check inspects the certificate chain the server actually presents, from the outside, and reports each certificate’s validity dates and issuer — so you can see which link is expired rather than guessing. If the check shows the leaf in date but flags an expired intermediate or a chain that terminates in a stale root, you’ve found it: the server is serving the wrong chain, and the fix is to install the modern intermediate that points at an in-date anchor. If DechoNet shows a clean, fully in-date chain while only old devices fail, the problem isn’t the server at all — it’s those clients completing the chain to an expired root they still carry, and the answer is updating their trust store.

Resolution Checklist

Look at which certificate is expired, not just that something is. Inspect the chain and read the validity dates on the leaf, every intermediate, and the root. The leaf will usually be fine; the expiry is above it.
Run an external SSL check to see the chain as the server sends it. An expired intermediate or a chain ending in a stale root there means the server is at fault.
Note the scope. Only old devices failing, current ones fine, points squarely at chain selection — the server is likely sending a legacy chain, or the old clients lack the replacement root.
If the served chain is stale, install the current intermediate bundle from your CA — the one that chains to the in-date root — and reload. Do not renew the leaf hoping it helps; the leaf isn’t the problem.
If it’s a client that simply reaches an expired root, update that device’s OS and root store. For a client too old to receive updates, there is no server-side certificate that fixes it cleanly.
If an internal CA’s intermediate genuinely lapsed, reissue and redeploy that intermediate across every server under it.

When to Escalate

If an external SSL check confirms the served chain is stale, this is a server fix, and whoever runs the origin needs the exact expired certificate named. “The served intermediate expired; install the chain to the USERTrust (or your CA’s current) root” is a precise, actionable request — far better than “the certificate is broken.”
If the failure is isolated to unpatchable old devices, escalate the decision, not the certificate. There’s a real trade-off between supporting ancient clients and serving a modern chain, and no server config satisfies both perfectly. That’s a product call about who you still support, and it belongs with whoever owns that decision — not something to paper over with an outdated chain that quietly weakens everyone else’s trust path.