Hello Team,
When we try to renew the certificates generated by LetsEncrypt, does the expiration date get extended for the same certificate or a new certificate gets created with new keys ?
Context: We're trying to implement SSL Pinning at client which requires to verify the public key of the certificate and it would create a problem if the certificate of the server changes for every 3 months
Regards
It's a new "certificate" regardless (as part of what the CA signs in a certificate is the expiration date). But whether the private/public key is new is up to you. Let's Encrypt doesn't care one way or the other if you reuse your key. Many ACME clients have a way to use your own CSR or to just reuse your past key. See, for instance, cerbot's --reuse-key option.
Please do be careful about how and where you use pinning—there are some cases where it might be appropriate, but there are other cases where people unexpectedly couldn't create new certificates that satisfied the pins, and therefore lost access to something. (The saddest cases here on the forum are manufacturers who put certificate pinning rules into embedded devices, which couldn't be updated with new pinnings without a certificate that satisfied the old pinning!)
If you pin an intermediate certificate like Let's Encrypt's, this will eventually break as intermediate certificates are retired and rotated (sometimes significantly before they expire). (See Search results for 'pinned x3 intermediate' - Let's Encrypt Community Support for some sad stories and some dodged bullets related to the retirement of the X3 intermediate.)
If you pin the key in your own end-entity certificate, this is more or less under your own control, but will break if you ever lose the corresponding private key, or if it gets leaked or stolen somehow and the certificates using it have to be revoked.
In any case, you should consider what you will do in your application if the pinning rule can no longer be satisfied at some time in the future for a reason like one of those above!
Thanks; I probably should have added some of those warnings myself. 
So, piggybacking on that and to try to make it clearer, rather than just pinning one public key you probably want to have multiple keys you accept, with at least one backup key that was generated on a separate system and stored securely elsewhere (preferably offline in some way).
Also, if you don't want to rely on the full WebPKI with just having a few roots in a trust store and want to deal with requiring specific keys directly, why bother with Let's Encrypt? Just make your own self-signed certificates and use those. Or at the very least, ensure that your pinning works when your public key is in a certificate issued by somebody else as well. While I love Let's Encrypt and fully expect it to be around for the long term, if they suddenly have a problem that stops them from being able to issue certificates for a long time, or run out of funding, or need to switch to a new root for whatever reason, then you want your system to be able to continue running. (ISRG Root X1 expires in a short 15 years from now, so there will certainly be other roots you'd be expected to use by then.)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.