The short answer
Three different events get called "the root expired", and only one of them reliably breaks a working certificate. A root passing its own notAfter date usually breaks nothing in an updated client, because a trust anchor is trusted for sitting in the trust store rather than for anything its own signature says. What does break certificates is removal from that store, and since both Mozilla and the Chrome Root Program now schedule removal by the age of the CA's key material, at roughly fifteen years from key generation for TLS, the date deciding your chain's future is not the one printed on the root. The USERTrust RSA root is the standard illustration: key material from 2010, a notAfter of January 2038, and a policy clock that ran out around 2025.
Three things get called "the root expired"
The phrase covers a root certificate reaching the expiry date printed on it, a browser root program removing that root from its trust store, and a certificate authority moving new issuance onto a newer hierarchy. They arrive with similar-sounding advisories and they have almost nothing in common operationally. The first is usually a server configuration problem, the second is the only one that turns working certificates into browser warnings, and the third is a scheduling problem for your next renewal.
Sorting them apart matters because the responses cost wildly different amounts. One is a five-minute edit to a chain file. One means every certificate under that hierarchy has to be replaced before a published deadline. One means remembering to install a different intermediate the next time you renew, and nothing else. Support queues fill up every time a root story makes the rounds, mostly with people about to buy a replacement certificate they do not need.
It helps to be precise about what a root actually is. A root certificate is self-signed, so its signature proves nothing to anyone. It is trusted because a vendor put it in a list that ships with an operating system, a browser, a language runtime, or a device image. That list is the whole mechanism, which is also why one certificate can pass in Chrome and fail in Java on the same machine.
Why an expired root usually breaks nothing
A client that holds the root in its own trust store builds a path that ends at that root and stops. RFC 5280 describes the trust anchor as an input to path validation, a name and a public key supplied to the algorithm, rather than as another link that gets date-checked on the way past. Validation starts with the certificate the anchor issued. The anchor's own notAfter frequently never gets read at all.
Implementations disagree about this, and the disagreement is the entire story of why one expiry is an outage for some users and a non-event for everyone else. Android is documented as deliberately not enforcing the notAfter of trust anchors, a choice Let's Encrypt later relied on to keep older phones working. Some older libraries take the opposite view, treating whatever chain the server sent as the chain to validate, expiry checks and all.
Which leaves the real variable: what your server sends. Certificate authorities often supply a chain file containing an extra cross-signed certificate that points back to an older, more widely deployed root, so that devices without the newer root can still find their way to something trusted. That extra certificate is harmless while the old root is alive. On the day it expires, every client that was relying on it, and only those clients, starts failing.
The practical consequence is worth stating plainly, because it saves people money: when only older clients break, the fix is almost always to remove the cross-signed certificate from the chain your server sends and reload. Nothing about the certificate on disk is wrong. Reissuing it changes nothing if the same chain file goes back into place. If the chain itself is unfamiliar territory, the walkthrough of intermediate certificates and broken chains covers how the pieces fit together.
The date that matters is the key's birthday
Root programs no longer decide a root's fate by the expiry date on the certificate. As of August 2026 the Mozilla Root Store Policy removes the websites trust bit once the CA key material is more than fifteen years past its generation date, and sets an S/MIME distrust date at eighteen years. The Chrome Root Program applies a comparable fifteen-year rule to key material in its own store. Roots are routinely issued with twenty-five or thirty year validity periods, so the policy clock now fires first, by a wide margin.
Mozilla's own reasoning for the number is unusually legible. A new root typically takes two to three years to propagate into the major trust stores, and a certificate authority needs time at the other end to migrate customers off the old hierarchy before it can be dropped. Fifteen years from key generation leaves roughly a decade of ordinary working life in the middle. CA operators are urged to apply for inclusion of their next-generation root at least two years before the distrust date of the one it replaces.
Run the arithmetic on any root you depend on and the gap tends to be startling. Take the not-before date as a working proxy for key generation, add fifteen years, and compare that to the notAfter. For a root generated in 2010 with a 2038 expiry, the two answers are about thirteen years apart, and only the earlier one has any bearing on whether your certificates keep validating. This is also why several long-standing hierarchies from the same era have been working through trust store removal across 2025 to 2027 while their certificates still read as valid for another decade.
None of this is something you have to manage yourself under normal conditions. Your certificate authority is the party obliged to have a successor root in the stores well ahead of the deadline, and a well-run one has been issuing from it for years by the time the old one goes. It matters when you are choosing a certificate authority, or when someone pins to a root, which is where pinning quietly turns a routine migration into an outage.
What actually broke in 2020 and 2021
Two root expiries produced most of the folklore on this subject, and both broke the same way. The AddTrust External CA Root expired on 30 May 2020, and DST Root CA X3 expired on 30 September 2021. In each case browsers on updated systems were unaffected, while a scattering of servers, scripts, embedded devices and payment integrations failed on the day. The cause both times was chain building rather than the expiry itself.
AddTrust had been cross-signing the newer USERTrust root so that devices predating USERTrust could still validate. Any client holding USERTrust directly simply built the shorter path and discarded the cross-sign, which is why every current browser sailed through. Clients built on older OpenSSL 1.0.x, and some GnuTLS and Java builds, followed the chain the server sent all the way to AddTrust and refused it. The fix Sectigo published was to stop serving the cross-signed certificate.
DST Root CA X3 was the same shape with a twist worth knowing. IdenTrust had cross-signed ISRG Root X1 so that Let's Encrypt certificates would validate on old Android devices, and Let's Encrypt arranged for that cross-sign to remain valid past the expiry of the root that issued it. That works only because Android ignores trust anchor expiry, and it bought several years of compatibility for phones that will never receive another trust store update. The arrangement ran out in 2024.
The lesson people took away was "roots expiring breaks the internet". The more useful one is that a cross-signed certificate is a compatibility crutch with an end date, and leaving it in your chain after it stops helping converts it into a liability. Both incidents were, for the overwhelming majority of affected sites, a one-line change to a chain file.
Distrust: the event that does break certificates
Distrust is a root program deciding it will no longer accept a hierarchy, and it is the only one of the three events that turns a valid certificate in a fully updated browser into a warning. It arrives on a published schedule rather than on a date printed in the certificate, it can be triggered years before any expiry, and there is no configuration change that works around it. The certificate has to be replaced.
It comes in two flavours. Scheduled removal is the fifteen-year key age rule above, which the certificate authority sees coming from a decade away and normally handles without customers noticing. Removal for cause is the other kind: Chrome's action against Entrust is the reference case, where certificates whose Signed Certificate Timestamps were dated after 11 November 2024 stopped being trusted, while those issued before the cutoff kept working until they expired. Google cited a pattern of compliance failures over several years.
That date-scoped design is deliberate and worth understanding, because it explains why a distrust announcement is urgent without being instant. Nothing on your server stops working the day the announcement lands. What stops is your ability to get a usable certificate from that hierarchy, so the pressure sits on your next renewal rather than on your current one. Organisations that treated the Entrust announcement as a slow-moving deadline generally came through it fine; the ones that had no inventory of which certificates came from which authority did not.
A related current of policy is pushing the same way. Chrome's root program is steering hierarchies toward serving TLS server authentication alone, with dates through 2026 and 2027 tightening what a certificate under a trusted root may contain, the same movement that produced the removal of client authentication from public TLS certificates. Multi-purpose roots from an earlier era are being retired on those grounds as much as on age.
When your CA moves to a new hierarchy
Hierarchy rotation is the certificate authority's response to everything above, and it is the event you are most likely to encounter. New issuance moves to a fresh intermediate under a newer root, existing certificates keep validating exactly as before, and nothing on your server changes until you next renew. The surprise lands on renewal day, when the new certificate arrives expecting a different intermediate than the one already installed.
The classic failure is an automation pipeline that installs the new leaf alongside a chain file someone saved years ago. The leaf is valid, the chain no longer leads anywhere, and the site starts serving an incomplete chain that some clients tolerate and others reject. Because it works in the browser the person testing happens to use, it often survives into production and gets found by an API client instead. Pull the chain from the issuance each time rather than from a file in a repository.
This is also where the choice of certificate authority stops being abstract. Migrating an estate is far easier with an authority that publishes its hierarchy plans in advance and issues from a current root well before it has to, which is worth weighing when you compare how the major certificate authorities differ. Our own SSL certificates from Certum are issued from Certum's current publicly trusted hierarchy, and the chain that ships with each order is the one to install rather than whatever an old runbook says.
How to check which root you chain to
There are two different questions here and confusing them wastes an afternoon. The first is what your server sends, which is fixed and inspectable. The second is what a given client builds from it, which depends on that client's trust store. Answer them in that order, because most root-related incidents are explained entirely by the first.
For what the server sends, ask it directly:
| What you want to know | How to ask |
|---|---|
| Every certificate the server sends, in order | openssl s_client -connect example.com:443 -servername example.com -showcerts |
| Subject and issuer of each one, without the noise | ... | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout |
| The validity dates on a single certificate file | openssl x509 -in cert.pem -noout -dates -subject -issuer |
| Whether a specific old client agrees with you | curl -v --cacert /path/to/that/client/bundle.pem https://example.com/ |
Three things are worth looking for in that output. A certificate whose subject and issuer are identical is a root, and it should not normally be there at all. A certificate that names an issuer nothing else in the list matches is your cross-sign. And the last certificate in the list is the one whose expiry date an unforgiving client will care about. If you would rather read it back as a summary than parse OpenSSL output, our SSL checker returns the leaf, the chain and the days remaining from a hostname.
For the second question, test on the platform that complained rather than on your laptop. A Java client validates against a cacerts file that only moves when the JDK does, Node and Python and curl each read bundles of their own, and an embedded device may be carrying a trust store frozen at manufacture. Reproducing the failure on the right trust store is usually the moment the diagnosis becomes obvious.
What to fix, in the order it matters
Work from the symptom to the event, then from the event to the fix. If current browsers are fine and only older clients fail, you have a chain-building problem and the answer is a server configuration change. If current browsers show a warning too, check whether the browser vendor has published a removal or a cutoff date for that hierarchy. That single question separates a five-minute edit from a certificate replacement programme.
Beyond the immediate incident, three habits stop this class of problem from recurring. Send the leaf and the intermediates needed to reach a trusted root, and nothing else, no root certificate, and no cross-sign that no longer earns its place. Take the chain from each issuance rather than from a file someone saved, so a hierarchy rotation lands automatically. And keep an inventory of which certificates come from which authority, because that inventory is the only thing that makes a distrust announcement a scheduling exercise instead of a scramble.
One habit not to adopt: pre-emptively replacing certificates because a root made the news. Almost every root story in circulation is either the harmless first event or a scheduled removal your certificate authority handled years ago. Establish which of the three you are actually in, and most of the time the answer costs nothing at all.
FAQ
See the chain your server is actually sending
Most root-expiry incidents are settled by reading the chain rather than by reasoning about it. Entering a hostname returns the leaf, every intermediate the server sends and the days remaining, which is enough to tell a stray cross-sign from a genuine problem. It takes a few seconds and needs no account.
Check a certificate chain with the SSL checker