Knowledge Base

The certificate industry is changing how certificate authorities (CAs) operate and manage publicly trusted root and intermediate certificates. Soon, root programs (Google Chrome, Apple, Mozilla, and Microsoft) will require CAs, such as DigiCert, to move away from multipurpose root hierarchies to dedicated, single-purpose hierarchies to enhance security and digital trust.

DigiCert has aligned its root strategy with the browser requirements. These requirements specifically target the public WebPKI and do not affect the following:

• X9 PKI for TLS
  These certificates operate independently of the standard WebPKI (browsers). They follow their own community-driven timelines for root updates.

• Private, Government, and Other Non-Browser Root Stores
  Because these are managed by entities other than the browsers, they are not impacted by these specific browser mandates.

Action Items:

1. Ensure you are not pinning any publicly trusted certificate, root, or otherwise.
2. Always install the full certificate chain instead of just the end-entity certificate.

In this article

• DigiCert Transitioning TLS Certificate Issuance to G5 TLS Root Hierarchies
  • Does the move to G5 TLS root hierarchies affect me?

• Transition to single-EKU Public TLS Certificates
  • Does the transition to single-EKU certificates affect me?

• DigiCert to Replace G5 TLS Intermediate CA Certificates and Begin Annual ICA Rotation
  • Does the ICA certificate replacement and new rotation policy affect me?

• Non-browser Devices: Consider Private TLS Certificates

• Revocation of Intermediate (ICA) and Cross-Signed Certificates
  • Does the ICA and cross-signed root certificates revocation affect me?

• Mozilla and Google Chrome G1 Root Removal
  • Does the G1 root removal affect me?

DigiCert Transitioning TLS Certificate Issuance to G5 TLS Root Hierarchies

Start date: October 15, 2026

On October 15, 2026, DigiCert will start issuing public TLS certificates from the DigiCert TLS RSA4096 Root G5 and DigiCert TLS ECC P384 Root G5 root hierarchies by default.

By default, TLS certificates issued after this date, including new orders, renewals, reissues, and duplicates, will chain to DigiCert’s newer G5 public TLS roots.

This change applies to all public TLS certificates, including DV, OV, and EV, across all DigiCert brands: DigiCert®, GeoTrust®, Thawte®, RapidSSL®, and Encryption Everywhere®. 

Why is this happening?

The Google Chrome Root Program is limiting certificate authorities to a maximum of two active TLS roots in the Chrome Root Store starting September 15, 2027.

To enforce the two-root limit, the Chrome Root Store will only support DigiCert's DigiCert TLS RSA4096 Root G5 and DigiCert TLS ECC P384 Root G5 hierarchies starting on September 15, 2027. 

Why is DigiCert moving to G5 root hierarchies on October 15, 2026?

DigiCert selected October 15, 2026, for the transition because:

• Your public TLS certificates issued from the DigiCert TLS RSA4096 Root G5 and DigiCert TLS ECC P384 Root G5 hierarchies will continue to be trusted by Google Chrome and other major browsers.

• Moving to DigiCert G5 root hierarchies now gives you time to identify and resolve any deployment or compatibility issues before the DigiCert Global Root G2 (RSA) and DigiCert Global Root G3 (ECC) root hierarchies are removed from Chrome and other major browsers.

Does the move to G5 TLS root hierarchies affect me?

Yes. This change applies to all DigiCert customers using DigiCert public TLS certificates. However, for most DigiCert customers, no action is required if you always install the certificate chain provided by DigiCert.

Starting October 15, 2026, all new, reissued, and duplicate public TLS certificates will be issued from G5 TLS root hierarchies by default.

For mission-critical dependencies that rely on the DigiCert Global Root G2 (RSA) and DigiCert Global Root G3 (ECC) root hierarchies, please contact your account manager immediately. 

What do I need to do?

In most cases, no action is required if you follow TLS certificate installation best practices, such as installing the issuing intermediate certificate along with your TLS certificate. 

The intermediate CA certificate links your TLS certificate to its trusted root, helping browsers, operating systems, and applications trust the certificate protecting your site or application.

Starting October 15, 2026, when you order, renew, reissue, or duplicate a public TLS certificate, DigiCert will issue it from a G5 TLS root hierarchy by default.

Additional action may be required in the following use cases:

Use case	Action required
Only installing the TLS certificate	Always install the complete certificate chain provided by DigiCert. This may include the server certificate, intermediate CA certificate, and cross-signed root certificate.
Managing a trust store	Add and trust the G5 root and intermediate CA certificates.
Hard-code root or intermediate CA certificate trust	Do not hard code root or intermediate CA certificate trust. Remove any policies that require hard coding CA certificate trust. WebPKI environments (such as browsers) require regular intermediate CA and root certificate updates. Hard coding certificate trust limits crypto-agility and can cause service disruptions.
Pinned root or intermediate CA certificates	Do not pin root or intermediate CA certificates. Remove any policies that require pinning. WebPKI environments (such as browsers) require regular intermediate CA and root certificate updates. Pinning limits crypto-agility and can cause service disruptions. For more information, read our blog, Stop Certificate Pinning.

Transition to Single-EKU Public TLS Certificates

Deadline: March 1, 2027

On March 1, 2027, DigiCert will remove the Client Authentication EKU from certificates chaining to the DigiCert Global G2 root, the DigiCert Global G3 root, the DigiCert TLS RSA4096 Root G5, and the DigiCert TLS P384 Root G5. This change aligns with evolving CA/Browser Forum and root program requirements that restrict the use of the clientAuth EKU in publicly trusted TLS certificates. Learn more about why we are removing the client authentication EKU from public TLS certificates.  

This change affects all DigiCert's public TLS certificates: DV, OV, EV, EU Qualified Website Authentication Certificate (QWAC), and EU QWAC PSD2, and all DigiCert brands: DigiCert®, GeoTrust®, Thawte®, RapidSSL®, and Encryption Everywhere®.

Why is this happening?

The Google Chrome Root Program requires CAs to stop including the Client Authentication extended key usage (EKU) in public TLS certificates.

Does the transition to single EKU certificates affect me?

• Standard Website Owners: If you only use TLS certificates to secure websites (HTTPS), no action is required.
  
• mTLS Users: If your organization uses public TLS certificates for Mutual TLS (mTLS) or server-to-server identity, you are impacted, and action is required. 
  DigiCert recommends that you stop using the clientAuth EKU in all public certificates.

DigiCert has excellent options available for our customers and partners who require the client authentication EKU beyond March 1, 2027.

If you require the clientAuth EKU in your TLS certificates	Description
X9 PKI for TLS certificate	Transition to DigiCert’s X9 PKI for TLS certificates to secure communications involving multiple organizations. X9 PKI for TLS certificates can have both Client Authentication and Server authentication EKUs. Learn more about X9 PKI for TLS.
Private Trust	Transition to Private PKI as a service for business needs that are strictly internal. Learn more about Private PKI as a service.
Existing DigiCert Roots	If you require non-browser ubiquity, you should use existing DigiCert root hierarchies to issue TLS certificates that include the clientAuth EKU. Available root hierarchies: DigiCert Assured ID Root G2 (RSA) DigiCert Assured ID Root G3 (ECC) However, these certificates will not be trusted in Google Chrome or Mozilla Firefox.

 

DigiCert to Replace G5 TLS Intermediate CA Certificates and Begin Annual ICA Rotation

Start date: October 15, 2027

DigiCert is updating its TLS intermediate CA certificate rotation policy. Beginning October 15, 2027, DigiCert will rotate TLS intermediate CA certificates approximately once every 365 days.

Beginning October 15, 2027: 

• DigiCert will begin issuing public TLS certificates from new TLS G5 RSA and G5 ECC intermediate CA certificates by default.

• DigiCert will replace public TLS intermediate CA certificates approximately once every 365 days.

• By default, TLS certificates issued after this date, including new orders, renewals, reissues, and duplicates, will be issued from the new G5 intermediate CA certificates.

This change applies to all public TLS certificates, including DV, OV, and EV, across all DigiCert brands: DigiCert®, GeoTrust®, Thawte®, RapidSSL®, and Encryption Everywhere®.

Note about custom ICA certificates: DigiCert is still evaluating the impact to custom ICA certificates. If you have a custom ICA certificate, DigiCert will communicate any related changes separately. 

Why is this happening?

This change aligns with the Google Chrome Root Program's move toward a more frequent intermediate CA rotation model. More frequent ICA rotations improve crypto-agility and reduce long-term reliance on any single ICA certificate.

Does the ICA certificate replacement and new rotation policy affect me?

Yes. This change applies to all DigiCert customers using public DV, OV, EV, QWAC, and QWAC PSD2 certificates issued from G5 intermediate CA certificates being replaced on October 15, 2027. However, for most DigiCert customers, no action is required if you always install the complete certificate chain provided by DigiCert.

Starting October 15, 2027, New, reissued, and duplicate public TLS certificates will be issued from the new G5 TLS ICA certificates by default. 

What do I need to do?

In most cases, no action is required if you follow TLS certificate installation best practices, such as installing the issuing intermediate CA certificate along with your TLS certificate.

The intermediate CA certificate links your TLS certificate to its trusted root, helping browsers, operating systems, and applications trust the certificate protecting your site or application.

Starting October 15, 2027, when you order, renew, reissue or duplicate a public TLS certificate, DigiCert will issue it from the new G5 TLS intermediate CA certificates by default. 

Additional action may be required in the following scenarios: 

Use case	Action required
Only installing the TLS certificate	Always install the complete certificate chain provided by DigiCert. This may include the server certificate, intermediate CA certificate, and cross-signed root certificate.
Managing a trust store	Add and trust the new G5 intermediate CA certificates.
Hard-coded intermediate CA certificate trust	Do not hard code intermediate CA or root certificate trust. Remove any policies that require hard coding CA certificate trust. WebPKI environments (such as browsers) require regular intermediate CA and root certificate updates. Hard coding certificate trust limits crypto-agility and can cause service disruptions.
Pinned intermediate CA certificates	Do not pin intermediate CA or root certificates. Remove any policies that require pinning. WebPKI environments (such as browsers) require regular intermediate CA and root certificate updates. Pinning limits crypto-agility and can cause service disruptions. Read our blog, Stop Certificate Pinning.

Non-browser Devices: Consider Alternatives to Brower-trusted TLS Certificates 

For non-browser devices, publicly trusted TLS certificates may not be required. In these environments, communication typically occurs between a device and a server, not between a browser and a public website.

If your devices use TLS certificates for mutual TLS (mTLS), server-to-server authentication, APIs, or other non-browser authentication use cases, DigiCert recommends moving these use cases away from publicly trusted TLS certificates. This helps reduce dependency on public TLS industry requirements and browser-driven changes. 

Consider the following options instead

X9 PKI for TLS

Transition to DigiCert’s X9 PKI for TLS certificates to secure communications involving multiple organizations. Governed by the ASC X9 PKI Policy and Operations teams, the X9 PKI is an independent certificate policy unaffiliated with the browsers, but that ensures interoperability by using a common root of trust.

X9 PKI for TLS certificates can have both client and server authentication EKUs, meeting today's unique need for control, security, flexibility, and scalability with encryption, identity, and cross certification capabilities. Learn more about X9 PKI and schedule a consultation.

Private Trust

Transition to Private PKI as a service for business needs that are strictly internal. DigiCert can configure and operate a private PKI for your organization, leveraging our operational expertise and investments in security. Learn more. 

Non-browser public trust

Transition to existing DigiCert root hierarchies for business needs that require nonbrowser ubiquity. You can use these DigiCert root hierarchies to issue TLS certificates that include the clientAuth EKU:

• DigiCert Assured ID Root G2 (RSA)

• DigiCert Assured ID Root G3 (ECC)

TLS certificates issued from these hierarchies will not be trusted in Google Chrome or Mozilla Firefox. Contact your account representative to learn if this option is right for you.

Revocation of Intermediate (ICA) and Cross-Signed Certificates

Deadline: May 15, 2026

DigiCert will revoke several G2 and G3 intermediate CA (ICA) certificates and two G5 cross-signed root certificates on May 15, 2026.

Why is this happening?

The Google Chrome Root Program requires Certificate Authorities (CAs) to use dedicated TLS root hierarchies for issuing public TLS certificates. To transition our G2 and G3 TLS root hierarchies to single-purpose root hierarchies dedicated to issuing public RSA and ECC TLS certificates, DigiCert must revoke several G2 and G3 ICA certificates used to issue non-TLS certificates, such as S/MIME and Code Signing. We must also revoke a code-signing cross-signed root certificate. Learn more about the transition from multipurpose G2 and G3 roots to dedicated TLS root hierarchies.

Additional revocations

DigiCert must revoke a TLS ICA certificate and a TLS cross-signed root certificate that do not contain any EKUs. Google Chrome policy requires CAs to include only the Server Authentication (serverAuth) and optionally, Client Authentication (clientAuth) EKUs in their ICA and cross-signed root certificates.

See which ICA and cross-signed root certificates are being revoked:

• G2 and G3 ICA certificates being revoked and their affected end-entity certificates
• G5 cross-signed roots being revoked and their affected end-entity certificates

Does the ICA and cross-signed root certificates revocation affect me?

• ICA certificate revocations: You are only affected by these revocations if you have active certificates issued by any of the G2 and G3 ICA certificates being revoked. 
  
• Cross-signed certificate revocations: You are only affected by these revocations if you have active certificates issued from the G5 TLS and Code Signing root hierarchies and installed either of the cross-signed roots being revoked in your certificate trust chains.

Required actions

If you have,	Action required
Certificates issued by the ICA certificates being revoked	Switch to new ICA certificates and reissue or renew your certificates as needed before the deadline to avoid the following post revocation problems: Can no longer tell if the certificate's private key was compromised, or if another security issue impacts it. Certificate software may fail to validate the certificate and consider the end-entity certificate untrusted.
Certificates that include the G5 cross-signed roots in their chain of trust	Replace this cross-signing certificate in your end-entity certificate chain of trust with an updated version before the deadline to ensure the alternative trust path for your certificates continues to provide the required trust.
Learn what you need to do to prepare for these revocations: What must I do to prepare for the revocation of the G2 and G3 ICA certificates? What must I do to prepare for the revocation of the G5 cross-signed root certificates?

 

Mozilla and Google Chrome G1 Root Removal

Deadline: April 15, 2026

On April 15, 2026, Mozilla and Google Chrome removed DigiCert's G1 root certificates from their trust stores.

Background

To minimize the impact of the G1 root removal, DigiCert transitioned our default public TLS certificate issuance to our second-generation (G2) hierarches on March 8, 2023. See DigiCert root and intermediate CA certificate updates 2023.

However, some customers have devices that require updates before they can transition to the G2 root hierarchies. DigiCert may allow customers to continue issuing TLS certificates from our G1 root hierarchies on an exception basis. However, these certificates will not be trusted in Google Chrome or Mozilla Firefox starting April 15, 2026.

Does the G1 root removal affect me?

Most DigiCert customers have moved to our G2 root hierarchies, and no action is required. You are only affected if you meet these criteria:

1. You have active TLS certificates issued from a G1 root hierarchy.
2. Your certificates require trust in Google Chrome or Mozilla Firefox.

 

Required actions

If your TLS certificates expire,	Action required
After April 15, 2026	Reissue or renew your TLS certificates using the DigiCert G2 or G3 root hierarchy before the deadline to avoid "Untrusted" browser warnings.
Before April 15, 2026	No immediate action. Your next renewal will automatically move you to a supported G2 or G3 hierarchy. You can no longer renew certificates using a G1 root hierarchy.