Which SSL pinning method to choose on your project?

Oleksandr Stepanov
2 min readNov 18, 2019

This is the final story in my series about SSL pinning (#1, #2) which aims to answer the question which SSL pinning method to choose.

I’m going to answer this question using the next scheme:

Simple scheme to choose SSL pinning method

Basically, the ranking of methods from the most secure to the less looks like next:

  • Certificate pinning
  • Public key pinning
  • Root/intermediate certificate pinning

I would not recommend using the last, as you are not in control of what pin against in the app, and still may brick it if the configuration changes. But this could be a suitable solution when you are not in control of the server your app is communicating with, but you can make a robust assumption about CA signing the certificates chain. This is the case, for example, when the backend is hosted on AWS and uses the Certificate Manager service. In this case, you can be sure that the root certificate will be always from Amazon, so you may pin all 4 of them in your app. Such approach has its own drawbacks, so you need to weigh them out.

So, the main factors which influence on the decision are:

  • Force app update mechanism. This is obviously required to update the pins in your app once they change. Note, even in case of the public key or the root certificate pinning this mechanism may be required if the last are compromised. So, it’s better to foresee such situation even you opt for these two options.
  • Key rotation on certificate update. In general, it’s recommended to make it and thus request the new certificate with the new CSR each time. However, if you are confident in the way you store the private key on your server, you may opt-in for the public key pinning and do not release the mandatory update on a regular basis.

Certificate pinning timeline

In case if you go with certificate pinning for your application, you will need a strict procedure of the pins update in the app synchronized with certificate renew and update on the server. I may recommend the next scheme of the timeline for this problem:

Timeline for the certificate pin renew procedure.

I used the maximum available lifetime of 2 years for EV certificate in this timeline. In case your certificate is renewed more frequently, the scheme must be adapted accordingly, but the order of events remains the same.

--

--