The background is the following: Right now certificate revocation is essentially broken. There are two mechanisms (CRL and OCSP), and both don't work. CRL for obvious scalability issues and OCSP because you'd need near 100% uptime of the OCSP responder for it to be reasonable and never have any firewall (think of captive portals) that blocks the conncetion to OCSP. Therefore browsers decided either to implement OCSP insecurely with a soft fail (mostly pointless) or not at all.
So we have no working revocation. Someone hacks into your server and steals your key and uses it to attack your users. What do you do? Of course you revoke your cert, but it doesn't really make a difference.
People have been thinking how to fix revocation. One way would be OCSP Stapling + must staple. But that's still a long way till this will work (the ocsp stapling implementations of both apache and nginx would need a huge overhaul, they are pretty bad and not up to the task). Short lived certificates are a way to make revocation less important, because it reduces the time a hacked key can be used.
And if this really bothers you a lot: There are two other free CAs that will give you one year certs: StartSSL and Wosign.
That was a proposal before the specs of HTTP/2 were official, it's not a requirement anymore.
> I truly appreciate the heroic efforts of let's encrypt, however that seems to be an annoying middle step before DNSSEC.
I don't think that DNSSEC is a great idea. Chrome supported DANE for a while, but they removed the support for it.
TLS + HPKP + HSTS is working great, DNSSEC don't improve a lot when we would add it.
I also really want to have the argument for improved security. Because a compromised host can now generate new certs for himself at zero cost as well, so what's the real point behind the 90 day limit? Giving NSA less time to crack your key?
Thanks for clarifying.
A TLS cert change doesn't bring down your website. Swap the old cert for the new and reload. Done.
> Or any problem with letsencrypt basically giving you only <90 days to generate a cert with somebody else?
Look at the folks behind the project. Take a good look at the folks running and funding the project. They know how to run an essential Internet service. Moreover, they will give you more than 90 days notice if they ever need to shut Let's Encrypt down.
Frankly, you can level this criticism at any vendor that's a potential SPoF. It's not a good complaint when it's so general.
> Because a compromised host can now generate new certs for himself at zero cost as well...
Because -AIUI- CRLs don't currently work well -in practice-, a 90 day window of cert validity limits the amount of time a given cert can be out in the wild, impersonating your site.
> ...what's the real point behind the 90 day limit? Giving NSA less time to crack your key?
If I might snark for a second:
1) If your box is pwnd, and your private keys aren't in an HSM, then there's no need to try crack your key.
2) AFAIK, there is no non-brute force attack against the public part of a correctly generated TLS keypair that will reveal the private part of the key. (Or am I totally wrong about how TLS works, and there's only a private key? I can't remember. :( )
But a the OP pointed-out, if a site using LE is compromised then the attacker has basically an infinite duration of valid certs, because they are automatically renewed.
There is no manual challenge to receive a new cert. So essentially the validity period of an LE cert means nothing.
The 90 day window mitigates the effect of the cert being leaked.
Just because I grabbed a site's cert on day doesn't mean I control the site. In fact, there's nothing to say I even compromised the site to get the cert in the first place. Perhaps it was mishandled internally? Or grabbed via a heartbleed-style attack?
As zeendo mentions, this is only true while the attacker can continue to provide proof that they control the site in question.
> There is no manual challenge to receive a new cert.
You're talking about a server on which an attacker has the ability to
* Read the server's ACME private key
And one or more of
* Add new documents to [scheme]://[domain]/.well-known/acme-challenge/
* Stand up a HTTPS server at the domain for which a key is being requested that responds with LE-provided data using a LE-provided temporary key.
* Sign challenge information using a previously issued private key.
* Add a TXT record for the domain in question containing data specified by the LE server.
This requires a server to be pretty thoroughly pwnt.
What's more, even though cert revocation works poorly in the real world, the LE servers almost certainly respond correctly to cert revocation requests. So, if a server operator notices that his box has been pwnt, he can revoke the certs that were issued during the time, closing the "Sign challenge info using a previously issued LE key" barn door for good. (Or until his machine gets pwnt again.)
Frankly, I think that OP hasn't actually had a good look at how the LE software works, or the design of ACME.
I'd be a little hesitant to switch commercial or critical sites to using Let's Encrypt right now. But overall, no, I like automated renewal. I think I'd choose to get a new certificate monthly, instead of 3 months. The provider I was using before with very low prices requires me to go through a manual process through their website. The main feature to me that'll cause me to switch is being able to set it and forget it. With automated monthly renewals, the 90 day expiry is extra buffer in case something goes wrong.
90 days isn't short, it's about 89 days too long.
Do tell. How is LE a middle step before DNSSEC?
(I would appreciate it if only tenfingers replies. I'm interested in his response, not speculation from the rest of us. :) )
Especially given the cert is basically now a requirement to get onboard with http2 at all.
I truly appreciate the heroic efforts of let's encrypt, however that seems to be an annoying middle step before DNSSEC.