DigiCert / Chrome & Mozilla root programs

DigiCert's G1 Roots Lose Browser Trust — Affecting RapidSSL, GeoTrust, and Thawte Too

DigiCert's G1 Roots Lose Browser Trust — Affecting RapidSSL, GeoTrust, and Thawte Too

On April 15, Google Chrome and Mozilla Firefox removed default trust for TLS certificates chaining to DigiCert's first-generation (G1) root certificates. Any certificate still validating up through a G1 root now triggers a browser security warning, regardless of which brand name appears on the certificate itself.

Why this matters beyond "DigiCert" specifically

This is the detail most likely to catch people off guard: DigiCert acquired Symantec's certificate business in 2017, which included GeoTrust, RapidSSL, and Thawte. All three brands issue from shared underlying DigiCert infrastructure, and a certificate bought under any of those names could still be chaining to an old G1 root without anything on the certificate itself obviously flagging that fact. The brand name on your invoice doesn't tell you which root hierarchy your specific certificate actually uses.

Most customers were already unaffected

DigiCert transitioned its default issuance to second-generation (G2) root hierarchies back in 2023, so the overwhelming majority of certificates issued since then were never on a path to be affected by this at all — the same kind of root/intermediate relationship our chain of trust guide walks through. The risk was narrow and specific: customers with genuinely long-lived G1-chained certificates, or infrastructure with hardcoded trust for the old root, who hadn't reissued since the 2023 transition.

How to actually check which root your certificate uses

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -issuer

This shows your certificate's issuer — cross-reference against DigiCert's published G1-to-G2 intermediate mapping if the result doesn't obviously tell you which generation you're on. If you are affected, the practical fix in most cases is a straightforward reissue against your existing key, not a full new certificate order — DigiCert's guidance describes this as usually the simpler operation of the two.

The part that's easy to miss

Reissuing the server-facing certificate is only half the job. Any older device, background agent, or embedded application that has the G1 root hardcoded as an explicit trust anchor — rather than relying on the OS or browser's own trust store — will keep rejecting the new chain until that trust anchor is updated too. Testing across every actual client touching the certificate, not just confirming the server-side reissue succeeded, is the step DigiCert's own advisory specifically calls out as commonly overlooked.

This is our own summary and analysis of publicly reported news, written independently — not a reproduction of any single source's article. Where we reference a specific announcement, we link to it or name the organization directly.