Certificate Pinning: Backup Strategy

TL;DR

Pinning to a leaf certificate with an intermediate as a backup provides strong security against man-in-the-middle attacks, but allows for easier certificate rotation than pinning only to the root. It’s more flexible and practical for most applications.

Understanding Certificate Pinning

Certificate pinning is a technique where your application explicitly trusts specific certificates (or their public keys) instead of relying on the system’s trust store. This prevents attackers from intercepting traffic using fraudulently issued certificates, even if those certificates are signed by trusted Certificate Authorities (CAs).

Why Pinning to Leaf with Intermediate Backup?

There are three main approaches to certificate pinning:

• Pinning to Root CA: Most secure but least flexible. Requires updating your app whenever the root certificate changes (rare, but possible).
• Pinning to Leaf Certificate Only: Very secure initially, but requires immediate app updates when the leaf certificate expires or is revoked. This can be disruptive.
• Pinning to Leaf with Intermediate as Backup: Best balance of security and flexibility. Allows for easier certificate rotation without requiring a full app update in many cases.

Pinning to the leaf provides strong initial protection, while pinning the intermediate allows you to rotate your leaf certificates more easily.

Step-by-Step Implementation

1. Obtain Certificates: You’ll need your leaf certificate and the intermediate certificate that signed it. These are usually provided by your Certificate Authority (CA).
2. Convert to Suitable Format: Pinning typically requires certificates in formats like DER-encoded binary or PEM format. Use OpenSSL if needed:

   openssl x509 -in leaf_certificate.pem -out leaf_certificate.der -outform DER

3. Implement Pinning Logic: The implementation varies depending on your platform and programming language. Here’s a conceptual example (using pseudo-code):

   function verifyCertificate(certificateChain) {
     // Check if the leaf certificate is pinned.
     if (isPinnedLeaf(certificateChain[0])) {
       return true;
     }
   
     // If not, check if the intermediate certificate is pinned.
     if (isPinnedIntermediate(certificateChain[1])) {
       return true;
     }
   
     return false; // Certificate is not trusted.
   }

4. Configure Your Application: Integrate the verifyCertificate function into your application’s network connection handling. This usually involves modifying TLS/SSL settings.
5. Test Thoroughly: Test with valid certificates, expired certificates, and fraudulent certificates to ensure pinning is working as expected.
   • Use tools like OpenSSL s_client to simulate different certificate scenarios.
   • Consider using a proxy tool (e.g., mitmproxy) to intercept traffic and verify the pinning process.
6. Certificate Rotation: When your leaf certificate expires, you can replace it without immediately updating your app if the intermediate certificate remains valid.
   • Update the pinned leaf certificate in your application configuration (or distribution mechanism).
   • Deploy the updated configuration to your users.

Considerations

• Certificate Revocation: Implement a robust certificate revocation checking mechanism, such as Online Certificate Status Protocol (OCSP) stapling or Certificate Transparency (CT). Pinning doesn’t protect against revoked certificates unless you actively check their status.
• Backup Strategy: Ensure your backup intermediate certificate is also regularly updated and monitored.
• Platform Support: Check the pinning capabilities of your target platforms and libraries. Some platforms may have built-in pinning support, while others require custom implementation.
• Security Libraries: Use well-vetted security libraries to handle certificate parsing and validation. Avoid implementing this logic yourself unless you are a cryptography expert.