How to not change the keys while renewal for SSL pinning mechanism

I have installed LetsEncrypt on Ubuntu 16.04 Apache server. It generated 4 .pem files under its letsencrypt/live directory. I am using the public and certificate pinning mechanism and dumping them into the iOS app bundle. To avoid updating the app on renewal i have read that it has to be renewed using a --csr flag but couldn’t get much help on this. Can letsencrpyt renew the way i want to or i need to use some other client? Do i have to regenerate all the certs as am sure it generated only pem and i can’t find no csr files while creating certificates with Letsncrypt. Thanks.


The Certbot client currently doesn’t have this feature. Other client software might. We are working on it but it won’t be available until the next release.

In particular, the renewal features of certbot renew (previously letsencrypt renew) currently can’t do this. If you make a CSR yourself, you can refer to it by --csr, but this is a rather distinct way of using Certbot.

1 Like

No, for two reasons.

First, Certbot did generate CSRs and save them in the typical format used by OpenSSL. When using Certbot normally, the CSRs are managed in the background and you don't ever have to deal with them directly, but luckily they are there. They're in the directory "/etc/letsencrypt/csr" with sequential filenames such as "0012_csr-certbot.pem" or, for older versions of the client, "0012_csr-letsencrypt.pem".

You can use "openssl" to examine them, for example "openssl req -in /etc/letsencrypt/csr/0012_csr-certbot.pem -noout -text".

Second, you can always generate a new CSR when you have the private key. Using "openssl", you would do something like "openssl req -days 365 -key /etc/letsencrypt/live/ -new -out foo.csr -sha256".

I'm not sure what strategy you should or will take, but "not having a CSR" is not an issue for you. :slight_smile:

(Edit: Left an argument out.)

1 Like

Thanks for the clarification, @mnordhoff!

Hi @adnan

the HTTP Public Key Pinning is quite a tricky mechanism

Essentially you use the modulus of the public version of the public key to create a fingerprint of the certificate

Quick recap - generate rsa key, generate CSR from key (use CSR to get cert)

Where people come unstuck is that usually this is configured for 30 days. Meaning if you need to change it during that period the browsers have cached the HPKP and I am not sure if you can clear this.

There are several solutions

A) Prep 6 CSRs and add them all to your HPKP. When it comes to renewal you specifcy the CSR but their fingerprints are cached in advanced (so no one will lockout). This will require you to store the private keys and CSRs somewhere on your web server until you need them. When renewing with certbot you use the CSRs. CSRs can also be updated as private keys are there.
B) Reuse the Same CSR (same private key) for your requests


1 Like

a good overview is here

i usually advise customers to think about this carefully before implementing :smiley:

FWIW, I wrote a bot that re-uses keys during certificate renewal for just this purpose, it also allows multiple certificates to share a common key (allowing the pin-subdomains HPKP feature to be used without having to use the same cert for every subdomain), generates and manages backup keys (allowing changing keys without bricking your site), and generates HPKP header information for you (including both the current and backup key).


so you are generating and HPKP header with two keys?

can you select the number of keys to stage?

I haven’t had a look at the code based but some of this python code should be reusable (either as a post hook or as an installer for certbot)


thanks, ill try that out

You can’t select the number of keys, but each certificate has a primary and a backup key. It can also generate both RSA and ECDSA keys (and certificates) in parallel, so each HPKP header may have up to four pins (primary and backup, RSA and ECDSA).

When renewing a certificate, it re-uses the same private key, but it will perform a key rollover (switching from primary to backup) after revoking a certificate, after a given number of days (the default is 2 years), or on command. It also prevents a key rollover if you try to do it too soon (before any cached HPKP pins that don’t include the current backup key have expired).

Feel free to use any of my code in certbot.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.