Dedicated TLS Roots: Why Your Certificate Chain Is Changing

What a dedicated TLS root is

A dedicated TLS root is a root CA certificate whose hierarchy issues nothing but TLS server certificates. For most of the web PKI’s history one root anchored a CA’s entire catalogue: web server certificates, S/MIME, code signing, document signing, timestamping. The Chrome Root Program now requires hierarchies included in the Chrome Root Store to be dedicated to TLS server authentication, so CAs have split those product lines apart.

The argument for splitting is containment. A root that signs five kinds of certificate has five ways to get itself into trouble, and a browser that distrusts it over a code signing failure takes every website using it down as collateral. Separating the hierarchies means a problem in one product line can be dealt with by removing that root, and Chrome can make trust decisions about the web without weighing what else the CA sells.

Purpose separation has been arriving in layers, from the leaf upward. Subordinate CAs newly disclosed to the Common CA Database have had to assert serverAuth alone since June 15, 2026, and the client authentication EKU came out of public TLS certificates earlier that year — the mechanics of that change are in our write-up of the clientAuth EKU removal. The root layer is the last one, and it is the one that changes what your server has to send.

There is a second driver alongside purpose. Certum describes its own root replacement as following decisions by Mozilla and Google to stop trusting TLS roots older than fifteen years, which is a separate clock from the dedicated-purpose requirement and pushes in the same direction. A root created in 2008 is retired because of its age whether or not it was ever multi-purpose.

What Chrome’s two-root limit changes

From September 15, 2027 the Chrome Root Store will include at most two self-signed root CA certificates per CA owner. A CA that already holds two or more can only file a new inclusion request that replaces an existing one, on a one-in, one-out basis. This is set out in Chrome Root Program Policy v1.8, last updated February 5, 2026.

That ceiling is what turns a slow tidy-up into a deadline. Two slots is a tight budget, and it explains a pattern you can see across every CA that has published a migration plan: the replacement roots arrive in pairs, one RSA and one ECDSA. Certum introduced Certum Trusted Root CA for RSA and Certum EC-384 CA for ECDSA. DigiCert’s pair is DigiCert TLS RSA4096 Root G5 and DigiCert TLS ECC P384 Root G5. A CA needs both key types to serve the market, and two key types fill the quota exactly, so there is no room left for a third root of any kind.

What happens to everything else the CA anchors? It leaves the Chrome Root Store, and that is fine, because Chrome only needs anchors for TLS server authentication. An S/MIME root that is not in Chrome loses nothing it was using. The consolidation looks dramatic from the outside and is mostly a filing exercise, right up to the point where a client of yours was trusting one of those departing roots for a TLS connection.

DigiCert has said that from September 15, 2027 the Chrome Root Store will support only its two G5 hierarchies, which is the same rule seen from the CA’s side. If you hold a DigiCert certificate issued from a Global Root G2 or G3 hierarchy that is still valid past that date, Chrome is the client that stops building a path to it.

The dates that matter

Five dates carry this migration. September 15, 2025 is when Certum started issuing from its dedicated roots. February 5, 2026 is the last update to Chrome Root Program Policy v1.8. October 15, 2026 moves DigiCert’s default issuance to the G5 pair. April 15, 2027 is the trust removal date for Certum Trusted Network CA. September 15, 2027 is when the two-root ceiling applies.

Per-CA status as of September 30, 2026, from each CA’s own advisories. Re-check these before you plan a change window against them; root schedules move, and the published dates are the ones that count rather than this table.

Why browsers stay fine and servers don’t

A current browser already trusts the replacement roots, because they were added to trust stores well before issuance moved onto them. That lead time is deliberate: a root is useless until it has shipped everywhere, so CAs get the anchor distributed first and switch issuance later. Nothing a browser does during this migration requires anything from you.

Clients that are not browsers get their anchors from somewhere else, and that is where the migration stops being invisible. The bridge built for them is the cross-certificate: the legacy root signs the new root, producing a second valid path that terminates at an anchor an old client already has. Certum supplies cross-signed certificates issued from Certum Trusted Network CA, and DigiCert says a G5 chain includes a cross-signed certificate with the older root by default.

Here is the part that turns into support tickets. A server sends its own certificate plus the intermediates; the client supplies the root. When the hierarchy changes, the intermediates change, and the cross-certificate is one of the files in the new bundle. The failure we see most often after a CA changes hierarchy is not exotic: a server is still sending an intermediate it cached at a previous renewal, the chain it presents leads to a root this certificate no longer belongs under, and the client reports unable to get local issuer certificate while the certificate itself is perfectly valid. Install the bundle that arrived with this certificate, not the one in your notes.

If that error is what brought you here, the anatomy of a chain and the ways servers misassemble one are covered in the SSL certificate chain explained, and the Java-specific version of the same fault is in PKIX path building failed.

Which deployments actually break

Anything that validates a certificate against a trust store nobody updates. That is a short list in principle and a long one in practice: Java applications on older JDKs, Android releases before 14, containers built from a stale base image, appliances and IoT devices with a CA bundle in firmware, air-gapped Windows servers with automatic root updates switched off, and any application that pins a root.

Java deserves singling out because its trust store is unusual. The JVM ships its own cacerts file rather than reading the operating system store, so a machine whose OS trusts the new roots can still have a JVM that does not. JDK 11 and earlier are the releases where a manual import is likely; JDK 17 and later carry a more current set. Upgrading the JDK fixes it, and so does akeytool -importcert of the new roots if you cannot.

Android splits at version 14. Certum notes that its new roots may be unavailable on Android older than 14, with manual installation of the cross-certificate as the workaround. Android 14 introduced updatable root certificates, so a device on 14 or later can receive a new anchor without a full system update, which is exactly the capability the fleet below it lacks.

Pinning is the one case where you cannot fix the problem from your own side of the connection. An application that pins a root you are about to stop chaining to will fail, and the correction has to ship in that application’s next release. If pinning is a requirement, pin the public key of the leaf or the issuing intermediate and carry a backup pin, so a hierarchy change is a rotation rather than an outage. A pinned root in a mobile app with a slow release cadence is the scenario worth finding this quarter rather than in April 2027.

How to check which root you chain to

Ask the server what it is sending and read the issuer of the last certificate in the chain. One openssl s_client call gives you the whole picture: the certificates the server presents, in order, and whether the path it offers can be completed. Do this against the live host rather than against the files on disk, since the gap between the two is the usual bug.

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null \
  | grep -E "^(depth|verify|ss?_|subject=|issuer=)|^ [0-9] s:|^   i:"

The lines beginning s: and i: are the subject and issuer of each certificate the server sent. The issuer on the final one names the anchor the chain expects the client to hold. If that name is a root you know is retiring, the server is sending the legacy path and needs the current bundle.

To test against a specific trust store rather than your own, point -CAfile at the bundle in question. This is how you answer “would the appliance accept this?” without touching the appliance:

# validate the live chain against one specific trust store
openssl s_client -connect example.com:443 -servername example.com \
  -CAfile /path/to/that-devices-ca-bundle.pem </dev/null | grep -i "verify"

# is a given root present in a JVM truststore?
keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" \
  -storepass changeit | grep -i -e certum -e digicert

More of these one-liners, including how to read a certificate without a network connection, are collected in our OpenSSL commands cheat sheet. If you want the conceptual layer underneath — who decides what any of these clients trust in the first place — certificate trust stores covers the four programs that matter.

Code signing and S/MIME

The root split changes which anchor these certificates chain to, not whether they work. The Chrome Root Store exists for TLS server authentication, so code signing and S/MIME roots are not competing for those two slots and Chrome’s ceiling does not constrain them at all. Signed software is trusted through the Microsoft Trusted Root Program; S/MIME through mail client and operating system stores.

The practical consequence shows up in mixed environments. Your TLS certificate, your code signing certificate and your email certificate now chain to three separate roots at the same CA, and a system that validates more than one of them needs all three anchors present. A build server that verifies a signature and also makes an HTTPS call is checking two unrelated hierarchies, and it is easy to update one bundle and forget the other.

Timestamping is the case people miss. A code signature’s timestamp is issued under a timestamping hierarchy, separate again, and a verifier that cannot build a path to that anchor reports a signature problem rather than a timestamp problem. If you are chasing a verification failure after a root change, check which of the several chains involved is the one actually failing before you reissue anything.

What to do before April 2027

Six things, in rough order of how much trouble skipping them causes: take the intermediate bundle your CA issues at every renewal, inventory the validators that are not browsers, find and remove pinned roots, test each trust store against a live chain, diary the three dates, and give air-gapped systems an update cycle. None is urgent this week, and all are cheaper now than during an outage.

1. Install the bundle your CA gives you at each renewal. Not a copy from last time, not one from a knowledge base article. This single habit removes most of the failure modes in this article.
2. Inventory the validators that are not browsers. JVMs, container images, appliances, payment terminals, mobile apps, anything air-gapped. This list is the actual scope of the work and it is usually longer than expected.
3. Find the pins. Grep your mobile and embedded code for pinned certificates and hashes. A pinned root is a release-cycle problem, so it needs the longest lead time of anything here.
4. Test each store against a live chain with the -CAfile check above, rather than assuming a bundle is current because the device is in support.
5. Put the three dates in a calendar: October 15, 2026, April 15, 2027, September 15, 2027. Root schedules are published years ahead and then arrive without a reminder.
6. Give air-gapped systems a trust-store update cycle. A machine with no path to a root update is a machine whose certificate validation has an expiry date, and this migration is not the last one it will miss.

One thing not to do: reissuing your certificate early does not help. A certificate issued today already chains to the new hierarchy at most CAs, so reissuing changes nothing about your exposure. The work is entirely on the validating side of the connection.

FAQ