DigiCert Global Root G2: How to Verify Your Chain Migrated

Quick answer

DigiCert Global Root G2 is the RSA-2048 root that replaced Baltimore CyberTrust Root as the trust anchor for Azure, Exchange Online, and most of DigiCert's public TLS hierarchy. It is valid until January 15, 2038, and it ships in every current OS and browser trust store.

If you landed here because of a Baltimore CyberTrust Root notice: that root expired on May 12, 2025. Anything still chaining to it stopped validating fifteen months ago. Microsoft's August 27, 2026 root program release formally disables it, which is bookkeeping on a root that is already dead. The item in that same release worth your attention is GeoTrust Universal CA, which is also being disabled and does not expire until March 4, 2029.

Note the date if you read about this earlier. Microsoft originally scheduled this release for August 25 and moved it to August 27, 2026 on August 21. Older write-ups still carry the earlier date, and Microsoft's own notice still opens with the stale weekday.

To check what your endpoint actually chains to:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer

What DigiCert Global Root G2 is

The 2038 expiry is the practical point. A root issued in 2013 with a 25-year life is not something you will migrate again on any normal planning horizon, which is why vendors moved their hierarchies onto it rather than onto a shorter-lived replacement.

Why Baltimore CyberTrust Root sent you here

Baltimore CyberTrust Root was issued in 2000 and expired at 23:59:00 GMT on May 12, 2025. Its SHA-1 thumbprint is D4DE20D05E66FC53FE1A50882C78DB2852CAE474.

It was one of the most widely embedded roots ever shipped, which is why the migration off it ran for years and generated notices from Microsoft, Cisco, SAP, NetApp, and IBM. Azure services moved to DigiCert Global Root G2 ahead of the expiry. Most people reading a Baltimore notice today are reading a stale one — a KB article, a monitoring alert with a hardcoded thumbprint, or an appliance that bundles its own trust store and never got updated.

The migration is done. What remains is confirming that nothing in your estate still pins, bundles, or hardcodes the old root.

What Microsoft's August 27, 2026 release actually does

The August 2026 Trusted Root Program deployment notice uses three different mechanisms, and they are routinely read as one thing:

NotBefore sets a date after which newly issued certificates under a root fail validation. Certificates issued before that date keep working. This release sets a NotBefore of September 15, 2026 and applies it to 19 roots for all uses, plus a set of per-EKU NotBefores where the same root can be distrusted for code signing but remain fine for S/MIME.

Disable turns off the root outright. Every certificate under it fails, regardless of when it was issued. This release disables two roots:

• DigiCert \ Baltimore CyberTrust Root \ D4DE20D05E66FC53FE1A50882C78DB2852CAE474
• DigiCert \ GeoTrust Universal CA \ E621F3354379059A4B68309D8A2F74221587EC79

Remove deletes the root from the CTL entirely. This release removes Visa Information Delivery Root CA (C57A3ACBE8C06BA1988A83485BF326F2448775379849DE01CA43571AF357E74B).

Baltimore is on the disable list but expired in May 2025, so disabling it changes nothing operationally. GeoTrust Universal CA is on the same list and is valid until March 4, 2029. If anything in your estate chains to GeoTrust Universal CA, that is the one thing in this release that breaks certificates working today.

How to find out whether you still depend on either root

Four places to look, in the order that finds problems fastest.

1. What your live endpoints chain to. The server sends the leaf and its intermediates, usually not the root, so read the issuer of the topmost certificate the server actually sends:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -E '^\s*(s|i):'

The last i: line names the root your chain expects. If it says Baltimore CyberTrust Root or GeoTrust Universal CA, you have work to do. Our OpenSSL s_client guide covers reading the full handshake output, including the verify return codes.

2. The Windows machine store. Check for the thumbprint directly rather than eyeballing a list:

Get-ChildItem -Path Cert:\LocalMachine\Root |
  Where-Object { $_.Thumbprint -in @(
    'D4DE20D05E66FC53FE1A50882C78DB2852CAE474',
    'E621F3354379059A4B68309D8A2F74221587EC79'
  ) } | Format-List Subject, NotAfter, Thumbprint

3. Linux trust stores. Print a fingerprint and subject for every anchor, then filter:

for f in /etc/ssl/certs/*.pem; do
  printf '%s ' "$(openssl x509 -in "$f" -noout -fingerprint -sha1 | cut -d= -f2)"
  openssl x509 -in "$f" -noout -subject
done | grep -Ei 'baltimore|geotrust universal'

4. Java, which is where these survive longest. Java keeps its own cacerts file that OS updates do not touch:

keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit \
  | grep -Ei 'baltimore|geotrust'

On JDK 8 the path is $JAVA_HOME/jre/lib/security/cacerts. An application server can run for years on a cacerts copied from a decommissioned host, which is the single most common way an expired root is still sitting in production.

The same logic applies to any appliance with its own bundled store — load balancers, IoT gateways, MFPs, storage controllers. For F5 specifically, see F5 certificate chain configuration. For the broader model of who decides what your system trusts, the root stores and trust anchors demo walks through it interactively.

Adding DigiCert Global Root G2 where it is missing

Download the root from DigiCert and verify the fingerprint before you install anything:

openssl x509 -in DigiCertGlobalRootG2.crt.pem -noout -fingerprint -sha256

That must return CB3CCBB76031E5E0138F8DD39A23F9DE47FFC35E43C1144CEA27D46A5AB1CB5F. If it does not, stop.

Debian/Ubuntu: copy the PEM to /usr/local/share/ca-certificates/ with a .crt extension and run update-ca-certificates.

RHEL/Rocky: copy to /etc/pki/ca-trust/source/anchors/ and run update-ca-trust extract.

Java: keytool -importcert -alias digicertglobalrootg2 -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit -file DigiCertGlobalRootG2.crt.pem

Windows: import to Local Computer, then Trusted Root Certification Authorities. G2 ships in supported Windows versions already, so a missing G2 on Windows usually means a stripped or custom image rather than a gap you need to fill by hand.

If something breaks anyway

The failure signature for a missing or distrusted root is a chain-building error, not a name or expiry error. "unable to get local issuer certificate" and "self signed certificate in certificate chain" both point at the trust store rather than at the server certificate. Confirm with:

openssl s_client -connect example.com:443 -servername example.com -CApath /etc/ssl/certs </dev/null 2>&1 \
  | grep -E 'Verify return code|verify error'

A "verify return code: 0 (ok)" means the chain built. Anything else names the specific link that failed.

If you are tracking root program changes more broadly, the Chrome distrust of DigiCert legacy roots guide covers a separate set of DigiCert roots on a different browser timeline — a different event that gets confused with this one because the CA name is the same.

Frequently asked questions