Multiple Certificate Chains & Roots

TL;DR

Yes, a certificate can have multiple chains of trust and support multiple self-signed roots. This is often used for flexibility in environments with different root authorities or when transitioning between CAs.

Understanding Certificate Chains & Roots

Before we dive into the ‘how’, let’s quickly recap what these are:

• Certificate: A digital document that proves a website/service is who it says it is.
• Chain of Trust: The path from your certificate back to a trusted root authority (CA). It consists of intermediate certificates linking your certificate to the root.
• Root Certificate: A self-signed certificate that’s pre-installed in most operating systems and browsers, forming the foundation of trust.

Why Multiple Chains?

You might need multiple chains for these reasons:

• Different Clients: Some clients (browsers, applications) may only trust specific root CAs. Providing multiple chains ensures wider compatibility.
• CA Transition: When switching Certificate Authorities, you can include both the old and new CA chains for a period to ensure smooth operation during migration.
• Internal PKI: If you have your own internal Public Key Infrastructure (PKI), you might use multiple root certificates for different departments or purposes.

Why Multiple Self-Signed Roots?

Multiple self-signed roots are less common but useful in specific scenarios:

• Testing: For development and testing, you can create multiple self-signed root certificates to simulate different environments.
• Isolated Environments: In highly secure or isolated networks, you might use a custom set of self-signed roots for internal services.

How to Implement Multiple Chains & Roots

1. Concatenate the Certificates: Combine your certificate with all intermediate certificates and root certificates into a single file (usually in PEM format). The order is crucial: Your certificate first, followed by intermediates, then roots.

cat your_certificate.pem intermediate1.pem intermediate2.pem root1.pem root2.pem > combined_certificate.pem

2. Configure Your Web Server/Application: Most web servers (Apache, Nginx) and applications allow you to specify the certificate file containing all chains.
   • Apache: In your virtual host configuration, use the SSLCertificateFile directive.

   SSLCertificateFile /path/to/combined_certificate.pem

3. Nginx: In your server block configuration, use the ssl_certificate and ssl_certificate_key directives.

   ssl_certificate /path/to/combined_certificate.pem;

4. Verify the Configuration: Use an online SSL checker tool (like SSL Labs’ SSL Server Test) to confirm that all chains are being presented correctly.
5. Client Trust Stores: Ensure clients have the necessary root certificates installed in their trust stores. For self-signed roots, this usually involves manually adding them to the client’s trusted certificate list.

Important Considerations

• Order Matters: The order of certificates in the combined file is critical. Your certificate must come first, followed by intermediates and then roots.
• Redundancy: Including redundant root certificates doesn’t usually cause problems but can increase file size.
• Security: Be cautious when using self-signed roots in production environments. They bypass the standard trust model of publicly trusted CAs.