DigiCert G1 Root CA Distrust: Act Before April 15

In two weeks, Chrome and Firefox will stop trusting any TLS certificate that chains to the DigiCert Global Root CA — the original, first-generation root that DigiCert has been issuing against for over a decade. April 15, 2026 is the hard deadline, and for organizations that haven’t migrated to DigiCert’s newer G2 or G3 root hierarchies, the consequences range from browser warnings on public websites to silent authentication failures in backend services.

This isn’t a hypothetical risk. Rollbar already migrated on March 15 — and documented how legacy clients without G2 trust in their certificate stores experienced connection failures. Microsoft, Oracle, and Cisco all issued urgent advisories in the months prior. The clock is running down.

What’s Actually Changing

Mozilla and Google Chrome are removing the DigiCert Global Root CA (sometimes referred to as G1) from their root trust stores on April 15, 2026. This means that after that date, any TLS certificate with a chain that terminates at the G1 root will be considered untrusted by Chrome and Firefox users.

The newer DigiCert Global Root G2 and DigiCert Global Root G3 roots are not affected — certificates chaining to those roots will continue to be trusted normally. This is specifically about the original, older G1 root, which DigiCert and browser vendors have been moving away from as part of an industry-wide shift toward dedicated TLS root hierarchies with stronger security properties.

Which Services and Organizations Are Affected

The scope of impact is broad, because DigiCert has been one of the world’s largest certificate authorities for years. Services that issued certificates under G1 — and have not yet reissued them under G2 or G3 — will break on April 15 for Chrome and Firefox users.

Several major platforms have already issued warnings or completed migrations:

Microsoft Azure: Azure’s managed TLS feature (used by Azure Front Door, App Service, Static Web Apps, API Management, and Azure Storage) is migrating all certificates from G1-chained CAs to CAs under DigiCert Global Root G2 and G3. Microsoft explicitly warned that customers who haven’t updated their configurations “will have a service outage” — guaranteed — once the current certificate expires or is revoked.
Exchange Online: Microsoft required organizations to trust DigiCert Global Root G2 in their email infrastructure by March 22, 2026, to avoid SMTP delivery failures to and from Exchange Online.
Oracle Autonomous Database: Oracle announced that mTLS wallets generated before January 28, 2026 use G1 root certificates and will stop working after April 15. Customers need to download new wallets and update their connections.
Rollbar: The error-monitoring platform migrated its api.rollbar.com endpoint from G1 to G2 on March 15, 2026. Users with outdated certificate stores or custom trust configurations experienced connection failures during and after the transition.
Cisco Duo: Duo’s CA bundle — which relies on roots used to authenticate connections to Duo’s cloud service — set a March 31 soft deadline for customers to update, ahead of the April 15 browser distrust date. Organizations running unsupported Duo versions risk complete MFA failures.

The Hidden Risk: Certificate Pinning

For most public websites, the fix is straightforward: reissue your certificates under a G2 or G3 root, and browsers will trust them again. But for organizations that practice certificate pinning — hardcoding trust for a specific root or intermediate certificate in their applications or devices — the migration is more involved.

If your application pins against the DigiCert Global Root CA, it will reject G2 and G3 certificates even after migration. You need to update your pinned certificates before April 15, or your app will break for its own users regardless of what your CA does.

Microsoft’s guidance on this point is blunt: “Static pinning is strongly discouraged due to operational risk.” This is why: certificate changes upstream will silently break pinned clients, often with no clear error message for the end user.

What You Need to Do Now

With 14 days remaining, the actions depend on your situation:

Check your existing certificates: Identify any certificates in your infrastructure that chain to DigiCert Global Root CA. Tools like SSLboard.com can scan your domains and surface the full certificate chain, showing you exactly which root your certificates terminate at.
Reissue affected certificates: Contact DigiCert or your reseller and request reissuance under the G2 or G3 root hierarchy. This is typically a straightforward process and does not require generating a new private key.
Update trust stores: For internal systems, IoT devices, or any client that maintains its own certificate store (rather than relying on the OS), add DigiCert Global Root G2 and G3 and verify they are trusted.
Remove certificate pins: If your application or SDK pins to the G1 root, remove or update that pin immediately. Add G2 and G3 to your trust anchors.
Audit third-party dependencies: As with the Duo situation, your own certificates might be fine while a service you depend on is still running on G1. Check whether critical SaaS tools, identity providers, or APIs have communicated anything about this migration.

The Broader Pattern

This incident fits a recurring pattern in PKI: a root certificate that was considered acceptable for years gradually loses favor as security standards evolve, browsers announce a distrust date, and the industry scrambles to migrate before the deadline. Entrust went through a similar process in 2024. DigiCert’s G1 root is going through it now.

What makes it particularly disruptive is that G1 certificates can be found in unexpected places — embedded in firmware, hardcoded in SDK trust bundles, baked into mobile apps that haven’t been updated in years. The visible surface of the web is relatively easy to migrate. The long tail of internal services and legacy clients is where outages will actually happen.

Don’t Wait for April 15

To avoid becoming the next headline, consider using SSLcalendar.com to track certificate expirations across your domains and receive timely alerts before deadlines become crises. For full visibility into the TLS health of your infrastructure — including certificate chain details, root trust status, and vulnerability detection — SSLboard.com provides comprehensive certificate surveying so you can identify G1-chained certificates before they stop working.

April 15 is a fixed date. The renewal queue is not.

Sources: Microsoft Learn — Changes to the Managed TLS Feature, Oracle Cloud — DigiCert G1 Certificate Distrust Announcement, Rollbar Status — DigiCert G1 Root Distrust Incident, DigiCert Knowledge Base — Root and Intermediate CA Certificate Updates, Microsoft Exchange Team Blog — Trust DigiCert Global Root G2