Mutual TLS Certificate Chains: Best Practices

TL;DR

This guide covers how to design secure and reliable mutual TLS (mTLS) certificate chains for your applications. We’ll focus on chain structure, intermediate certificates, revocation, and practical considerations for deployment.

1. Understanding Certificate Chains

A certificate chain is a hierarchy of digital certificates used to verify the authenticity of an end-entity (server or client) certificate. It starts with your end-entity certificate, goes through one or more intermediate certificates, and ends with a trusted root certificate.

• Root Certificate: The foundation of trust. Usually self-signed and pre-installed in operating systems and browsers.
• Intermediate Certificates: Issued by the Root CA (or another Intermediate) to sign end-entity certificates. They extend the chain’s validity without exposing the Root key.
• End-Entity Certificate: The certificate used by your server or client.

The browser/client verifies the chain by checking each certificate’s signature against its issuer until it reaches a trusted root.

2. Chain Structure Best Practices

1. Keep Chains Short: Avoid unnecessary intermediate certificates. A single intermediate is often sufficient. Longer chains increase verification time and complexity.
2. Use a Dedicated Intermediate CA: Never sign end-entity certificates directly with your Root CA key. This protects the root from compromise.
3. Intermediate Certificate Validity: Set reasonable validity periods for intermediate certificates (e.g., 1-5 years). Shorter lifetimes mean more frequent rotation, but better security.
4. End-Entity Certificate Validity: Keep end-entity certificate validity short as well (e.g., 90 days to 365 days) for automated renewal and faster revocation response.

3. Intermediate Certificate Management

Properly managing intermediate certificates is crucial.

1. Secure Storage: Protect your Intermediate CA key with Hardware Security Modules (HSMs) or secure key management systems.
2. Access Control: Restrict access to the Intermediate CA key to authorized personnel only.
3. Regular Rotation: Rotate intermediate certificates periodically, even if they haven’t expired. This limits the impact of a potential compromise.

4. Certificate Revocation

When an end-entity certificate is compromised or no longer valid, it must be revoked.

• Certificate Revocation Lists (CRLs): A list of revoked certificates published by the CA. Clients need to download and check CRLs regularly.
• Online Certificate Status Protocol (OCSP): A real-time protocol for checking certificate status. More efficient than CRLs, but requires a reliable OCSP responder.
• OCSP Stapling: The server includes the OCSP response with the TLS handshake, reducing client load and improving performance. Highly recommended.

Example of configuring Nginx for OCSP stapling:

ssl_certificate /etc/nginx/certs/your_cert.pem;
ssl_certificate_key /etc/nginx/certs/your_key.pem;
ssl_trusted_certificate /etc/nginx/certs/intermediate.pem; # Important!
ocsp_enable on;
ocsp_stapling on;
ocsp_stapling_verify on;

5. Practical Considerations

1. Automated Certificate Management: Use tools like Let’s Encrypt, cert-manager (Kubernetes), or ACME clients to automate certificate issuance and renewal.
2. Monitoring: Monitor certificate expiration dates and revocation status. Alert on approaching expirations and revoked certificates.
3. Testing: Regularly test your mTLS configuration with different clients and browsers to ensure compatibility and proper chain verification.
4. Cyber security Best Practices: Ensure all systems involved in the certificate lifecycle are hardened against attacks. This includes CAs, servers, and clients.

6. Chain Building Tools

Tools like OpenSSL can help you build and inspect certificate chains.

openssl crl2pem -in your_crl.der -out your_crl.pem

This command converts a DER-encoded CRL to PEM format, which is more commonly used.