Can I setup Public-Key-Pins when I setup a cronjob to renew the LetsEncrypt certificate every 30 days?

If the certificate is renewed then the Public-Key-Pin is also renewed right?

3 Answers 3


Some words of caution to begin with:

  • Know what you're doing, if you're planing to implement HPKP.
  • If you don't do it right, or "if bad things happen", which aren't under your control, you might render your domain unusable.
  • Be sure to test your setup with a domain which isn't that important, or with a very short cache time, like ten seconds for example.
  • Think about which certs you would like to pin: Root, intermediate, leaf...
  • Think about if it makes sense to pin another (backup) certificate authority, it's intermediate certificates and your leaf certificate.
  • Better safe than sorry: Think about if it makes sense to pin another backup CA / cert, to have two.
  • If these points and questions sound "new" to you: Read what HPKP is about and the common traps and caveats, before you implement this.

Can I use Public-Key-Pins with LetsEncrypt?

  • Yes.

If the certificate is renewed then the Public-Key-Pin is also renewed right?

  • This depends on which certificate you're referring to and which cert(s) you're pinning.

Would echo everything that gf_ said.

However, to answer the question, yes you can.

By default Let's Encrypt recreates the key and the cert at renewal. This makes implementing HPKP difficult if you want to pin at the leaf, which you probably should do in case intermediate changes (like it did in March 2016).

So you've several options around this if you still want to do HPKP:

  1. Use your own fixed CSR rather than the standard client which creates the CSR for you each time so the leaf key doesn't change. This blog post explains how to do this specifically because the author uses HPKP.
  2. Use short HPKP expiries and renew within that expiry time and change policy to have both old and new keys before actually changing the cert, with enough time for new policy to be picked up by any visitors.
  3. Pin the Let's Encrypt root instead of the leaf or cert.
  • 1
    Good additions, +1.
    – gxx
    Jul 9, 2016 at 19:37
  • 1
    Is it safe to pin the root? For a MITM it's really easy to use his own Let's Encrypt certificate.
    – melbic
    Dec 6, 2016 at 8:08
  • 2
    How is it "really easy" for an attacker to get a cert for your domain name using Let's Encrypt? Not aware of any way of doing that. However it may be possible with any CA if they have bugs in their domain validation procedures. By pinning LE root you've massively reduced your attack surface down to just Let's Encrypt as opposed to every CA in the world. Still not as safe as pinning leaf I agree but that introduces it's own risks so depends on your definition of "safe". Dec 6, 2016 at 8:15
  • Saying that I do think there are MASSIVE risks to HPKP - mostly from a self suicide perspective - so am not a fan. If you decide to change CA, or cert path changes (e.g. due to SHA-256 depreciation), or urgently have to reissue cert, or backup key gets compromised/lost or the person who set it up leaves and next person doesn't realise they use HPKP and/or doesn't know about it. HPKP also doesn't protect against local roots such as Superfish. So, for most sites, HPKP, is too complex and, IMHO, not worth the added protection for the little added security gain. But that's just my opinion. Dec 6, 2016 at 8:20
  • Ok, I only asked because I thought, that all the LE certificates have the same root certificate. So if you pin the root somebody else with another LE certificate can just use an MITM and fake in it's own cert. Do you know what I mean?
    – melbic
    Dec 6, 2016 at 8:36

I just implemented this using the dehydrated client with dns01 validation. The dns01 hook is certzure because our DNS is hosted in Azure.

Edit: when I talk about private keys, obviously I always mean that you only turn the public key parts into pins. The private keys, as the name suggests, should always remain private. See my own hook for implementation details.

You need private key rollover to make this possible. That is, you always have the current private key (call it A) and the future private key (call it B) at hand, so that you can add them both to your pins. So at this point your pins are A and B. When the day of cert renewal comes, private key A becomes obsolete and B becomes live. At the same time you get a new future private key, call it C. You regenerate your pin list so now it contains B and C. So that's how you roll your private keys over. dehydrated supports this now.

Also, you need a hook that is called every time you renew your certs and thus roll over your private keys. I implemented this on my own.

Finally, if I get this right, you gotta make sure that:

HPKP age x 2 < days between cert renewals

For example, if your HPKP age is 50 days and you renew certs every 30 days, a client who visited your site on day one will be stuck with private keys A and B, and you rolled over to B and C at day 31. Your server has B and C, the client has A and B, there's a match even on day 50 and the client opens the site correctly.

BUT let's see if HPKP age is 70 days. You renew certs every 30 days, and the client visited your site on day one, so again, it only has private keys A and B. You rolled over to B and C at day 31, and rolled over to C and D at day 61. Your server has C and D, the client has A and B, there's no match and the client is given the middle finger from day 61 until day 71, when its HPKP policy expires.

Another, probably safer, and certainly much simpler option is using the same private key every time and generating one or several backup private keys, then hardcoding these into your HPKP config and be done with it.

Yeah, it's tricky and there might be caveats I haven't thought of, but we'll see in the long run. Obviously I deployed it on an uncritical subdomain with short (15 days) HPKP age so that it doesn't cause huge troubles.

Edit: I've written a few scripts to help you setting up HPKP with Let's Encrypt and dehydrated using Nginx:


  • 3
    I decided to have the best of both worlds. Automated private key rollover + a static private key. Might write a blogpost about it if anyone's interested.
    – bviktor
    Jan 23, 2017 at 15:00
  • 1
    If you do this, please edit your post and insert the link - thanks!
    – gxx
    Jan 24, 2017 at 0:56
  • Thanks, I'll try my best to finish that this or next week
    – bviktor
    Jan 25, 2017 at 18:41
  • 2
    Link added. Documentation is scarce yet, but the code is there so that you can try it and hack on it.
    – bviktor
    Jan 26, 2017 at 18:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .