Understanding Certificate Cross-Signing: The GoDaddy R1 and G2 Example

A renewed TLS certificate works on one client and fails on another. The hostname is correct, the certificate has not expired, and the server is reachable. How can both clients be looking at the same certificate and disagreeing about trust?

One explanation is certificate path construction. A client needs a route from the server's certificate to a trust anchor it accepts. Cross-signing can provide an additional route, but the client still has to find and accept it.

GoDaddy's R1 transition is a useful example. We checked the certificate artifacts linked below on September 30, 2026. Trust-store distribution continues to change, so the paths here describe clients with particular trust anchors, not a promise about every operating system version.

What is certificate cross-signing?

A typical TLS hierarchy has a leaf certificate for the website, an issuing intermediate certificate authority, and a root trusted by the client.

1. Website certificate
2. Issuing intermediate CA
3. Root CA trusted by the client

The root's self-signature is not what makes it trusted. Trust comes from the client's configuration, usually a root store maintained by its operating system, browser, application, or administrator. A root certificate received from a server does not acquire that status merely by being sent.

Cross-signing is when another CA issues a certificate for a CA's public key. That key can then be represented by multiple certificates with different issuers. In the example here, one R1 certificate is self-signed; another is signed by G2. The second can connect the R1 hierarchy to a client that already trusts G2.

New roots take time to become trusted

Creating a key pair and a self-signed certificate is straightforward. Distributing trust is a different process.

Root programs evaluate a CA before admitting its root. Distribution then depends on updates to operating systems, browsers, and applications. An appliance may ship its own CA bundle. A thin client may receive infrequent firmware updates. A disconnected host may never receive automatic root updates.

Even two recently updated machines can use different stores. A successful test in one browser therefore does not establish that every client of an RD Gateway, API, or appliance will accept the same path.

Cross-signing can bridge that distribution gap when the older trust anchor and the rest of the path remain acceptable to the client.

GoDaddy's R1 transition

GoDaddy documents moving DV TLS issuance to its R1 hierarchy. Its official transition explanation explicitly describes using an R1-to-G2 path while R1 trust is distributed.

The official certificate repository lists GoDaddy TLS Root CA - R1 and separate DV, OV, and EV issuing intermediates. The concrete DV intermediate used in this explanation is GoDaddy TLS Intermediate CA DV - R1v1. Choose the intermediate that actually issued your certificate; the labels are not interchangeable.

For a client whose trust configuration directly accepts R1, the conceptual path is:

1. example.com leaf certificate
2. GoDaddy TLS Intermediate CA DV - R1v1
3. GoDaddy TLS Root CA - R1 — local trust anchor

If the client does not trust R1 and cannot construct another acceptable path, it cannot anchor this hierarchy. Correct signatures do not resolve that missing trust decision.

It helps to separate three questions:

TLS acceptance also requires the server identity and intended usage to match, with revocation and other checks depending on client policy. A valid signature alone is insufficient.

Enter the G2 cross-sign

The repository also publishes GoDaddy TLS Root CA - R1 to G2 Cross Certificate. Its subject common name is R1, but its issuer common name is Go Daddy Root Certificate Authority - G2. Notice the space in “Go Daddy” in the G2 name; this is the name in the actual certificate.

1. The same example.com leaf certificate
2. GoDaddy TLS Intermediate CA DV - R1v1
3. GoDaddy TLS Root CA - R1 — certificate issued by G2
4. Go Daddy Root Certificate Authority - G2 — local trust anchor

These diagrams describe certification relationships. They do not prescribe an identical TLS certificate message for every client. In Path B, the R1 certificate is an intermediate in the validation path even though its subject contains “Root CA.”

Same CA key, different certificates

A CA's key is not the same thing as a certificate containing that key. An X.509 certificate binds information about a subject and public key to an issuer's signature, along with validity periods and extensions.

The two R1 artifacts have these common names:

Certificate A: self-signed R1
Subject CN: GoDaddy TLS Root CA - R1
Issuer CN:  GoDaddy TLS Root CA - R1
Public key: R1 key

Certificate B: R1 cross-signed by G2
Subject CN: GoDaddy TLS Root CA - R1
Issuer CN:  Go Daddy Root Certificate Authority - G2
Public key: R1 key

Matching names alone would not prove a shared key or a valid signature. We downloaded the self-signed R1 certificate, the R1-to-G2 cross certificate, and the G2 root.

Comparing their DER-encoded SubjectPublicKeyInfo (SPKI) confirmed identical public-key material in the two R1 certificates. R1's self-signature verified with that key; the cross certificate's signature verified with G2's key. The cross certificate's Authority Key Identifier also matched G2's Subject Key Identifier.

For reproducibility, both R1 artifacts produced this SHA-256 digest of their DER SPKI:

80a8c921a7194ae63a6db0e7bb5dd617faee7e9b3f14ac0621aab145be672990

Their whole-certificate SHA-256 fingerprints are different:

Self-signed R1:
25:CF:3D:A8:E9:B9:7A:DD:BF:92:54:3C:2B:82:52:7C:
8A:4E:2C:FF:20:62:A6:48:30:40:D4:B6:4A:CE:71:9F

R1 signed by G2:
7B:CB:0F:2F:2D:10:31:A6:AF:8D:61:BA:A8:35:D2:83:
5A:3B:8B:CC:26:D9:4A:3B:04:8B:16:55:FB:81:29:8C

Line breaks above are only for readability. These are distinct certificate objects, not two copies of the exact same certificate. They also have different validity periods and signatures.

Why the leaf can stay the same

The website certificate is signed by the issuing intermediate. That intermediate's certificate is signed by R1. When the same R1 public key is available in a suitable cross certificate, the client has a candidate route onward to G2 without changing the leaf.

Whether that route is available depends on more than what an administrator sees in a certificate viewer:

• The server supplies a particular set of certificates during the TLS handshake.
• The client may already have relevant intermediates cached or installed.
• Some implementations fetch missing issuers through Authority Information Access (AIA); others do not, or cannot reach the URL.
• The local trust store determines which anchors are accepted.
• The path builder and validation policy determine which candidates are tried and which paths pass.

Do not assume that every client discovers both routes or chooses the same one. Cross-signing provides a possible path; it does not override expiration, algorithm restrictions, CA constraints, distrust decisions, or missing certificates.

Servers normally do not send the root

A TLS server normally sends its leaf followed by the intermediate certificates needed by clients. A self-signed trust anchor generally need not be sent because trust must already be established independently. TLS 1.3's certificate-message rules allow the trust-anchor certificate to be omitted for that reason.

The R1-to-G2 certificate is different from a self-signed root at the end of a chain. In the G2 path, it is one of the certificates connecting the leaf to the client's anchor. A server may need to supply it so a client does not depend on a cache or issuer download.

“Root CA” in a certificate's name does not tell you its role in a particular path. The R1 cross certificate functions below G2, which is the trust anchor in that path.

When configuring a server, use the CA's appropriate bundle and the server's documented chain configuration. Inspect the certificates actually delivered over the network. A locally constructed chain and a server-presented chain are different observations.

Troubleshooting an incomplete GoDaddy chain

If a renewed GoDaddy certificate produces an untrusted-root or incomplete-chain error, check that the appropriate certificate bundle was installed with the leaf. GoDaddy's general chain-error guidance explains bundle installation, reloading the server, and checking the resulting path.

For IIS, follow GoDaddy's separate Windows IIS certificate-error procedure. It distinguishes certificates whose CSR and private key were generated in IIS from those generated externally, and describes the corresponding import and binding steps.

When clients disagree, compare a working client with a failing client, capture the certificates actually served, and inspect each client's trust configuration. A complete bundle supplies the certificates needed to attempt the alternate path; the client still needs to accept its trust anchor and validation constraints.

What this means for monitoring

Saying “the chain is leaf → intermediate → root” can hide the distinction between what was observed and what was constructed.

A useful diagnostic record separates:

1. Presented certificates: the certificate list received from the endpoint.
2. Candidate issuers: certificates found locally, supplied by the server, or retrieved from another source.
3. Constructed path: the particular sequence chosen for validation.
4. Trust anchor: the independently trusted endpoint of that path.
5. Client context: the trust store, policy, time, and implementation used for the decision.

This also explains why a successful monitoring probe is not proof of universal client compatibility. It demonstrates a result from that probe's perspective. Troubleshooting an older appliance may require examining the appliance's own CA bundle.

Making certificate observations and PKI details easier to inspect is part of CertIntel's purpose. The certificate tools can help inspect certificate material; conclusions about trust still need a clearly identified client context.

An established PKI technique

Cross-signing is a normal technique for introducing roots, connecting CA hierarchies, and maintaining compatibility during migrations. It is not inherently evidence of a misconfigured CA.

It does create operational details worth tracking: which certificate was deployed, which issuer signed it, what constraints apply, and which anchor a client actually accepts. A longer path is not automatically worse, and a shorter path is not automatically more compatible.

A certificate does not necessarily have one universally correct chain. The server supplies certificates; the client constructs and validates a path. GoDaddy's R1/G2 transition illustrates how a cross certificate can offer another route to an accepted trust anchor without replacing the website certificate.

Further reading

• GoDaddy certificate repository: authoritative artifact names, certificates, and bundles.
• GoDaddy's R1 hierarchy transition: the CA's explanation of its transition and cross-signed path.
• GoDaddy's chain-error guidance.
• GoDaddy's Windows IIS certificate-error procedure.
• RFC 5280, section 6: certification path validation and trust-anchor inputs.