HTTP Public Key Pinning (HPKP)

Continuing the discussion from Maximum (and minimum) certificate lifetimes?:

2 Likes

Yes, I'm aware of this. The part you quoted from my reply was intended for @My1 as a reply to his/her idea of automating this.
As I also describe later in the post you quoted it's of course possible to use the same HPKP hash longer than 90 days.

However I was not aware of the fact that the LE client regenerates the private key every time. That's very interesting (and quite important) to know, so thanks for mentioning this.

1 Like

Another thing I’d like to add (ask) to (in) this HPKP discussion is:

AFAIK the LE often requires the server operator to cryptographically prove (aka sign) that he owns the private key of a (previously) used certificate.
However in case of HPKP and an attack you may get problems, because if your server is compromised and you have no way to get to the private key, so you have to reset your server, you may get problems with this challenge.
This may be problematic when you want to get a backup cert signed by LE after an attack.

So this means you should always also backup the currently used certificate.


Please correct me if I am wrong, because I only had this cryptographically verification in mind and thought this could be an issue here.

1 Like

yeah this is a bit stupid why not rrather require the account key?

I think this is only required when issuing a certificate while there’s currently another service active at domain.tld:443. I shut down my previous server and issued the certificate, I didn’t have to provide any possession information, maybe because LE didn’t know the state before in this situation.

If you do not want to pin your leaf certificate (which would be the most secure, but most risky option) you can also pin the intermediate certs of LE. Here is a detailed guide how you can do it:

1 Like