> It's not so much about replacing keys which aren't strong enough (and > actually you can just replace the old key+cert in that case), it's > about dealing with compromised keys. > > Certificate revocation is a disaster area. CRLs are often not checked > at all (letsencrypt aren't even generating CRL entries for end-user > certs - startssl will do but they charge for them, even for free > certs).
Ya I found out when I tried to upgrade to sha256 ;) and found I had to wait for the current ones to expire. > OCSP is probably checked more often in browsers than CRLs > but fails open in some cases (and has terrible UI in others) and > again isn't used universally - keeping certificate lifetimes short > is a useful way to limit the damage that can be done by a compromised > key. (and if letsencrypt *were* to start doing CRLs for revoked > end-user certs, keeping lifetimes short would also limit the file > size of the CRL). Well atleast that's a more sensible reason. Not sure I like the idea of a non priviledge seperated internet connecting script accessing the key every few months (it is open source though), potentially nullifying effort by some daemons/LibreSSL in that area. Despite joining the beta, I haven't had time to look into the tools yet. I guess/hope it wouldn't be hard to have a system user with key file access that provides a CSR to another chrooted system user that downloads the new certificate. ftp is pledged I believe in the next release which will add some belts and braces I guess too. -- KISSIS - Keep It Simple So It's Securable
