How does Cross Certificate work?

How cross certificates extend trust between PKI domains

A cross certificate is not a separate trust system, it is a bridge between trust systems. One CA vouches for another CA’s public key or hierarchy so relying parties in one PKI can accept certificates rooted in the other PKI, as long as path validation can build a valid chain through that bridge.

The practical effect is interoperability. A cross certificate can let two organisations, subsidiaries, government domains, or legacy and modern PKIs recognise each other without collapsing into one shared root. That makes migration and federation possible, but it also means trust is now shaped by certificate path building, policy constraints, and whether the bridge is still appropriate for current security requirements.

Because the bridge changes how chains can be formed, certificate validation becomes more than “does the leaf chain to a trusted root?”. Verifiers have to consider which intermediate CAs are acceptable, which policies are permitted, and whether the cross-certification introduces alternate paths that were not originally intended by either PKI owner.

Why path building is the hard part

Cross certification can create more than one valid route to trust, and those routes are not always equally safe. A relying party may accept a certificate through a cross-certified hierarchy even when the organisation expected validation to prefer a different root, a different policy, or a newer trust anchor. That is why cross certificates need careful path building rules and ongoing trust store review. Machine Identity, PKI and Certificate Lifecycle Guide is useful background on how certificate trust, lifecycle, and automation intersect in practice.

Cross certificates can also preserve legacy trust longer than intended. If an older authority remains reachable through a valid cross certificate, systems may continue to trust it even after the organisation has started a transition to a new CA hierarchy. That is one reason cross-certification is often treated as a governance decision, not just a technical routing detail.

When a cross certificate is used for interoperability, the security question is whether both PKI domains still deserve mutual trust at the same level. In many environments the answer changes over time, so the certificate graph should be reviewed as part of CA rollover, merger activity, or trust-anchor retirement.

Where cross certificates help, and where they create exposure

Cross certificates are most valuable when two PKI domains need controlled trust without reissuing every identity or rebuilding every dependency. They are common in federation, government interconnects, partner ecosystems, and migration between trust infrastructures. In those cases, the bridge reduces operational disruption while preserving cryptographic assurance.

The exposure comes from trust propagation. A compromise, policy mistake, or weak control in one PKI can become a trust problem in the other if path validation accepts the cross-certified route. That is why certificate authority governance, revocation handling, and trust anchor selection matter as much as the cryptography itself. The CA/Browser Forum is a useful external reference for the trust and revocation discipline expected in publicly trusted certificate ecosystems.

Operationally, the main failure modes are stale trust paths, unexpected chain preference, and incomplete revocation coverage. If the environment cannot reliably revoke or distrusting a cross certificate, then a trust bridge can outlive the business relationship or security posture that justified it.

Risk and Threat Considerations

Cross certificates expand the trust graph, which creates a real risk of unintended trust persistence. If a legacy or compromised authority remains reachable through a valid chain, relying parties may continue to accept certificates that should no longer be trusted.

Failure mechanism: Path building accepts an alternate chain through the cross certificate, bypassing the intended root, policy, or retirement state of the original authority.

Impact: Trust can extend across domains longer than intended, increasing the chance of unauthorized certificate acceptance, failed revocation expectations, or exposure after a CA compromise.

Practitioner Guidance

What to verify: Treat every cross certificate as a trust policy object, not just a cryptographic artifact. Verify which chains your clients actually build, whether revocation is enforced on every hop, and whether the accepted chain matches the business trust model rather than merely the technically valid one.

Decision rule: If the cross certificate exists only to support migration or a short-lived federation, define an explicit retirement date and remove the bridge as soon as the direct trust relationship is no longer needed. If the relationship is permanent, document the policy boundaries and monitor for chain drift over time.

Practitioner takeaway: Cross certificates are safe only when trust path, policy, and lifecycle are managed together; the technical certificate is easy to issue, but the long-term risk sits in the chains it makes possible.

Related resources from NHI Mgmt Group

• How do certificate controls and DNS controls work together in practice?
• How do certificate lifetimes, key storage, and revocation work together?
• Why do CAA records and certificate transparency need to work together?
• Why do certificate-based logins change identity governance work?