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?
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.
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).
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.
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".
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)?
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.
My 2c, if you have to do anything when there is an ordinary event like time passing and a certificate is re-issued then you have created more work and more risk for users than you are solving.
The OkHttp docs discuss how to implement for Android
If you aren't quite sure which certificates to pin against from a) your site certificates, b) intermediate certificates, c) root CA certificates, then you probably shouldn't be worrying about this.
However If you have a high profile app that you think companies, or educated actors will try to MITM. Say by installing certificates and proxies on devices or intercepting connections on the network, then your security team should probably define a long term almost zero maintenance policy. And use the instructions above or similar for your mobile client.
