Key Takeaways
- Cross certificates provide continuous trust between autonomous PKI domains.
- They offer one-way or two-way trust without the consolidation of root CAs.
- Well-designed architecture – either bilateral, bridge, or mesh – and strict constraints help make the cross-certificate solution both safe and scalable.
- Analysis of cross and intermediate certificates helps determine which type is best for each particular purpose.
Introduction
Different entities use separate PKIs, and each has a different root of trust. This makes it impossible for users to validate certificates and their identities between trust domains.
To solve this problem, cross-certificates come into play, as they make connections between separate trust domains while maintaining certification paths without requiring organisations to unify their root.
What Is a Cross Certificate in PKI?
A cross certificate is a CA certificate issued by a CA to another CA from outside of the CA’s hierarchy. It is like a trust bridge that tells relying parties that certificates issued by CA B are to be trusted within the limits set out in the cross-certificate by CA A signing the public key of CA B.
Unlike end-entity certificates, cross certificates do not authenticate a user, device, or server; instead, they authenticate another CA. It should also be noted that a cross certificate is different from a subordinate CA certificate because a subordinate CA is always inferior to the issuing entity and is part of the same hierarchy and usually does not have any independent self-signed root for certificate path building.
Organisations employ cross certificates to achieve one-way or mutual trust relationships within two separate PKI domains. This leads to the establishment of trust chains that extend through corporations, government organisations, or industries as a whole, while preserving full authority over the root certificate on the part of each of the PKI domains involved.
Also Read: How to Add a Cross-Sign Certificate to the Chain on Windows Platform IIS?
Why Do We Need Cross Certificates?
Independent root CAs create trust silos. Certificates signed by one root CA would not be verified by another CA, resulting in failed secure communication as soon as two organisations start working together.
Almost any government organisation, corporation, or industry consortium will operate on a separate PKI. They need to exchange sensitive information. They have to sign agreements with each other.
Participants in supply chains need mutual device authentication. None of them is able, and not willing, to abandon their roots and join a single PKI hierarchy.
Cross certificates become vital in many practical situations involving continuous trust:
- Federated identity systems, which allow the use of common credentials to access partner portals
- Secure communication via e-mail and document signing across organisations
- IoT platforms that involve devices from different vendors
These elements will be missing, causing the breakage of the trust chain. Authentication errors will ensue for users, who may have to depend on insecure solutions or manual issuance of certificates by administrators.
Development will be delayed, risks of noncompliance will grow, and the cost of collaboration will increase. Cross certificates address all these difficulties while maintaining the total autonomy of each domain.
Also Read: Public Key Infrastructure (PKI) Use Cases for Modern Enterprise Security
How Cross Certificates Work?
Basic Steps in Creating a Trust Chain
CA A makes a cross certificate by issuing a certificate signed with the public key of CA B. The certificate created by CA A uses CA B as the subject name.
The relying party initiates with a leaf certificate from CA B and climbs up: leaf certificate → certificate of CA B itself → cross certificate from CA A → trusted root of CA A.
One-Way vs Mutual Cross-Certification
In one way cross certification, CA A certifies CA B, allowing users who trust A to validate certificates issued by B. The reverse does not work, so trust flows from A to B.
Mutual cross-certification is when CA A certifies CA B and vice versa. Now each of them can use certificates for creating paths to the other’s realm. For path validation, all that is needed is to follow the certificates in the necessary direction according to the trust anchor of the relying entity.
Path Building and Path Validation
Traditional path validation algorithms treat the cross-certificates as if they were regular CA certificates. They validate the certificate chains, check validity intervals, and implement critical extensions. The parameter pathLenConstraint defines the maximum number of CA certificates following the cross-certificate.
The extension nameConstraints limits the names that B can certify. The extension policyMappings converts policies from one realm to another, allowing relying parties to accept the chain.
PKI Cross Certification Architecture Explained
Simple Bilateral Cross-Certification
Independent CAs sign cross-certificates for each other. CA A signs the public key of CA B and vice versa. Each CA keeps its own root certificate, while end-users from both domains are able to build valid paths across the boundary. Such an approach is perfect for direct partnership.
Hierarchical Bridge CA Approach
There is a central Bridge CA that connects multiple member CAs through cross-certificates to each of them. A member CA has just one connection with the bridge rather than a separate certificate for each participating CA.
Federal Bridge CA, used in U.S. government agencies, operates based on this approach. Path validation is performed via the bridge, and the number of certificates is reduced from dozens to a few.
Mesh Configuration
Mesh is the case when each CA cross-certifies each other’s CAs. The outcome is the highest flexibility since any path can be formed without any intermediate CA. However, the number of certificates increases quadratically.
Administrators have a large operational burden starting from a few participants in the system. The mesh approach is viable for a small number of CAs only.
Anchor of Trust and Policy Considerations
The relying party remains confident in its local root as the only trust anchor. Cross certificates are used to create more pathways out of this trust anchor. Certificate policies and policyMappings become extremely important. They interpret the requirements of one domain in the language of another domain.
Cross Certificate vs Intermediate Certificate
| Aspect | Cross Certificate | Intermediate Certificate |
| Purpose | Bridge two independent PKI domains | Extend trust within a single hierarchy |
| Issuer–Subject Relationship | Different root CAs | Same root CA hierarchy |
| Trust Direction | Can be one-way or mutual | Always downward from the root |
| Path Validation Impact | Adds a horizontal link | Adds a vertical link |
| Typical Use Case | Inter-organizational trust | Organizational internal hierarchy |
| Revocation & Lifecycle | Managed by both participating CAs | Managed solely by the issuing hierarchy |
Select the cross certificate where two different organisations need to communicate with each other, but the roots should not merge. Select the intermediate certificate where an organisation needs to build or divide its trust internally. This depends on whether the relationship between these entities is peer-to-peer or hierarchical.
Real World Instances of Cross Certificates
Governments and Defence Alliances
The U.S. Federal Bridge CA connects multiple federal government PKIs and approved third parties. Agencies like the Department of Defence and the Department of State use cross-certification via the bridge so that their employees can authenticate across different departments.
Military defence alliances, including the CCEB nations, cross-certify between military PKIs of different countries so that they can operate in coalition effectively.
Commercial Bridge Systems
Commercial industry-based bridge models also exist. CertiPath runs a commercial bridge CA for defence and aerospace industry suppliers.
The organisation allows its members, which include companies like Boeing and Lockheed Martin, to cross-certify with the bridge once so that they can establish trust with all other members as well as the Federal Bridge.
SAFE-BioPharma is another example of a bridge organization that runs a bridge for healthcare and pharmaceuticals that have to exchange signed regulatory documents digitally.
Enterprise Merger and Acquisition
In mergers, the acquiring firm usually issues temporary cross certificates to the root or intermediate CA of the target company. This helps to maintain communication via email, VPN, and digital signature during integration.
Ecosystems of Public Trust Certificates
Some Commercial CAs sometimes cross-certify private enterprise roots as Non-Federal Issuers across the Federal Bridge. Such arrangements enable contractors to have their credentials used for government systems without putting all private roots in public trust stores.
Pure public-root cross-certifications happen rarely and only for the sake of compatibility and not for true inter-domain federation.
Also Read: What Is a Merkle Tree Certificate (MTC)? [Detailed Guide]
Common Mistakes in Cross Certificates and Fixes
The path validation breaks when there is no cross-certificate or it points to the wrong CA. Troubleshooting involves checking the certificate chain via a validation tool. The correct cross certificate needs to be installed in the intermediate store or directory accessible to the relying party.
Name constraints/pathLenConstraint violations lead to rejection of a valid subject or a too-long path. Name constraints and pathLen values need to be checked on the cross certificate. The cross certificate should be re-issued with broader nameConstraints or a higher pathLen value.
The relying party rejects a valid path due to policy mapping conflicts. Policy OIDs need to be compared in both certificate policies. The policyMappings extension should be updated with proper translation of the foreign policy to a local one.
Expired or revoked cross certificates will be found in cached paths. Check the notAfter value and the CRL/OCSP availability. Delete the old certificate and deploy the new one.
Incorrect trust-anchor configuration prevents the relying party from starting the path. Ensure that the only configured trust anchor is the local root and that the cross certificate properly chains to it. Remove any additional or outdated roots from the trust store.
Cross Certification Best Practices
Use restrictive nameConstraints and pathLenConstraint values in every cross certificate. This will restrict the foreign CA from certifying names or chain depth outside of the agreed business relationship.
Define explicit certificate policies for both domains and use the policyMappings extension for mapping. This will enable relying parties to enforce their own rules easily.
Ensure synchronisation of revocation information. Make sure to publish CRLs or OCSP responses that are accessible by both parties to prevent immediate usage of a revoked cross certificate.
Record the trust agreement along with policy mappings, constraints, and contacts. Assess the relationship at regular intervals, either annually or when PKI alters its hierarchy.
In case of several partners, select the Bridge CA. It reduces the network of bilateral certificates to a single relationship and makes further additions easier.
Perform complete testing of path building and validation in a replica environment before issuance of the cross certificates. Detect missing intermediaries or policy differences before it is too late.
Lastly, consider the exit strategy. Once the cooperation ends, the cross certificates should be revoked and removed from the directory. Verify that no trust paths exist.
Conclusion
Cross certificates tie disjointed trust islands together into functional chains of trust. They provide interoperability for separate entities, agencies, and industries, each of which maintains control over its own root. Where do isolated roots hinder you from exchanging identity information, documents, or device certificates? You must design an architecture, impose stringent constraints and policy mappings, and explore all paths for full lifecycle management. With this rigour, cross-certificates provide trust, not kludges.
