DigiCert Revoked G2/G3 ICAs: Is Your Site Affected?
DigiCert revoked multipurpose G2 and G3 intermediate CAs on May 15, 2026 to meet Chrome's dedicated TLS hierarchy rules. Check if your certs are affected.
The DigiCert G1 root got distrusted by Chrome and Firefox in April. Barely a month later, DigiCert went further: on May 15, 2026, the company revoked several intermediate CA certificates under its G2 and G3 root hierarchies. If your TLS, code signing, or S/MIME certificates were issued by one of the affected intermediates, browsers now treat your site as untrusted, even though your end-entity certificate itself was never revoked.
This wasn’t a browser policy change. DigiCert initiated the revocation on its own to comply with Google Chrome Root Program rules requiring dedicated, single-purpose root hierarchies for TLS issuance. The old multipurpose intermediates that issued TLS, code signing, and S/MIME certificates from the same root had to go.
What got revoked
On May 15, DigiCert revoked these intermediate CA certificates:
The most impactful one is DigiCert Global CA G2, which sat under DigiCert Global Root G2 and was used to issue public TLS certificates. It lacked the Server Authentication extended key usage (EKU) that Chrome now requires. Its replacement is DigiCert Global G2 TLS RSA SHA256 2020 CA1.
They also revoked DigiCert G2 SMIME RSA4096 SHA384 2024 CA1 (for S/MIME email certificates, replaced by DigiCert Assured ID SMIME RSA2048 SHA256 2021 CA1) and two G3 code signing ICAs under DigiCert Global Root G3, replaced by DigiCert Assured ID G3 CS ECC384 SHA384 2025 CA1.
Two G5 cross-signed root certificates were also revoked. These provided backward-compatible trust paths through the older G3 root.
Your certificate looks valid. The chain isn’t.
DigiCert did not revoke end-entity certificates. Your TLS certificate is technically still active in their systems. But the intermediate CA that issued it has been revoked, so browsers can’t build a valid trust chain from your certificate to a trusted root. Visitors get security warnings. Automated systems reject your endpoints.
What makes this annoying to diagnose: an admin checking the certificate’s validity date will see months of remaining life. Monitoring tools that only check expiration dates won’t catch it. The certificate itself is fine. The chain above it is not.
Java is an even bigger problem
Java handles certificate validation differently from browsers. Browsers typically evaluate trust based on the certificate’s status when it was issued. Java checks the current revocation status of every certificate in the chain. The moment an ICA gets revoked, Java considers every certificate that ICA ever issued as untrusted. No grace period. No exceptions.
If you run Java services that use code signing certificates from the affected G3 intermediates, any code that wasn’t properly timestamped will fail validation as soon as the revocation propagates. Timestamped signatures survive. Everything else breaks.
What to do about it
If you’re a DigiCert customer, what you need to do depends on what you’re running.
TLS certificates issued by DigiCert Global CA G2 need to be reissued under the replacement ICA (DigiCert Global G2 TLS RSA SHA256 2020 CA1). This is the most common scenario and the most likely to cause visible outages.
S/MIME certificates should be reissued under the new S/MIME-specific ICA if you still need them.
Code signing certificates from the G3 intermediates require attention too. Resign any code that wasn’t timestamped. Timestamped signatures will survive, but un-timestamped binaries need fresh signatures from the replacement ICA.
If you’re using G5 cross-signed roots, download the updated cross-signed root certificates from DigiCert’s knowledge base and swap them into your chain files.
A rough month for PKI
Google wants clean separation between TLS, code signing, and S/MIME hierarchies, so a compromise in one area doesn’t bleed into the others. Reasonable enough. But for organizations managing certificates across multiple use cases, it means more intermediates to track and more places where chain breaks can hide.
This revocation follows the G1 distrust in April, the Let’s Encrypt issuance halt on May 8, and the DigiCert support portal breach earlier this month. May 2026 has been rough for certificate infrastructure. The organizations that got through it cleanly are the ones with automated certificate lifecycle management and chain monitoring, not just expiration alerts.
Don’t get caught by the next one
If you’re still tracking certificates by expiration date alone, this kind of revocation will blindside you. SSLcalendar.com sends reminders before your certificates expire. SSLboard.com goes further with chain validation, root trust monitoring, and vulnerability detection, so you catch intermediate CA changes before they take your site down.
Sources: DigiCert Knowledge Base — Transitioning G2 and G3 Roots to Dedicated TLS Hierarchies, DigiCert — Root Strategy: Aligning with Industry Standards, Security Boulevard — DigiCert G2 & G3 Root Certificate Changes May 2026, Google Chrome Root Program Policy