How to use SSL from Let's Encrypt for ssl pinning in mobile app?

Hi, I'm using let's encrypt SSL to enable https for my API services which are consumed by my mobile app. When I configured ssl pinning from my app I figured out that when it expires, certbot automatically renews the certificates, causing the handshake connection error from the app (because the certificate saved locally in app already expired). To fix this, I was trying to find a way to get the next certificate to be generated before the automated renewing task were executing so I could add this "next" certificate in my app.

But I couldn't find a way, Is there a way? Or is there a better way to handle this case for ssl pinning?

Thanks in advance

1 Like

You could renew the cert without reloading the API webserver. The renewed cert is only loaded after a reload, so between renewing and reloading you could do your App magic.

By the way, can you only pin a complete cert? Or perhaps also the public key? Because the latter would be ideal, as it's not required to change the key of the renewed cert.


Welcome to the Let's Encrypt Community, Anthony :slightly_smiling_face:

You could just turn off autorenewal and run the renewal command yourself at the appropriate time. This would require pushing the new certificate to your clients accordingly (via app update if necessary).

1 Like

Just a thought...

HTTP Public Key Pinning : A security mechanism that asks a browser to require that a site’s certificate chain use certain public keys on future loads. Chrome introduced this mechanism to protect against CA compromises, but it caused site outages, leading Chrome to deprecate and remove it.

1 Like

I'm not experienced enough with Android Apps to say it's the same as HPKP for browsers.


Me neither, but I provided lots of literature, which will hopefully help. I only pointed that part out to you as an FYI in case you never saw it.

1 Like

The certificate pinning that the Android platform provides ( is based on the SPKI (public key) of the certificate.

Certbot automatically rotates the private key at every certificate renewal (unless you disable it using --reuse-key), which breaks this type of pinning.

Certbot doesn't pre-generate future private keys either, so if you want to have a backup private key, you're going to have to organize that on your own, outside of Certbot. If you ever need to use the backup private key, that would be an entirely manual process as well.

You could pin the Let's Encrypt roots instead, but you'd be moving your trust from "I trust a key I control" to "I trust a key Let's Encrypt controls".


The short answer is: Don't use pinning.

Pinning is very difficult to do right, and it is very easy to do it in a way that will weaken your security instead of strengthening it.

If you have a very special situation where you need it anyway, then don't use a publicly trusted certficate, like the ones from Let's Encrypt. Use either a self-signed certificate or run your own private root CA.

Why? When you use a publicly trusted certificate, industry standards require you to be able to replace it within days at any time (either 24 hours, 5 days or 7 days depending on the situation), but that is not possible if you use pinning.


I already read some articles that states SSL Pinning is a mechanism to secure your apps and avoid Man in the middle attacks.

So as you say, maybe ssl pinning is not a appropiate option to secure a system, in my case I tried to secure the communication between my app and backend. There is an alternative (or best option) to secure communication between app (android/ios) and backend (api rest)?

1 Like

Just regular SSL, without pinning, is already good enough to defend against relevant MITM attacks.

Pinning can help in situations where the device itself has been modified to subvert the normal operation of certificate trust.

For example, devices enrolled in MDM with forced SSL decryption. Or devices where end-users themselves are reverse-engineering other people's apps (though in this case, pinning can be defeated anyway).

And I suppose, it can defend against malicious CAs. But at some point, you either trust WebPKI or you don't.

1 Like

with only ssl (https) there is a certain degree of protection against MITM attacks?

1 Like

Yep. Secure establishment of a shared secret (session key) for starters. Hence the primary purpose of PKI. :slightly_smiling_face: