ETA 404
Menu

Security

Published

What a Cross-Root Certificate Actually Is: Reading DigiCert's G5 Transition

How cross-root certificates work, and how to judge an existing G1 → G5 chain as DigiCert moves issuance to its G5 root hierarchies.

Pixel art of an HTTPS window chained through certificates that branch into two root certificates, each ending in a trusted shield
Contents
  1. Background on certificate chains
  2. How this post names DigiCert’s root certificates
  3. Self-signed versus cross-signed root certificates
  4. A cross-root certificate adds another trust path
  5. Is there no impact if you keep sending G1 → G5?
  6. Checking it locally
  7. Summary

DigiCert has announced that it is consolidating public TLS issuance onto its G5 root hierarchies. According to DigiCert’s alert, from October 15, 2026, new, renewed, and reissued public TLS certificates will be issued by default from the DigiCert TLS RSA4096 Root G5 and DigiCert TLS ECC P384 Root G5 hierarchies.

The part of this news that is easy to misread is the cross-root certificate.

If you are currently serving a chain that includes the G1 → G5 cross-root certificate, how long can you keep doing that? Will existing chains suddenly break when DigiCert moves to G5? And why can a G5 cross-signed by G1 and a self-signed G5 be treated as the same G5 in the first place?

This post sorts out the terminology and then looks at what a cross-root certificate is actually doing.

Background on certificate chains

A certificate chain is the sequence of certificates that connects a server certificate to a trusted root CA (Certificate Authority).

Server certificate
  ↓
Intermediate CA certificate
  ↓
Root CA certificate

In practice a server usually sends only the server certificate and the intermediate CA certificate. The root certificate is assumed to already be in the trust store held by the client’s OS or browser. RFC 8446 - 4.4.2. Certificate also allows a certificate that acts as a trust anchor to be omitted on the assumption that the peer already has it.

a certificate that specifies a trust anchor MAY be omitted from the chain

The other thing worth keeping in mind is that verification splits into path building and path validation.

path building
  find which certificates connect, and how, to reach a trust anchor

path validation
  check the signatures, validity periods, extensions, and revocation
  status of the path that was found

For cross-root certificates, it is mainly path building that matters.

How this post names DigiCert’s root certificates

This post uses shorthand such as G1, but the formal certificate names are as follows.

RSA and ECC differ in the public-key algorithm used for signing, and DigiCert maintains separate root certificates for each. From here on, this post mainly uses the RSA side (G5 RSA) as its example.

Name used here Formal name Role Expires
G1 DigiCert Global Root CA Older-generation root. The Issuer of the G1 → G5 cross-root certificate 2031-11-10
G2 DigiCert Global Root G2 The RSA G2 root certificate 2038-01-15
G3 DigiCert Global Root G3 The ECC G3 root certificate 2038-01-15
G5 RSA DigiCert TLS RSA4096 Root G5 The new TLS-dedicated RSA root certificate 2046-01-14
G5 ECC DigiCert TLS ECC P384 Root G5 The new TLS-dedicated ECC root certificate 2046-01-14
G1 → G5 G1 Cross Signed DigiCert TLS RSA 4096 Root G5 G5 RSA signed by G1 as a cross-root certificate 2031-11-09

When this post writes G1 → G5, the arrow means “G1 cross-signs G5”.

Self-signed versus cross-signed root certificates

Conceptually, the self-signed G5 root certificate looks like this.

Subject: DigiCert TLS RSA4096 Root G5
Issuer : DigiCert TLS RSA4096 Root G5
Public Key: the G5 public key
Signature: signed with the G5 private key

The G1 → G5 root certificate looks like this.

Subject: DigiCert TLS RSA4096 Root G5
Issuer : DigiCert Global Root CA
Public Key: the G5 public key
Signature: signed with the DigiCert Global Root CA private key

For a cross-root certificate, the Issuer and the signature belong to a different root certificate. The public key, however, is the same in both the self-signed G5 and the G1 → G5.

That is the essence of a cross-root certificate. Because G1 signs G5, even a legacy client that has G1 but not G5 in its trust store can use G1 as its trust anchor and still trust a server certificate issued by an intermediate CA under G5.

A cross-root certificate adds another trust path

Seen from an intermediate CA certificate under G5, a chain can be built through either of the following Issuers.

The reason is the one described above: the G1 → G5 cross-root certificate and the G5 root certificate are different files, but the public key — and the private key used to sign the intermediate CA certificate — is the same.

Candidate A: self-signed G5 root certificate
  Subject = DigiCert TLS RSA4096 Root G5
  Issuer  = DigiCert TLS RSA4096 Root G5
  SPKI    = the G5 public key
  SKI     = identifier of the G5 public key
  AKI     = none

Candidate B: G1 → G5 root certificate
  Subject = DigiCert TLS RSA4096 Root G5
  Issuer  = DigiCert Global Root CA
  SPKI    = the G5 public key
  SKI     = identifier of the G5 public key
  AKI     = identifier of the G1 public key

SKI (Subject Key Identifier) is a value that identifies the public key held by the certificate itself. AKI (Authority Key Identifier), on the other hand, identifies the public key of the issuing CA above it. In other words, it is a hint about which key of which CA issued this certificate.

These values are used when building a chain, to look for issuer candidates for a subordinate certificate. Typically, a candidate is a certificate whose Subject matches the subordinate’s Issuer and whose SKI matches the subordinate’s AKI. That said, AKI and SKI are identifiers that help chain building. What ultimately matters during validation is that the candidate’s public key can verify the subordinate certificate’s signature.

Candidate A gives a shorter path with the G5 root certificate as the trust anchor.

Server certificate
  ↓
G5 intermediate CA certificate
  ↓
G5 root certificate

Candidate B gives a path with the G1 root certificate as the trust anchor.

Server certificate
  ↓
G5 intermediate CA certificate
  ↓
G1 → G5 cross-root certificate
  ↓
G1 root certificate

In both cases, the public key that the G5 intermediate CA certificate points to is the same.

G5 intermediate CA certificate
  Subject = DigiCert G5 TLS RSA4096 SHA384 2021 CA1
  Issuer  = DigiCert TLS RSA4096 Root G5
  SPKI    = public key of the G5 intermediate CA certificate
  SKI     = identifier of that public key
  AKI     = identifier of the G5 public key

A cross-root certificate is not a way to “use G1 instead of G5”. It is a certificate that bridges the same G5 public key to a different trust anchor, G1. Thinking of it as a compatibility bridge for older environments that do not yet have the new root in their trust store makes it easier to picture.

Is there no impact if you keep sending G1 → G5?

The G1 → G5 cross-root certificate expires on November 9, 2031, so there are still several years left.

That suggests that even after October 15, 2026, when DigiCert issues and renews certificates from the G5 RSA and G5 ECC hierarchies, a server that responds with a chain including the G1 → G5 cross-root certificate would still let a client that has G1 but not G5 in its trust store trust the server certificate it presents.

Whether a chain is actually trusted, however, is not decided by the validity period alone. At minimum, the following all matter.

1. The cross-root certificate has not expired
2. The cross-root certificate has not been revoked
3. The client has the Issuer-side root certificate as a trust anchor
4. The client can build that path
5. The browser or OS root program (the policy that decides which roots
   go into the trust store) does not reject that path
6. The application does not pin the root or intermediate CA certificate

Because some of this depends on the client implementation, the reliable approach is to build the chain and check whether the certificate is actually trusted.

Checking it locally

DigiCert provides a demo site that responds with the G1 → G5 cross-root certificate, so this uses that.

In the output below, the certificate at index 3 is the G1 → G5 cross-root certificate. You can tell because its i (Issuer) points at the G1 certificate. The G1 certificate itself appears at index 4.

openssl s_client \
  -connect digicert-rsa4096-root-g5-to-g1.chain-demos.digicert.com:443 \
  -servername digicert-rsa4096-root-g5-to-g1.chain-demos.digicert.com

Certificate chain
 0 s:jurisdictionC = US, jurisdictionST = Utah, businessCategory = Private Organization, serialNumber = 5299537-0142, C = US, ST = Utah, L = Lehi, O = "DigiCert, Inc.", CN = digicert-rsa4096-root-g5-to-g1.chain-demos.digicert.com
   i:C = US, O = "DigiCert, Inc.", CN = DigiCert G5 TLS RSA4096 SHA384 2021 CA1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jul 23 00:00:00 2026 GMT; NotAfter: Aug 21 23:59:59 2026 GMT

 1 s:C = US, O = "DigiCert, Inc.", CN = DigiCert G5 TLS RSA4096 SHA384 2021 CA1
   i:C = US, O = "DigiCert, Inc.", CN = DigiCert TLS RSA4096 Root G5
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Apr 14 00:00:00 2021 GMT; NotAfter: Apr 13 23:59:59 2031 GMT

 2 s:C = US, O = "DigiCert, Inc.", CN = DigiCert TLS RSA4096 Root G5
   i:C = US, O = "DigiCert, Inc.", CN = DigiCert TLS RSA4096 Root G5
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Jan 15 00:00:00 2021 GMT; NotAfter: Jan 14 23:59:59 2046 GMT

 3 s:C = US, O = "DigiCert, Inc.", CN = DigiCert TLS RSA4096 Root G5
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Sep 21 00:00:00 2022 GMT; NotAfter: Nov  9 23:59:59 2031 GMT

 4 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1
   v:NotBefore: Nov 10 00:00:00 2006 GMT; NotAfter: Nov 10 00:00:00 2031 GMT

Whether the self-signed G5 and the G1 → G5 cross-root certificate are different files can be checked with the following commands.

# Download the self-signed G5 root certificate
curl -fsSLo g5-self-signed.pem \
  https://cacerts.digicert.com/DigiCertTLSRSA4096RootG5.crt.pem

# Download the G1 → G5 cross-root certificate
curl -fsSLo g5-cross-signed.pem \
  https://cacerts.digicert.com/G1CrossSignedDigiCertTLSRSA4096RootG5.crt.pem

# Show details of the self-signed G5 root certificate
openssl x509 -in g5-self-signed.pem -noout \
  -subject -issuer -dates -serial -fingerprint -sha256

subject=C=US, O=DigiCert, Inc., CN=DigiCert TLS RSA4096 Root G5
issuer=C=US, O=DigiCert, Inc., CN=DigiCert TLS RSA4096 Root G5
notBefore=Jan 15 00:00:00 2021 GMT
notAfter=Jan 14 23:59:59 2046 GMT
serial=08F9B478A8FA7EDA6A333789DE7CCF8A
sha256 Fingerprint=37:1A:00:DC:05:33:B3:72:1A:7E:EB:40:E8:41:9E:70:79:9D:2B:0A:0F:2C:1D:80:69:31:65:F7:CE:C4:AD:75

openssl x509 -in g5-self-signed.pem -noout -text \
  | grep -A2 -E "Subject Key Identifier|Authority Key Identifier"

X509v3 Subject Key Identifier:
    51:33:1C:ED:36:40:AF:17:D3:25:CD:69:68:F2:AF:4E:23:3E:B3:41
X509v3 Key Usage: critical

# Show details of the G1 → G5 cross-root certificate
openssl x509 -in g5-cross-signed.pem -noout \
  -subject -issuer -dates -serial -fingerprint -sha256

subject=C=US, O=DigiCert, Inc., CN=DigiCert TLS RSA4096 Root G5
issuer=C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA
notBefore=Sep 21 00:00:00 2022 GMT
notAfter=Nov  9 23:59:59 2031 GMT
serial=05BD039060388AF417FE7D1C05BE4507
sha256 Fingerprint=A4:BC:DA:32:D4:9C:DF:05:F0:CD:D0:85:E7:3C:3A:2E:67:88:0B:D4:85:79:FE:D4:DF:59:40:DF:76:A0:76:D7

openssl x509 -in g5-cross-signed.pem -noout -text \
  | grep -A2 -E "Subject Key Identifier|Authority Key Identifier"

X509v3 Subject Key Identifier:
    51:33:1C:ED:36:40:AF:17:D3:25:CD:69:68:F2:AF:4E:23:3E:B3:41
X509v3 Authority Key Identifier:
    03:DE:50:35:56:D1:4C:BB:66:F0:A3:E2:1B:1B:C3:97:B2:3D:D1:55
X509v3 Key Usage: critical

The Issuer, validity period, and serial number differ, so these are different certificates — but the SKI matches.

Next, compare the public keys.

# Hash of the public key in the self-signed G5 root certificate
openssl x509 -in g5-self-signed.pem -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

SHA2-256(stdin)= 6a97b51c8219e93e5dec64bad5806cdeb0f8355be47e757010b702456e01aafd

# Hash of the public key in the G1 → G5 cross-root certificate
openssl x509 -in g5-cross-signed.pem -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

SHA2-256(stdin)= 6a97b51c8219e93e5dec64bad5806cdeb0f8355be47e757010b702456e01aafd

The public keys in the G5 and the G1 → G5 cross-root certificate match, confirming that they are the same key.

Summary

It is tempting to remember a cross-root certificate loosely as “an old root signing a new root”, but knowing the actual structure makes it possible to read topics like this DigiCert root reorganization accurately. My own understanding of cross-root certificates was vague, and working through it this time helped.