DigiCert G1 Retirement 2026: A Turning Point in Web PKI Evolution

Mozilla and Google Chrome will revoke the G1 root certificates of DigiCert on April 15, 2026. When the certificate you are using TLS chains to one of those roots, the browsers immediately do not trust it. A security warning is shown to your users. Breaking your login flows. Your payment page is a wall.

It is not a browser bug. Your infrastructure on the nose.

How Can It Disrupt Your Secure Connections?

This is what is particularly dangerous: even with a certificate that is not expired, not revoked, not with any problems on paper, a warning about untrusted prompts as soon as this change comes into effect. Having an expiry date on your cert is irrelevant when the root that it chains to is no longer trusted.

The majority of DigiCert customers were transferred to G2 hierarchies back in March 2023 and do not have to do anything. However, to the organisations that continue to use older chains, particularly within a legacy environment, custom trust stores, or non-standard deployments, this is a very real, business-affecting risk.

Important Dates, Changes, and Actions

This isn’t just One Change: It’s a Sequence

The most pressing one is the G1 removal, although it is a subset of a larger cleanup of the public WebPKI. The following is the entire schedule:

G1 Root Removal of Chrome and Mozilla

Three particular roots are pulled: DigiCert Global Root CA, DigiCert Assured ID Root CA and DigiCert High Assurance EV Root CA.

Any active TLS certificates that exclusively chain to these roots instantly lose their trust with Chrome and Firefox. No difference in certificates on G2 or G3 hierarchies.

DigiCert withdraws many G2 and G3 intermediate CA certificates to provide non-TLS products such as S/MIME and Code Signing, and two G5 cross-sign root certificates.

In case your chain of certificates relies upon any of these, validation is lost. This one traps those organisations that assumed that the G1 change was not relevant to them.

Client Authentication EKU has been deleted from the public TLS certificates

DigiCert eliminates the clientAuth extended key usage on all public TLS certs of all brands: DigiCert, GeoTrust, Thawte, RapidSSL, and Encryption Everywhere.

In case your organisation relies on public certificates to make mutual TLS or server-server authentication, you should have a migration plan long before this date.

Who’s actually at Risk?

This is where most organisations get blindsided. They check their primary domain, see it’s fine, and close the ticket. Then something breaks in a partner integration at 2 am on a Tuesday.

You’re exposed if any of these describe your environment:

• Active TLS certificates issued from a G1 root hierarchy that expire after April 15, 2026
• Custom trust stores, manually built CA bundles, or certificate pinning in internal applications or devices
• Network appliances, VPNs, mail gateways, load balancers, or IoT devices with hardcoded root trust that rarely get updated
• B2B integrations, reverse proxies, or machine-to-machine connections that validate the full certificate chain
• Legacy admin subdomains, staging environments, or partner portals that slip through normal renewal cycles
• Cross-signed compatibility workarounds put in place years ago and never revisited
• Standard websites renewed normally after March 2023 already on G2, no action needed

The systems that cause the most painful outages aren’t the ones anyone is watching. They’re the secondary services, the older subdomains, the appliances in the server room that “just work” until they don’t. That’s exactly where G1 chains are most likely hiding.

What to do Right Now

If you follow these four steps in order, you are good to go. 

Step 01: Run a full certificate inventory

Go beyond your main domain. Map every public certificate in use on admin portals, APIs, B2B endpoints, appliances, VPNs, mail gateways, and any service that uses a public cert. Assign a business and technical owner to each one.

Step 02: Trace the full trust chain

The brand on the cert GeoTrust, RapidSSL, Thawte doesn’t tell you which root it chains to. You need to verify each deployment’s actual trust path. DigiCert publishes G1-to-G2 intermediate mappings to make this easier.

Step 03: Reissue affected certs into G2 or G3

For every G1 certificate expiring after April 15, reissue now. In most cases, you don’t need to generate a new private key. This is usually a reissue, not a full rebuild. Confirm with your product’s specific policy before you start.

Step 04: Test client-side trust dependencies

Reissuing the server certificate is only half the job. Old devices, agents, and applications that expect the G1 root will still reject the new chain. Test compatibility on every client, integration, and endpoint that touches the updated certificate.

A Certificate is no longer a One-time Purchase

The G1 removal isn’t an isolated event. It is a part of a much greater change in how the web handles certificate trust. There are shorter maximum certificate lifespans that are enforced.

Multi-perspective issuance checks are already being rolled out. Single-purpose root hierarchies are emerging as the new norm in all major browser applications.

Organisations that continue to consider SSL as a one-time buy and forget-about-it task are going to continue to be caught unawares each time one of these changes hits the ground.

The ones who give actual visibility into their certificate infrastructure, with each cert owner knowing where it is deployed, which chain it is in, and when it is due to be renewed, and when it is due to be revoked, see every deadline as a regular working operation, not a crisis.

It is not a matter of not having a browser warning this year, but what you do before April 15. It is about developing the process that safeguards you in all the changes thereof.

Conclusion

This isn’t just another certificate update. It’s a wake-up call.

April 15, 2026, won’t break everything overnight. It will reveal the holes that you were unaware of: forgotten certificates, old systems, and unspoken dependencies that have not been accessed in years.

Those organisations that do so will consider it a normal migration. The delays of the ones? They will find the problem when users are faced with a security warning, and at this point, it is already affecting business.

Other Major Updates of 2026