On 11/28/2016 03:04 PM, sivmu wrote:
Am 28.11.2016 um 23:23 schrieb Alice Wonder:
On 11/28/2016 02:12 PM, Raoul Bhatia wrote:
I've successfully transitioned existing StartSSL certificates + HPKP /
HSTS to letsencrypt.sh (via the Debian package).
I know I am not the first to do such a thing, but maybe you'd like to
have some quick pointers to get this resolved ASAP.
Raoul
PS. The most important thing is to initially tell letsencrypt.sh to
reuse an existing private key for requesting new certs.
And that is exactly why I never use HPKP - it does not give the system
administrator any flexibility when a new cert / key is needed.
In theory there should be a backup key already with a pin to take care
of cases where the private key is compromised, but as soon as you have
to use it you are vulnerable to bricking the site for some users if that
key needs to be revoked.
It also gives no flexibility whatsoever when you have to fire a system
administrator who may have had access to private keys. Normally in that
situation you generate new keys, but with HPKP you are stuck keeping the
old keys active until the new keys have had their pins in the header
longer than the TTL.
This issue can be solved by using sort life spans for certificates/keys
like lets encrypt does. At least it reduces the drawbacks
No it doesn't solve the problem, the certificate lifespan has nothing to
do with the private key.
Why people like HPKP so much is a real mystery to me.
Because HPKP recreates some level of trust in a (almost) compleately
broken and highly flawed system?
It's a broken solution that only somewhat works for one very specific
application of x509 certificates.
A better solution (DANE) exists, is not limited to HTTPS, and doesn't
prevent you from deploying freshly generated private keys in an emergency.
But Google pushed HPKP out on the market in a Chrome release and that
was that.
What's interesting, under some conditions Chrome doesn't even enforce
HPKP which is kind of suspicious and makes it somewhat useless.
e.g. on Chrome HPKP would be useless against a fraudulent certificates
signed by the root key that Lenovo or Dell added to the root store on
user's systems.
_______________________________________________
Ach mailing list
[email protected]
http://lists.cert.at/cgi-bin/mailman/listinfo/ach
