On May 15, 2026, DigiCert will revoke certain key certificates. Your users will leave, and browsers will mark your website as “Not Secure” if it is in one of the affected chains.

The majority of organisations are unaware of their impact. That’s the problem.

Here’s what it is really saying. Google Chrome updated the rules. It now necessitates the use of separate and dedicated systems for TLS, code signing and S/MIME by certificate authorities, such as DigiCert.

DigiCert is complying, which will result in the indefinite retirement of a number of G2 and G3 intermediate certificate authorities and cross-signed root certificates on May 15. Any website, API, Java application, or enterprise system that relies on these old chains will lose its trust upon the revocation.

Why DigiCert Is Making This Change

The root cause comes from new requirements introduced by Google Chrome’s Root Program.

Google now requires Certificate Authorities (CAs) to use dedicated TLS root hierarchies specifically for issuing public TLS certificates. In simple terms, certificate authorities can no longer use the same root hierarchy for multiple purposes like TLS, code signing, and S/MIME.

To comply with these requirements, DigiCert is transitioning its older G2 and G3 infrastructure into newer single-purpose hierarchies.

As part of that migration, DigiCert announced it will revoke:

• Certain G2 and G3 Intermediate CA certificates
• Some G5 cross-signed root certificates
• Legacy certificate trust chains that no longer meet Chrome requirements

The revocation date is fixed, i.e., May 15, 2026. After that date, affected certificate chains may no longer be trusted.

What Exactly Is Being Revoked on May 15?

DigiCert is taking back some certificates under the G2 and G3 roots. This is the part where people usually stop paying attention. You should not do that because the details are important to know.

Under the DigiCert Global Root G2:

• DigiCert Global CA G2 is used for TLS certificates. It is being taken back because it does not have the information that Google Chrome now needs.
• DigiCert G2 SMIME RSA4096 SHA384 2024 CA1 is used for Public S/MIME certificates.

Under the DigiCert Global Root G3:

• Some code signing certificates are being taken back, including DigiCert Global G3 Code Signing ECC SHA384 2021 CA1, DigiCert Global G3 Code Signing ECC P256 SHA384 2021 CA1, DigiCert Assured ID G3 CS ECC384 SHA384 2025 CA1 and DigiCert Global G3 Code Signing Europe ECC P-384 SHA384 2023 CA1.

Here is the important part that people often miss:

DigiCert is not taking back the end-entity certificates. Your actual TLS certificate, S/MIME certificate, or code signing certificate is still good. That does not really matter. If the certificate in your trust chain is taken back, your end-entity certificate becomes untrusted and invalid to browsers and operating systems. Google Chrome will give a “Not warning“. Your customers will see a red screen, and they will leave.

DigiCert is also taking back two cross-signed root certificates:

• G3 Cross-Signed DigiCert TLS ECC P384 Root G5 for TLS
• G3 Cross Signed DigiCert CS ECC P384 Root G5, for code signing

This matters because the G5 roots are new and not all devices have them. The cross-signed certificates were a plan. Once they are taken back, that backup plan is gone.

Why This Matters More Than People Think

Most organisations assume: “My certificate hasn’t expired yet, so I’m safe.” That assumption is wrong.

A TLS certificate can still become untrusted even before expiration if the intermediate certificate authority (ICA) in its trust chain gets revoked.

That means:

• Websites may trigger browser trust warnings
• APIs may reject TLS connections
• Mobile applications could fail secure communication
• Internal enterprise systems may break unexpectedly
• Signed software may fail integrity validation

And in some cases, users may be completely blocked from accessing services.

This isn’t just theoretical. DigiCert explicitly warned that browsers may show “invalid certificate” or “not trusted” errors once the ICA revocation occurs.

The Biggest Risk Areas

Not every organisation will face the level of risk.. Some environments are more at risk.

Public Websites Using Older DigiCert Chains

Organisations still using the DigiCert Global CA G2 chain for TLS certificates need to take immediate action.

DigiCert says this ICA must be revoked because it does not have the Google Chrome-required Server Authentication EKU. The replacement certificate authority is DigiCert Global G2 TLS RSA SHA256 2020 CA1

Companies must reissue and reinstall affected TLS certificates before the deadline (15 May 2026). If they do not, they may face browser trust failures.

Java Code Signing Environments

This could be one of the dangerous parts of the transition.

DigiCert warns that Java handles certificate revocation differently from other platforms. Java checks if a certificate is valid based on its status, not the date it was originally signed.

That creates a problem.

When the affected code-signing ICA certificates are revoked:

• Existing Java signatures may become invalid over time
• Applications may fail integrity verification
• Deployment pipelines could break
• Enterprise software distribution may stop working properly

Even software that was signed before may need to be signed again. For organisations that rely heavily on Java, this is not a task. It could become a project.

Older Operating Systems and Legacy Devices

DigiCert also announced the revocation of some cross-signed roots. This is a problem because many older systems do not trust G5 roots.

Examples include:

• Legacy Windows environments
• Older Android devices
• Embedded IoT systems
• Industrial infrastructure
• Offline enterprise appliances

To stay compatible, many organisations used signed trust paths.

DigiCert, TLS certificates, and Java Code Signing Environments are areas where organisations face risk.

Organisations using DigiCert Global CA G2 chain and Java Code Signing need to take action, and their systems also need to take action to maintain compatibility.

To maintain compatibility, many organisations relied on cross-signed trust paths.

Your Action Plan: What You Must Do Before May 15

Let us get down to business. Here is your straightforward action checklist.

If You Have TLS Certificates Under DigiCert Global CA G2:

• Stop giving out certificates from DigiCert Global CA G2 right away.
• Switch to the ICA: DigiCert Global G2 TLS RSA SHA256 2020 CA1.
• Give out TLS certificates using the new ICA and put them on your servers.

If You Have S/MIME Certificates Under DigiCert G2 SMIME RSA4096 SHA384 2024 CA1:

• Start giving out certificates from DigiCert Assured ID SMIME RSA2048 SHA256 2021 CA1.
• Give out S/MIME certificates and use them across your organisation.

If You Have Code Signing Certificates Under the G3 ICAs:

• Put a timestamp on all your signatures now. Signatures with a timestamp are still good after the ICA is revoked. This is your plan, so use it.
• Sign files again that do not have a timestamp before May 15.
• Sign all Java files away. Do not wait.
• Switch to the ICA: DigiCert Assured ID G3 EUR CS ECC384 SHA384 2025 CA1.
• Give out code signing certificates and sign your code again.

If You Use G5 Cross-Signed Root Certificates in Your Trust Chain:

You do not need to give out new certificates here. That is news.

You need to:

• Get the replacement cross-signed root certificate from DigiCerts G5 cross-signed root certificates page.
• Open your Intermediate CA file in a text editor.
• Remove the cross-signed root from the end of the file.
• Put in the cross-signed root content.
• Save the updated file.

For TLS certificates: Replace with DigiCert Global G3 -signed DigiCert TLS ECC P384 Root G5.

For Code Signing certificates: Replace with DigiCert Assured ID G3 cross-signed DigiCert CS ECC P384 Root G5.

Also Read: Sectigo New Public Roots and Issuing CAs Hierarchy 2025

Conclusion

DigiCert’s 2026 certificate revocation is a major change that could impact websites, applications, code signing, and enterprise systems worldwide. Organisations that fail to prepare early may face trust warnings, broken certificate chains, and unexpected outages.

Our team can help you identify affected certificates, migrate to secure trust chains, and prevent downtime before it’s too late.

Secure your infrastructure before the May 15, 2026, deadline and stay updated with industry compliance by subscribing to our blog.