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

You renew a certificate. It works in your browser, so you close the ticket. An hour later someone with an older laptop, or a scanner, or a Java app, reports an untrusted-certificate error on the same site. The hostname is right, the dates are fine, the server is up. Both clients are looking at the same certificate and reaching opposite conclusions.

The usual culprit is path building. A client needs a route from the server's certificate to a trust anchor it already has. Cross-signing can offer a second route, but the client still has to find it and accept it, and not every client does.

GoDaddy's move to its R1 hierarchy is a good worked example, because the certificates are public and you can check everything below yourself. We pulled the files linked here on September 30, 2026. Trust-store coverage changes over time, so treat the paths as descriptions of clients with particular trust anchors, not a promise about any given OS version.

What cross-signing is

The textbook TLS hierarchy is three certificates: the website's, the intermediate CA that issued it, and a root the client trusts.

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

The root isn't trusted because it's self-signed. Anyone can self-sign a certificate. It's trusted because the client was configured to trust it, usually through a root store shipped with the operating system, the browser, or the application, or installed by an administrator. A root certificate that arrives from a server during the handshake gains nothing by having been sent.

Cross-signing is when a second CA issues a certificate for the first CA's public key. The same key then exists in more than one certificate, each with a different issuer. In this example there's a self-signed R1 certificate, and there's another R1 certificate signed by G2. The second one is what lets the R1 hierarchy reach a client that trusts G2 but has never heard of R1.

Why new roots need this

Generating a key pair and self-signing a root takes a second. Getting the world to trust it takes years.

Root programs have to evaluate the CA before they'll admit the root. Then the root has to actually reach devices, which means OS updates, browser updates, application updates. Appliances often ship their own CA bundle and update it when the firmware does. A thin client may go years between updates. An air-gapped host may never get one.

Even two machines patched last week can have different stores. Which is why "works in Chrome on my laptop" tells you very little about what every client of an RD Gateway, an API, or a printer fleet will do.

Cross-signing bridges the gap. As long as the client still trusts the older root and accepts the rest of the path, it has a way in.

GoDaddy's R1 transition

GoDaddy has moved its DV TLS issuance to the R1 hierarchy, and its transition explanation says outright that an R1-to-G2 path is there for clients that don't yet trust R1.

The certificate repository lists GoDaddy TLS Root CA - R1 and separate DV, OV and EV issuing intermediates. The DV intermediate in this walkthrough is GoDaddy TLS Intermediate CA DV - R1v1. If you're following along with your own certificate, use whichever intermediate actually issued it; the names look similar and they are not interchangeable.

For a client that trusts R1 directly, the path is short:

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

A client that doesn't trust R1 and can't build any other path simply can't anchor this hierarchy. Every signature can be perfect and it still fails, because trust was never a question about signatures.

It helps to keep three questions apart:

And TLS adds more on top: the hostname has to match, the key usage has to fit, and revocation and other checks depend on the client's policy. A valid signature is necessary and nowhere near sufficient.

The G2 cross-sign

The repository also publishes GoDaddy TLS Root CA - R1 to G2 Cross Certificate. Its subject is R1. Its issuer is Go Daddy Root Certificate Authority - G2, with the space in "Go Daddy", because that's how the G2 root is actually named.

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 show certification relationships, not the exact certificate message a server sends. One detail worth dwelling on: in Path B the R1 certificate is an intermediate. It has "Root CA" in its name and it sits in the middle of the path. The name tells you what the key was created to be, not what role it plays for a given client.

Same key, two certificates

A CA's key and a certificate containing that key are different things. An X.509 certificate binds a subject and a public key to an issuer's signature, with validity dates and extensions wrapped around it. You can wrap the same key more than once.

The two R1 certificates look like this:

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 don't prove a shared key, so we checked. We downloaded the self-signed R1 certificate, the R1-to-G2 cross certificate, and the G2 root, and compared the DER-encoded SubjectPublicKeyInfo of the two R1 certificates. Byte for byte identical. R1's self-signature verifies with that key, the cross certificate's signature verifies with G2's key, and the cross certificate's Authority Key Identifier matches G2's Subject Key Identifier.

If you want to reproduce it, both R1 certificates give this SHA-256 digest of their DER SPKI:

80a8c921a7194ae63a6db0e7bb5dd617faee7e9b3f14ac0621aab145be672990

Their whole-certificate fingerprints, on the other hand, 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

(The line breaks are just for readability.) Two distinct certificate objects, different validity periods, different signatures, one key.

Why the website certificate doesn't change

The leaf is signed by the issuing intermediate. The intermediate is signed by the R1 key. Nothing about the leaf cares which certificate the R1 key happens to be wrapped in, so when a suitable cross certificate is available, the client has a candidate route onward to G2 with the leaf untouched.

Whether a particular client finds that route depends on things you can't see in a certificate viewer:

• Which certificates the server actually sent in the handshake.
• Which intermediates the client already has cached or installed.
• Whether the client fetches missing issuers through the Authority Information Access extension. Some do, some don't, and some can't reach the URL.
• Which anchors are in the local trust store.
• How the client's path builder orders candidates and which paths its policy accepts.

So don't assume every client sees both routes, or picks the same one. Cross-signing offers a path. It doesn't override expiry, algorithm restrictions, CA constraints, distrust decisions, or a certificate that simply isn't there.

Servers don't normally send the root

A TLS server sends its leaf and the intermediates clients will need. It generally doesn't send the self-signed root, because the client either trusts that root already or won't be persuaded by receiving it. TLS 1.3's certificate-message rules explicitly allow the trust anchor to be left out for that reason.

The R1-to-G2 certificate is a different animal from a self-signed root at the end of the chain. In the G2 path it's one of the links between the leaf and the client's anchor. A server may need to send it so that clients aren't relying on a cache or an AIA fetch.

"Root CA" in a certificate's name tells you nothing about its role in a particular path. The R1 cross certificate sits below G2, and G2 is the trust anchor in that path.

When you configure a server, use the bundle the CA provides for your certificate and follow the server's documented chain configuration. Then look at what actually goes over the wire. The chain you built on disk and the chain the server presents are two different observations, and they disagree more often than you'd think.

Fixing an incomplete GoDaddy chain

If a renewed GoDaddy certificate produces an untrusted-root or incomplete-chain error, the first thing to check is that the right bundle was installed with the leaf. GoDaddy's chain-error guidance walks through installing the bundle, reloading the server, and checking the result.

IIS has its own procedure, and it matters whether the CSR and key were generated in IIS or somewhere else, because the import and binding steps differ.

When clients disagree, put a working one and a failing one side by side. Capture the certificates each one actually received, then look at each client's trust store. A complete bundle gives the client the pieces it needs to try the alternate path. It still has to accept the anchor at the end of it.

What this means for monitoring

Saying "the chain is leaf → intermediate → root" hides a distinction that matters: what was observed versus what was constructed.

A diagnostic record that's actually useful separates:

1. Presented certificates: the list received from the endpoint.
2. Candidate issuers: certificates found locally, supplied by the server, or fetched from elsewhere.
3. Constructed path: the sequence the validator chose.
4. Trust anchor: the independently trusted end of that path.
5. Client context: the trust store, policy, clock and implementation that made the decision.

It also explains why a green monitoring probe isn't proof that every client is happy. It proves that this probe, with its trust store, built a path it liked. Troubleshooting an old appliance may mean opening up the appliance's own CA bundle.

Making this kind of thing easier to inspect is a lot of what CertIntel is for. The certificate tools will decode and chain-check any certificate material you have; any conclusion about trust still needs a clearly identified client on the other end.

Cross-signing is normal

None of this means something went wrong at GoDaddy. Cross-signing is a standard technique for introducing new roots, linking hierarchies, and keeping old clients working through a migration. It's been done by every large CA.

What it does create is operational detail worth tracking: which certificate you deployed, which issuer signed it, which constraints apply, and which anchor each client population actually accepts. A longer path isn't automatically worse and a shorter one isn't automatically more compatible.

There isn't one correct chain for a certificate. The server supplies certificates; the client builds and validates a path. GoDaddy's R1/G2 transition is just a clear, public case of a cross certificate opening a second route to trust without touching the website certificate at all.

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.