CA Signing Other CAs: Is it Possible?

TL;DR

Generally, a Certification Authority (CA) shouldn’t directly sign another CA’s certificate. It creates trust issues and defeats the purpose of a hierarchical Public Key Infrastructure (PKI). However, there are specific scenarios like cross-certification where it’s done carefully under controlled conditions.

Understanding CAs and Trust

Before we dive in, let’s quickly recap:

• Root CA: The top of the trust chain. These are usually self-signed.
• Intermediate CA: Signed by a Root CA (or another Intermediate). They issue end-entity certificates.
• End-Entity Certificate: Issued to servers, people, or devices.

Trust is built on the chain of trust – your browser/OS verifies that an End-Entity certificate is signed by a trusted Intermediate CA, which in turn is signed by a trusted Root CA.

Why Directly Signing Another CA’s Cert is Usually Bad

1. Breaks Trust Hierarchy: If CA A signs CA B’s certificate directly, it implies CA A trusts CA B implicitly. This bypasses the need for independent vetting of CA B.
2. Circular Dependency: It can lead to a circular trust loop, making validation difficult and potentially insecure.
3. Security Risks: If CA B is compromised, CA A’s reputation is also at risk because it vouched for CA B.

When CA Signing Another CA’s Cert *Is* Done (Cross-Certification)

There are legitimate reasons to allow one CA to sign another CA’s certificate, but these are carefully managed:

1. Cross-Certification: This is a formal agreement between two CAs where they vouch for each other’s root certificates. It’s often used when CAs want to expand their trust reach across different ecosystems or geographies.
2. Bridging Trust Anchors: To connect separate PKI domains.

How Cross-Certification Works

Here’s a simplified breakdown:

1. Agreement: CA A and CA B agree to cross-certify each other’s root certificates. This involves thorough due diligence on both sides.
2. Certificate Request: CA A generates a Certificate Signing Request (CSR) for its own root certificate.
3. Signing: CA B signs CA A’s CSR with *its* root certificate, creating a cross-certificate.
4. Distribution: Both CAs distribute the cross-certificates to their respective clients and systems.

Example using OpenSSL:

# CA B signs CA A's CSR (simplified)

openssl ca -config ca_b.cnf -extensions v3_ca -days 3650 -in ca_a_csr.pem -out ca_a_cross.pem

Verifying Cross-Certificates

Clients (browsers, OS) need to be configured with both CAs’ root certificates and cross-certificates to establish trust.

• Browser Trust Stores: Browsers maintain lists of trusted Root CAs.
• Operating System Certificate Stores: Operating systems have their own certificate stores.

You can view certificates in your browser by navigating to the site’s security information (usually a padlock icon).

Important Considerations

• Due Diligence: Thoroughly vet any CA before cross-certifying.
• Revocation: Have clear procedures for revoking cross-certificates if necessary.
• Scope: Limit the scope of cross-certification to specific purposes and use cases.

In Summary

While directly signing another CA’s certificate is generally discouraged, cross-certification provides a controlled mechanism for establishing trust between CAs when done properly. Always prioritize security best practices and thorough vetting.