DigiCert G2/G3 Root Revocations – May 15 Emergency Action Plan

Verified by SSLInsights Editorial Team - Cybersecurity Professionals & SSL/TLS Specialists - Last reviewed: May 2026 | Based on DigiCert official advisories and PKI industry analysis

QUICK DEFINITION

DigiCert G2/G3 Root Revocation

A root revocation occurs when a Certificate Authority invalidates a root or intermediate CA certificate before its natural expiry. When DigiCert revokes its G2 and G3 Intermediate CA (ICA) certificates on May 15, 2026, every end-entity certificate that chains through those ICAs loses its trust anchor — causing browsers to display "not trusted" or "invalid certificate" errors. The end-entity certificates themselves are not revoked, but they become functionally invalid without a valid chain.

Active Issue: DigiCert revoked specific G2 and G3 intermediate CA certificates on May 15, 2026. If your TLS, S/MIME, or code-signing certificate chains through any of the affected ICAs, clients are already blocking your services. Check your chain now and replace affected certificates immediately.

DigiCert revoked several G2 and G3 Intermediate CA (ICA) certificates and two G5 cross-signed root certificates on May 15, 2026. Any website, API, Java application, or enterprise system whose certificate chain passes through a revoked ICA immediately loses browser trust - meaning Chrome, Firefox, Safari, and Edge will display hard "not trusted" warnings. The trigger was a Google Chrome Root Program mandate requiring Certificate Authorities to operate single-purpose, TLS-only root hierarchies rather than multipurpose roots that also issue S/MIME and code-signing certificates.

This is not a theoretical risk. If the revoked ICA sits anywhere between your end-entity certificate and the trusted root, the entire chain is broken. Replacing the ICA alone is not sufficient - you must reissue your end-entity certificate under a replacement ICA that is not on the revocation list.

Why Did DigiCert Revoke G2 and G3 Intermediate CAs?

Google Chrome's Root Program introduced a requirement in 2026 that all Certificate Authorities maintain separate, dedicated root hierarchies for TLS versus other certificate types such as S/MIME and code signing. Multipurpose roots - which previously issued all certificate types from the same hierarchy - no longer satisfy this requirement. Per the Chrome Root Store Policy, Section 3.2.2, CAs must demonstrate clear separation by certificate purpose.

DigiCert's G2 and G3 roots were built as multipurpose hierarchies. To comply, DigiCert is transitioning them into single-purpose TLS-only hierarchies and revoking any ICA that either was used for non-TLS purposes or does not include the Server Authentication Extended Key Usage (EKU) that Chrome now requires for all public TLS certificates.

Which Certificates Are Affected by the May 15 Revocations?

Three categories of end-entity certificates are potentially impacted, depending on which ICA issued them. The table below maps each revoked ICA to its certificate type and the replacement ICA.

How Do You Know If Your Certificate Chain Is Broken?

The most common mistake teams make after a revocation event is assuming their certificate is fine because it has not expired. Expiry and revocation are separate conditions. A valid, unexpired certificate that chains through a revoked ICA will fail CRL and OCSP validation immediately, causing browsers to present a hard block rather than a warning the user can bypass.

To confirm whether your chain passes through a revoked ICA, run your domain through the SSL Checker on SSLInsights. The tool displays each certificate in your chain, including the issuing ICA. Cross-reference the ICA Common Name against the revocation table above. If the names match, your chain is broken and requires immediate reissuance.

What Is the Step-by-Step Fix for a Revoked ICA?

If your chain passes through a revoked ICA, follow these steps in order. Do not skip step 3 - reissuing without confirming the new ICA is a frequent error that extends downtime.

1. Identify the exact ICA:Use the SSL Checker or run  openssl s_client -connect yourdomain.com:443 -showcerts and check the "issuer" field on the intermediate certificate against the revocation table above.
2. Log into DigiCert CertCentral:Navigate to the affected certificate, select Reissue, and choose the replacement ICA listed in the table. Do not generate a new CSR unless your private key has also changed.
3. Confirm the new chain before deploying:After download, verify the new intermediate with openssl verify -CAfile chain.pem yourcert.pem. The output should read "OK" with no revocation warnings.
4. Install and restart:Replace the certificate bundle on your server (Apache, Nginx, IIS, or CDN origin). Always include the full chain - root, intermediate, and end-entity - in the correct order.
5. Verify live:Re-run the SSL Checker on your live domain. Confirm the chain shows the replacement ICA, not the revoked one. Clear any server-side OCSP stapling cache if applicable.

Does This Affect G5 Cross-Signed Certificates and Older Systems?

DigiCert also revoked two G5 cross-signed root certificates on May 15, 2026. A cross-signed root provides an alternative trust path - particularly useful for older Android versions and embedded devices that do not yet include the newer G5 roots in their native trust stores. Once the cross-signed certificate is revoked, those older clients lose their fallback path.

For most modern operating systems, end-entity certificates that chain directly to the G5 root remain valid until expiry, because the primary G5 trust anchor is unaffected. But if you support Android 7.0 or earlier, older Java runtimes (pre-JDK 11), or embedded IoT devices with static trust stores, you should install the replacement cross-signed root certificates that DigiCert published on April 7, 2026 - available from the DigiCert Knowledge Base.

Per SSLInsights' analysis of PKI compatibility patterns across enterprise environments, the systems most often overlooked during root transitions are Java-based API consumers, IoT firmware with hardcoded trust stores, and legacy load balancers that cache intermediate certificates without automatic refresh.

What Happens If You Miss the May 15 Deadline?

If the ICA in your active certificate chain was revoked on May 15 and you have not yet reissued your certificate, browsers are already blocking your users. Chrome, Firefox, Edge, and Safari all perform real-time CRL and OCSP checks. A revoked ICA causes a hard failure - users see "NET::ERR_CERT_AUTHORITY_INVALID" or an equivalent error - and cannot proceed even if they click through warnings, because modern browsers no longer offer a bypass for revoked intermediates.

Mobile apps that perform certificate pinning face a separate issue. If the app pins the ICA certificate rather than the root or the end-entity, the pin breaks when the ICA is revoked and you must push an app update. This is one reason the CA/Browser Forum has long recommended pinning root certificates rather than intermediates.

Is This the Same as the DigiCert G1 Root Removal in April 2026?

No - these are two separate events with different impacts. The DigiCert G1 root removal, which took effect in April 2026, involved removing three older root certificates (DigiCert Global Root CA, DigiCert Assured ID Root CA, and DigiCert High Assurance EV Root CA) from Mozilla's trust store. That action primarily affected a small group of customers still using pre-2015 certificate chains.

The May 15, 2026 G2/G3 ICA revocations are broader in scope. They affect active TLS certificates, S/MIME certificates, and code-signing certificates issued under G2 and G3 hierarchies within the last several years. The root cause for both events is the same - the Chrome Root Program's separation-of-purpose requirement - but they are distinct revocation actions with separate affected certificate lists and separate remediation paths.

Frequently Asked Questions

Does DigiCert revoke my actual SSL certificate on May 15?

No. DigiCert is revoking specific Intermediate CA certificates - not the end-entity SSL/TLS certificates issued by those ICAs. Your certificate remains technically valid. But if the ICA in your trust chain is revoked, browsers treat your certificate as untrusted because the chain is broken. The practical effect is identical to a revoked end-entity certificate: a hard browser block.

Which certificate types are affected by the G2/G3 revocations?

Three types are affected: (1) Public TLS certificates issued by DigiCert Global CA G2; (2) Public S/MIME certificates issued by DigiCert G2 SMIME RSA4096 SHA384 2024 CA1; and (3) Public code-signing certificates issued by several G3 ECC ICAs. Check the full table in this article and cross-reference against the ICA shown in your certificate chain.

What is a G5 cross-signed root and why does it matter?

A cross-signed root is an older root's signature applied to a newer root certificate. It provides a secondary trust path for devices that do not yet include the newer root in their built-in trust store. DigiCert revoked two G5 cross-signed roots on May 15. Devices that relied on the cross-signed path for G5 trust - primarily older Android devices and pre-JDK 11 Java runtimes - will fail to validate unless you deploy DigiCert's replacement cross-signed root certificates.

How do I find out which ICA issued my certificate?

Run your domain through an SSL Checker, or use OpenSSL: openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -issuer. The "O=" and "CN=" fields in the issuer line show the ICA Common Name. Compare that name against the revocation table in this article. A match means your chain is affected.

Can I reuse my existing private key when reissuing?

Yes. You do not need to generate a new private key unless your security policy requires it or the key has been compromised. Reissuing against the replacement ICA with your existing CSR is sufficient to restore chain validity. Generate a new key only if you rotate keys on a fixed schedule or if your previous key was exposed.

Will this affect Let’s Encrypt or other free certificate users?

No. Let's Encrypt operates its own independent root hierarchy (ISRG Root X1 and X2) and is not part of DigiCert's G2/G3 infrastructure. This revocation event is specific to certificates that chain through DigiCert's G2 and G3 root hierarchies and their associated ICAs. Sectigo, GlobalSign, and other CAs have their own separate root hierarchies and are not affected by this action.

Next Steps: Act Before Your Users See Errors

The May 15, 2026 DigiCert G2/G3 revocations are not a future risk - they are an active event. If your certificate chain passes through any of the revoked ICAs listed in this article, your site, API, or application is already presenting trust errors to users. Run an SSL Checker on every domain in your infrastructure, not just your primary site. APIs, admin panels, mail servers, and code-signing pipelines are all common blind spots.

Reissuance under a replacement ICA is the only fix. Updating intermediate bundles alone will not resolve the issue if your end-entity certificate was issued by the revoked ICA. Log into DigiCert CertCentral, reissue your affected certificates under the correct replacement ICA, verify the full chain before deploying, and then push the update to every server, CDN origin, and load balancer in your stack.

Key insight: The G2/G3 revocations follow the April 2026 G1 removal. This is a pattern - the PKI ecosystem is actively enforcing purpose-separated hierarchies. Audit your certificate inventory quarterly so future trust store changes do not catch your infrastructure unaware.