[Gasparila]

This article (and others I have read disliking HPKP) generally take an all or nothing approach. That is to say, they see HPKP as either "pin the key of my certificate" or "don't use HPKP at all"

In reality, you can have a valid HPKP setup as long as any keys in your certificate chain match the key in the HPKP header. This means that you can pin the intermediate certificate (or even the root CA if you want) key. By doing so, you are no longer vulnerable to losing your SSL keys, but now other CAs cannot issue certificates for your site

[ivanr]

No, you're wrong. There are no guarantees that you'd be able to get a fresh certificate from the same intermediate certificate. CAs rotate the intermediates all the time, for various reasons.

Of course, CAs can choose to make such guarantees ("the public key behind this intermediate will continue to be available for N years"), which would make the pinning much less dangerous.

[sdeziel]

That's why it's nice of Let's Encrypt to publish their current and backup intermediate CAs (X3 and X4) https://letsencrypt.org/certificates/. That's what I pin for my sites.

[agwa]

Barclays pinned to an intermediate. Here's what happened: https://cabforum.org/pipermail/public/2016-November/008989.h...

It worked out OK for Barclays in the end, but only because Symantec was willing to violate the Baseline Requirements to help them out. (I wonder how much that cost Barclays.)

[eridius]

Why did Symantec change the private key used for their intermediate certificate? It sounds like they switched from an older system to a newer one for issuing certificates, but that doesn't explain why they couldn't preserve the key.

[viraptor]

Or you get N certificates from different sources, pin them all, use 1, stick the rest in (a) safe vault(s). Even if something really bad happens, you can use one of the other ones until you cycle. Cost of N certificates will be << money you'd lose otherwise, and likely a rounding error in any company's monthly spending. (if it's already live / trading)

[pfg]

HPKP is based on the public key, so you don't necessarily need to obtain signed certificates in advance - generating a key pair and keeping the private key safe would suffice.

There is some value in ensuring that a CA is willing to sign a certificate using those keys in case something went wrong during the key generation (i.e. a key size or curve that's not supported by the Web PKI), so it might be considered a best practice to do that regardless.

[Scott_Helme_]

The only safe way to try and do that would be to make sure that the max-age of your policy was never more than the remaining validity of your longest valid certificate.

[stanleydrew]

There is a debate about which public key to pin, and I'm not sure it's settled. It depends on your priorities and the relative probabilities you put on various failure modes.

If you pin your public key, it's easy to switch CAs if the one you currently use goes under. This does happen.[1] But you are in trouble if you lose your key somehow.

If you pin your CA's public key, it's easy to recover from losing your key but you can't switch CAs until your pin expires. You could use the required second HPKP pin to add a fallback CA though.

I will note that this decision is not actually the hard part of deploying HPKP.

[1] https://blog.mozilla.org/security/2016/10/24/distrusting-new...

[the8472]

> You could use the required second HPKP pin to add a fallback CA though.

Or pin current CA + current pubkey? That way you can either change certificate within the current CA or use the current certificate to move to any new CA.

[Scott_Helme_]

In many of my articles I discuss the various ways to deploy HPKP including leaf pins, intermediate pins and root pins, or even a combination of different types of pin. They all come with various challenges and considerations that a site needs to consider.

[skywhopper]

Pinning the intermediate or root CA is actually more risky, since you have no control over it.