What You Need to Know about HTTP Public Key Pinning (HPKP)

Re:What You Need to Know about HTTP Public Key Pinning (HPKP) by mwpmaybe on Sunday February 07, 2016 @10:56AM (#11053260)

I feel stupid having to ask this question, but is a backup key literally just a different SSL certificate issued by the same or another CA for the same domain(s)? You keep it on standby in case your primary certificate is compromised? Do I use the same CSR and private key or do I generate new ones?

EDIT: Okay, the coffee is flowing and the gears are starting to turn. I guess if I'm going to pin my cert, I should generate a new private key for the backup, and if I'm going to pin the intermediate cert, I should use a different CA. And for maximum protection, do both, and not keep both private keys on the same servers. Does that make sense?

[ Parent | on HN ]

Re:What You Need to Know about HTTP Public Key Pinning (HPKP) by jlgaddis on Sunday February 07, 2016 @02:40PM (#11054416)

Yes. You want everything to be completely separate. In a way, It's kinda like falling over to a failover machine -- different storage, different network connection, etc.

If your "primary" certificate or any of the others in the chain is compromised -- for whatever reason -- you want the ability to immediately switch over to your "backup" certificate without problems or affecting your users.

[ Parent | on HN ]

Re:What You Need to Know about HTTP Public Key Pinning (HPKP) by sjtgraham on Sunday February 07, 2016 @11:08AM (#11053303)

It's the hash of the SubjectPublicKeyInfo field of an X.509 SSL cert. A different pin == a different public key, so you will need to generate a new CSR with a new key pair, as the public key is embedded in the CSR.

[ Parent | on HN ]