Letsencrypt would they automate this aspect too with support for HPKP https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning ?
so auto generating both the primary and backup CSR/key and SPKIs ?
how would automated renewals work come every 90 days ?
Hi,
I think we all think HPKP is an important security technology, but of course one that has to be used carefully because it can lock users out of a web site entirely for a period of time (for instance, if a server hard drive fails with no backup). We would like to give people tools to make HPKP setup convenient or automatic, but we’ll probably need some experience with how people are using it, what their backup strategies are, etc. The HPKP protocol requires servers to specify a backup key as a precaution, but it can’t enforce a system administrator’s actually making an offsite backup of that key.
If we have time, I expect that an HPKP option will be included in the client around launch, but won’t be active by default. (By contrast, we may give users a built-in option or recommendation to turn on HSTS, which is a bit less risky in terms of accidental self-denial-of-service. In the early versions of the client, activating HSTS is part of the “Secure Mode” option.) But again, we could benefit from more experience with how sysadmins use HPKP, how well they understand it, whether it commonly causes reliability problems or outages, and so on, before we come close to trying to automate it for the typical Let’s Encrypt user.
indeed.. but the same would be said for primary key too
isn't it that technically the web browser doesn't know which hash pin primary or backup is the one tied to the current SSL cert so it checks both and if one matches the current SSL cert it's fine ? So technically, you could demote the current SSL cert's pin to backup and generate a new SSL cert and pin as primary pin hash and that combo would work too for emergencies ?
My primary concern is just the question of the sysadmin’s understanding of the consequences of HPKP, and ability and willingness to make an offsite backup. We don’t want to produce harmful traps for the unwary.
yeah Let’s Encrypt needs a fully comprehensive SSL FAQ for all aspects before launch - it will cut down time spent on support and newbie questions alot !
I’ve just published a blog on how I use Let’s Encrypt and HPKP: https://scotthel.me/LE
awesome stuff cheers @ScottHelme
AFAIK, HPKP can also pin the root certificate for a given domain - so one could just pin letsencrypt’s root CA. This has no real risk in case of disk failure, etc, and is an improvement to no-HPKP.
You’d still need to pin at least 1 backup or the policy would be invalid. You could pin the root of another CA that you’d fall back to if LE ceased issuing certificates or you can pin your own public key that you could take to any CA of your choosing to sign.
It is not that easy, e.g. because LE also has a backup root CA.
If you want to have a robust (failsafe) HPKP header I'd recommend you this official "Best practises":
I would suggest to never ever overwrite any files. My own script manages a directory hierarchy based on timestamps where each script invocation manages its stuff. Only if the validation of the new cert is successful a symlink gets changed. Then another portion of the script creates the bundle.pem in yet another location where HAProxy accesses it. Before overwriting the old bundle, it gets hashed and compared to the new bundle and only if there’s a difference is it written and the proxy reloaded.
This allows for a scripted handling of which chain certs to include, whether custom DH parameters get included and so on (HAProxy needs custom DH params inside the bundle). You could change the DH parameters or the chain certs and run the script and it would recreate the bundles even though the certs didn’t change.