DigiCert G1 Root Removal: What You Must Do Before April 2026

The removal of DigiCert’s G1 root is an important step in the history of the evolution of the public key infrastructure (PKI). On or after April 15, 2026, Google Chrome and Mozilla Firefox will stop trusting any certificate that is part of a chain back to a DigiCert’s G1 roots cert.

At first glance, this appears to be a typical decommissioning; however, the issue is more complex than it seems since organizations will find it difficult to replace their certs, due principally to their lack (or limited visibility) into where they have hidden dependencies scattered throughout their infrastructure.

This document describes what will change, who is impacted, and how organizations can take pre-emptive steps to identify and reduce risk before any disruptions occur.

What Is Changing in April 2026?

Starting in 2026, the major browser vendors Google, Mozilla, Apple, and Microsoft will have stronger policies concerning all certificate authorities (CAs) that issue SSL/TLS certificates.

The following areas of change will occur in how CAs and their root programs are viewed and issued upon:

• Transitioning to a single-purpose root hierarchy rather than an existing multi-purpose hierarchy;
• Establishing stricter EKU policy requirements in conjunction with existing CA policies;
• Issuing CA’s no longer authorized to issue verifiable certificates;
• Eliminating any existing cross-signed or legacy root programs that may include existing DigiCert G1 roots after Apr 15, 2026.

In light of these changes, all future TLS certificates rooted exclusively to any of the DigiCert G1 roots, such as:

• DigiCert Assured ID Root CA,
• DigiCert Global Root CA,
• DigiCert High Assurance EV Root CA

 will not be trusted by Chrome or Firefox.

Why DigiCert G1 Root Removal Matters

The removal of DigiCert Roots from browsers affects trust throughout modern digital systems. Although the browser trust stores are where the change occurs, browser trust will have much broader effects on:

• APIs and microservices
• Load balancers and reverse proxies
• VPNs and mail gateways
• IoT devices and appliances
• B2B integrations

A common misunderstanding is that a certificate’s validity period guarantees trust. However, an unexpired certificate can be rejected if the trust chain ends at a root that is no longer recognised.

This creates an unknown risk for organisations focused only on expiration monitoring, and not on the associated certificate chain of trust, root dependencies, or client-side validation behaviour.

Trust ≠ Certificate Validity

The notion of certificate validity is not equivalent to trust. This is a continuing issue within the context of DigiCert G1 root removal.

A TLS certificate could be valid and operate properly, yet if the chain of trust is broken by an intermediary that is no longer trusted by browser manufacturers such as Google (Chrome) or Mozilla (Firefox), the TLS certificate will be untrusted (rejected).

Trust is based not only on the expiration date of the certificate, but also on the entire trust chain (root, intermediate, and end-entity). If a root certificate is removed from trusted stores, then all of the TLS certificates that rely upon the root certificate subsequently become untrusted within that environment.

Also Read: Root Certificates vs. Intermediate Certificates

Therefore, organisations may experience an immediate interruption in operation even though their certificates have several months or years remaining on their term of validity, and this further illustrates the necessity of monitoring both trust chains and validity end-dates.

Who Is Most Affected?

Low Risk

• Standard HTTPS websites
• Certificates renewed after 2023 (already on G2/G3)
• No custom trust configurations

Medium to High Risk

Organizations that:

• Still use G1-issued certificates
• Require trust in Chrome/Firefox environments
• Maintain custom trust stores
• Use certificate pinning
• Rely on older systems or libraries

Highest Risk Environments

• Legacy infrastructure with minimal updates
• B2B integrations and external service dependencies
• Systems using cross-signing or manual chain configuration
• Poorly documented certificate deployments

Timeline of Events

Date	Change/Event	What Happens	Impact	Required Action
March 8, 2023	Transition to G2 issuance	DigiCert begins default issuance from G2 hierarchies	Reduces dependency on legacy G1 roots	No action (automatic for most renewals)
April 15, 2026	G1 Root Removal	Chrome & Mozilla remove trust in DigiCert G1 roots	G1-based certificates become untrusted in browsers	Reissue/renew certificates to G2 or G3
May 15, 2026	ICA & Cross-Signed Certificate Revocation	Revocation of select G2/G3 intermediate CAs and G5 cross-signed roots	Potential validation failures, broken trust chains	Replace ICAs, update chains, reissue certificates
March 1, 2027	Single-EKU Enforcement	Removal of Client Authentication EKU from public TLS certs	mTLS and clientAuth use cases impacted	Move to Private PKI or X9 PKI solutions

What Could Break After April 15, 2026?

Visible Issues:

• Browser security warnings
• “Certificate not trusted” errors

Less Visible (More Critical):

• TLS handshake failures
• API connection drops
• Integration failures
• Incomplete logs with generic SSL errors

How to Assess the Impact on Your Certificate Infrastructure?

A structured approach is critical. Instead of rushing to replace certificates, follow this 4-step assessment model:

Inventory All Certificates

Identify all public certificates across:

• Websites and subdomains
• Admin panels
• APIs and integrations
• VPNs and gateways
• Devices and appliances

Most issues hide in non-obvious systems

Identify the Certificate Chain

For each certificate, determine:

• Intermediate CA
• Root CA

You must confirm whether it chains to:

• ❌ G1 (risk)
• ✅ G2/G3 (safe)

Analyze Client-Side Dependencies

Even after fixing certificates, problems may persist if:

• Clients pin old certificates
• Devices use outdated trust stores
• Applications use custom validation logic

Migration success depends heavily on client environments

Review Historical Exceptions

Look for:

• Cross-signed roots
• Manual certificate bundles
• Compatibility workarounds

These “temporary fixes” often become long-term risks

Also Read: Sectigo Public Root CA Migration: What SSL Users Must Know

Conclusion 

Keeping up-to-date with changing WebPKI standards is now more than just an option; it has become compulsory. To ensure the continuing security and integrity of the overall system, you should review your certificate infrastructure on a regular basis, remove any legacy components that are still present within it, and engage in best practices for the future.

Follow us closely to receive constant information about the latest news from the industry as well as expert advice regarding how to maintain a secure, compliant, and prepared Infrastructure. 

Search