Certficate pinning: should I pin the leaf or intermediate?

Question

I'm following this article : Android Security: SSL Pinning to implement certificate pinning in Android using OkHttp.

As our app clients do not update their app regulary I don't want to take the risk by using our server certification (Leaf certification) which will expire in about a month.

** Warning: Certificate Pinning is Dangerous!**

limits your server team’s abilities to update their TLS certificates. By pinning certificates, you take on additional operational complexity and limit your ability to migrate between certificate authorities. Do not use certificate pinning without the blessing of your server’s TLS administrator!Pinning certificates

In the above article, the author did use two approaches. In the first one he used the leaf and intermediate certification, but in the second one he only used the leaf certification.

Is it possible to use the leaf and the intermediate and when the leaf gets updated my app will still work?

Is it OK to only use intermediate pinning?

Answer 1

You can pin leaf, intermediate CA, or root CA. All will work, but each comes with a usability / security tradeoff depending on the details of your setup.

The article you link actually gives a fairly good run-down of the differences:

Leaf certificate. By pinning against your leaf certificate you are guaranteeing with close to 100% certainty that this is your certificate and thus the chain is valid. Leaf certificates tend to have a short expiry time and if, for instance, the SSL certificates are re-issued because the private key is compromised your app will be bricked until you can push an update out. Of course the same may also be true if you frequently cycle your certificates.

Intermediate certificate. By pinning against the intermediate certificate you are trusting that intermediate certificate authority to not mis-issue a certificate for your server(s). This also has the advantage that as long as you stick to the same certificate provider then any changes to your leaf certificates will work without having to update your app.

Root certificate. By pinning against the root certificate you are trusting the root certificate authority as well as any intermediaries they trust not to mis-issue certificates. Often the root and intermediate authorities are the same company in which case there’s not much difference in the number of people you are trusting, however that’s not always the case.

In addition to what the article mentions, I'll say that then you pin a cert, you are removing the CA's ability to revoke that cert because your app trusts that cert implicely and will never go looking for status info for it. By that logic, pinning a CA (intermediate or root) has the advantage that when your leaf cert expires, gets hacked because you accidentally publish the private key on github, or whatever, you can easily ask the CA to revoke it and issue you a new one. Your app will keep working.

Personally, I would avoid pinning a leaf because you're essentially removing the parts that make a cert a cert: revocation and chaining to a trust root. You might as well do openssl genrsa and pin the public key in your app because you're not really getting any benefit from it being a cert.

That said, when you pin a CA, your app will trust any certificate issued by that CA, possibly to other people. You may be ok with that, maybe because it's your private corporate CA, or you may need to implement extra certificate validation logic to ensure that the cert chains to a pinned CA and the name matches what your app expects (and convince yourself that the CA would never in good faith issue a cert with that name to anyone who isn't you).

---

Summary: Pinning the leaf, intermediate CA, or root CA are all acceptable practice with some slight pros and cons. Do whatever makes sense for your app.

Answer 2

You should not pin the intermediate or leaf certificate in 99.9% of use cases.

Your leaf certificate may be revoked for a multitude of reasons. You might find that you need to revoke the certificate yourself, or that the CA has revoked your certificate due to them finding an operational error. Pinning the leaf certificate has a potential to lock you out of your application until you can get the application updated.

There are no guarantees that the intermediate certificate will stay valid and can change without any notice at any given time. This would completely lock you out of your own application until you can get the application updated.

Your safest bet would be to use a trusted root store maintained by Mozilla, Apple, Microsoft etc. Or to delegate that trust to the platform your software will run on (e.g. the operating system).

If you definitely want to use certificate pinning, then you should avoid pinning intermediates or leafs, and pin the root certificate.

Pinning the root isn't without it's own risks either, but it's far less likely for root pinning to cause you problems. As a side-note, you should understand exactly what threats you're planning to prevent by pinning. Understand where exactly pinning falls within your threat modeling and plan accordingly. A lot of the time you'll find out you don't actually need to pin certificates.

You can read more about what digicert thinks about certificate pinning.

Answer 3

This is little more than a comment on the other two answers, but I'd like to emphasize that pinning root certificates is also tricky and dangerous, if less dangerous than pinning intermediate certificates.

As mentioned, CAs are likely to switch intermediate certificates unpredictably and without notice, as they expire, or for other operational reasons.

Less often but for the same reasons, CAs will also switch which roots they use for new certificates or in the default chains provided for download. They are likely to give advance notice, but even if they do you probably have to regularly check their news and support websites to find it.

Older CAs have accumulated eclectic tangles of root certificates that were obtained through mergers and acquisitions, or issued to upgrade to more modern cryptography, to replace older certificates that will expire, to use for different categories of certificates (EV, S/MIME, government, etc.), or for other reasons.

Newer CAs are likely to have a few roots generated on their own, cross-signatures from one of the aforementioned older CAs, or maybe an entire root acquired from an older CA.

It can be difficult to make sense of which roots are relevant to you, which TLS clients and versions your clients use, and how their path building, pinning and validation algorithms work.

Your CA may have detailed documentation about how their graph of trust anchors fits together. They may provide advice about pinning. They may provide promises. They may not be able to keep them. They may work with you if you get backed into a corner by your choices or theirs.

As an example, Amazon lists 5 root certificates (1 acquired from another company). There are cross-signatures. Building a graph would probably find about 10 roots involved total. A misguided AWS certificate customer could probably pin 1 of about 5 different certificates and have something that would work today and explode later. I have not checked their documentation. (Also, some of Amazon's own services use other CAs.)

As further context, Ryan Sleevi wrote two posts about the complexities of path building.