DigiCert G5 cross-sign on Windows Server

From 15 October 2026 DigiCert issues all new public TLS certificates from DigiCert TLS RSA4096 Root G5 and TLS ECC P384 Root G5 by default. Clients that lack G5 can only validate through the cross-signed certificate up to DigiCert Global Root G2. Windows Server sends that chain only once G5 has been taken out of service locally.

The guide covers DigiCert, GeoTrust, Thawte and RapidSSL, across IIS, Exchange, RD Gateway, AD FS, Web Application Proxy, SQL Server, NPS and LDAPS.

FairSSL stays on G2

The FairSSL CertCentral account is set to the G2 hierarchy, and we stay there for as long as DigiCert allows it. On 15 May 2026 DigiCert revoked the non-TLS intermediates under Global Root G2 and G3, so both roots are dedicated to TLS and meet the Chrome requirement. DigiCert states that customers with mission-critical dependencies on G2 and G3 should contact their account manager, and that is the route we take.

DigiCert certificates ordered from FairSSL therefore chain up to DigiCert Global Root G2 from 2013 and do not need this guide. The Chrome Root Store supports only the two G5 roots from 15 September 2027. Read on if you hold a certificate that already chains to G5.

Does your certificate chain to G5?

Open the certificate and look at the Issuer field, or run the command below. The name of the issuing intermediate settles it.

Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, Thumbprint

Issuing intermediate	Root	Action
DigiCert Global G2 TLS RSA SHA256 2020 CA1	DigiCert Global Root G2	None. The chain is short and the root dates from 2013.
RapidSSL Global TLS RSA4096 SHA256 2022 CA1	DigiCert Global Root G2	None.
DigiCert G5 TLS RSA4096 SHA384 2021 CA1	DigiCert TLS RSA4096 Root G5	Follow this guide.
DigiCert G5 TLS ECC SHA384 2021 CA1	DigiCert TLS ECC P384 Root G5	Follow this guide, the ECC variant.
GeoTrust, Thawte or RapidSSL G5 TLS RSA4096 SHA384 2022 CA1	DigiCert TLS RSA4096 Root G5	Follow this guide.

If the server sends the short chain to G5, these clients fail:

iOS before 18 and macOS before 15. G5 entered the Apple list in September 2024.
Android 13 and older. G5 reached AOSP with Android 14 in October 2023.
Java installations that never received the January 2024 update (8u401, 11.0.22, 17.0.10, 21.0.2).
Embedded equipment and machines without internet access, which cannot fetch new roots.

On Linux you simply add the cross-signed certificate to the chain file after the intermediate and reload the web server. The rest of this guide is about Windows, where Schannel builds the chain itself.

The two files you need

You need both the issuing intermediate and the cross-sign certificate. The intermediate binds your certificate to G5, and the cross-sign binds G5 to DigiCert Global Root G2. Miss either one and the chain breaks.

1. Issuing G5 intermediate

Pick the one named in your certificate Issuer field.

DigiCert RSA: DigiCert G5 TLS RSA4096 SHA384 2021 CA1
DigiCert ECC: DigiCert G5 TLS ECC SHA384 2021 CA1
GeoTrust, Thawte, RapidSSL RSA: <brand> G5 TLS RSA4096 SHA384 2022 CA1
GeoTrust, Thawte, RapidSSL ECC: <brand> G5 TLS ECC P-384 SHA384 2022 CA1

The file is in the certificate bundle you download from the FairSSL control panel, and on the DigiCert list of trusted roots and intermediates.

2. Cross-sign towards the old root

RSA: TLS RSA4096 Root G5 signed by DigiCert Global Root G2 (31 March 2026 to 30 March 2036)
DigiCertTLSRSA4096RootG5_under_DigiCertGlobalRootG2_2026.crt
ECC: TLS ECC P384 Root G5 signed by DigiCert Global Root G3 (31 March 2026 to 30 March 2036)

Both live on cacerts.digicert.com and are linked from the DigiCert root list under G5 cross-signed roots. After downloading, confirm that Subject is DigiCert TLS RSA4096 Root G5 and Issuer is DigiCert Global Root G2.

Do not use the older cross-sign under DigiCert Global Root CA from 2022. The G1 roots were removed from Mozilla and Chrome on 15 April 2026.

Procedure on Windows Server

1. Open the machine certificate store

Run certlm.msc from a command line started as administrator. Alternatively: Win+R, mmc, File → Add/Remove Snap-in, choose Certificates, Computer account, Local computer. The machine store is what matters. Certificates in the user store take no part in the chain the server sends.

2. Import the issuing intermediate

Expand Intermediate Certification Authorities and click the Certificates subfolder.
Right-click → All Tasks → Import.
Select the G5 intermediate file. Switch the file type to All Files (*.*) if it does not show.
Confirm the store is Intermediate Certification Authorities → Finish.

3. Import the cross-sign certificate

Repeat step 2 with DigiCertTLSRSA4096RootG5_under_DigiCertGlobalRootG2_2026.crt. The file belongs in Intermediate Certification Authorities, not in Trusted Root. It is technically an intermediate, because it was signed by someone else.

Then confirm that DigiCert Global Root G2 is present in Trusted Root Certification Authorities. Without the old root the server cannot build the long chain. The root ships with every maintained Windows version.

4. Quarantine the G5 root

As long as DigiCert TLS RSA4096 Root G5 is active in Trusted Root, Schannel builds the short chain and sends it. The cross-sign certificate then sits unused in the Intermediate store.

Option A: move the root into the Disallowed store

Right-click Untrusted Certificates → Certificates → All Tasks → Import and select the G5 root file. The Disallowed store is the only place automatic root update cannot put the root back.

Option B: disable all purposes

This is the method in the DigiCert article on disabling a root certificate on Windows (KB article TL143). DigiCert stresses that the root must be disabled rather than deleted, and that a restart may be required.

Go to Trusted Root Certification Authorities → Certificates and find DigiCert TLS RSA4096 Root G5.
Double-click and confirm on the Details tab that Subject and Issuer match. That identifies the root rather than the cross-sign.
Right-click → Properties → General tab → Disable all purposes for this certificate → OK. Some sources say clearing Server Authentication alone under Enable only the following purposes is enough. We have not confirmed that.

Never delete the root. Microsoft writes in KB 2831004: "if the Turn off Automatic Root Certificates Update Group Policy setting is disabled or not configured on the server, the certificate ... you don't want to use may be enabled or installed when the next chain building occurs." A deleted root is fetched again from Windows Update at the next chain build. The difference between the two options is durability: automatic root update cannot touch the Disallowed store, while the purpose flags in Trusted Root can be set back. Both apply only to the server you change, and on that server they affect everything that would otherwise validate up to that root. A certificate with another way up, through the cross certificate to the older root for instance, still validates.

5. Re-export the PFX with its chain and rebind

Some services hold on to the chain that was in the PFX the certificate was imported from. Export the certificate again with the full chain and bind it to the service anew.

$pw = Read-Host -AsSecureString "PFX password"
Export-PfxCertificate -Cert Cert:\LocalMachine\My\<THUMBPRINT> `
  -FilePath C:\temp\server-with-chain.pfx -Password $pw -ChainOption BuildChain

-ChainOption BuildChain builds the chain from the machine stores, that is, after the root has been quarantined. Import the PFX again and bind it to the service that uses the certificate.

6. Restart

Chain data is cached in the process that built the chain, and in lsass and HTTP.SYS. A full Windows restart is the only way to clear all of it. Restarting the individual role does not reach the Schannel chain cache, so the service can answer with the old chain afterwards and look as though the change did not work. Plan a restart window.

The change applies to the whole machine. If the server runs both IIS and SQL Server, you change the chain for both. Run the verification against each service and port, not only against port 443.

Verification

certutil -verify, certutil -verifystore and Test-Certificate show the server own view of the chain. They say nothing about what HTTP.SYS or Schannel actually sends. Verify from the outside.

openssl s_client -connect your-domain.com:443 -servername your-domain.com -showcerts </dev/null \
  | grep -E "^ *[0-9] s:|^ *i:"

You should see three certificates: your server certificate, the G5 intermediate and DigiCert TLS RSA4096 Root G5. The i: line of the last certificate must read DigiCert Global Root G2. If the last link shows G5 in both subject and issuer, the server is still sending the short chain.

The FairSSL SSL Scanner shows the full delivered chain and the root it points at.
Internal servers with no access from the internet: run testssl.sh from another machine on the network.

SSL Labs alone is not enough. SSL Labs trusts G5 itself and awards an A on the short chain while an Android 13 phone fails. Read the chain list in the report rather than the grade.

Back to the default

Remove the G5 root from Untrusted Certificates, or set it back to Enable all purposes in Trusted Root, and reboot the server. The cross-sign certificate can stay in the Intermediate store, because Schannel picks the short chain again as soon as the root is active.

Frequently asked questions about DigiCert G5

Find answers to the most common questions about SSL certificates and FairSSL.

Does this apply to my DigiCert, Thawte, RapidSSL or GeoTrust certificates from FairSSL?

Not at the moment. The FairSSL CertCentral account is set to the G2 hierarchy, and we stay there for as long as DigiCert allows it. Certificates ordered from us chain up to DigiCert Global Root G2 from 2013, which is present in every relevant trust store. This guide is relevant if you have a certificate from another source, or if your certificate is issued from G5 for some other reason.

How do I tell whether my certificate chains to G5?

Open the certificate and look at the Issuer field. If the issuing intermediate has G5 in its name, for example DigiCert G5 TLS RSA4096 SHA384 2021 CA1 or Thawte G5 TLS RSA4096 SHA384 2022 CA1, it comes from the G5 hierarchy. If it says G2, for example DigiCert Global G2 TLS RSA SHA256 2020 CA1 or RapidSSL Global TLS RSA4096 SHA256 2022 CA1, it chains up to DigiCert Global Root G2.

What happens on 15 October 2026?

From that date DigiCert issues all new, reissued and duplicate public TLS certificates from DigiCert TLS RSA4096 Root G5 and TLS ECC P384 Root G5 by default. It covers DigiCert, GeoTrust, Thawte, RapidSSL and Encryption Everywhere across DV, OV and EV. Existing certificates need no reissue and continue unchanged until they expire.

Should I use the cross-sign towards G1 or towards G2?

Towards G2. DigiCert also has an older cross-sign of G5 under DigiCert Global Root CA (G1) from 2022, but Mozilla and Chrome removed the G1 roots on 15 April 2026. Use the cross-sign from 31 March 2026, signed by DigiCert Global Root G2 and valid until 30 March 2036.

Can I just delete the G5 root from Trusted Root?

No. Windows fetches root certificates from Windows Update during chain building, and a deleted root is reinstalled. DigiCert recommends disabling the root rather than deleting it in their own article on the subject. Importing it into Untrusted Certificates is more robust still.

How long can I stay on G2?

The Chrome Root Store supports only the two G5 roots from 15 September 2027, as a consequence of the Chrome limit of two self-signed roots per CA owner. Until then, DigiCert certificates ordered from FairSSL chain up to G2. We follow the DigiCert announcements and will tell you in good time if that changes.

Not sure which root your certificate points at?

Create a free account and order your first certificate. A DV certificate is issued in under 2 minutes.

Create free account Compare certificates