You're going to have to renew anyway. Previously you would have to remember to do that once a year, or maybe once every two years. Now let's ignore the security implications of having certificates that are valid for a year for a moment, and just focus on the actual work. Every year, you have to request a new certificate, wait for your certificate authority, upload the new certificate to the server, reload your webserver, check if everything works.
With LE, you do all of that once. You set up the tooling and the cronjob once. You make sure it works once. And you're done. No more hassle.
I'm not claiming these risks are that significant, but given that LE takes just as much time and effort for initial set-up as a standard multi-year cert, if not more, I think the mantra "some risk of failure is more risk of failure than no risk of failure" is something worth baring in mind.
And I'm not convinced having 90 day certs is a huge security win. Not only can someone do a lot of damage in 90 days, but your private key (the important bit) can't be rolled every 90 days anyway without integrating your rollover scripts with your HPKP config. If you botch that then your visitors can't come back to your website until the pin expires. Scary. Site ending scary. And if you're not using HPKP then i'm not even going to debate the security pros and cons.
On remembering to renew certs... there are many many services out there to send you reminders. Pick 2 or 3 and use them all. Or use a CA that sends reminders.
I'm glad LetsEncrypt exists, but let's not treat it like the be-all-and-end-all.
That's why I renew them a week in advance. I set up Nagios checks which alert me when a certificate is not renewed. Those were already in place before LetEncrypt since human error is just as likely as a script breaking.
given that LE takes just as much time and effort for
initial set-up as a standard multi-year cert
It's just going to take a long time to get there :)
It already is. Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception. That's the security model of SSH, and has the same assurances. It's just a terrible comparison. We can do better.
A better comparison would be with DNSSEC...
The way to simplify TLS deployment, while getting a better level security as DV CAs, would have been DANE. DNSSEC has an unfortunate reputation as being hard to setup ("pdnssec secure-zone mydomain" is not hard), but it also has exactly the same X day rollover key problem to solve as LE. Solving it once instead of twice would have made a lot of sense.
The symmetries between DNSSEC and LetsEncrypt are striking. Your account key is your KSK. Your cert is your ZSK... but instead of your webserver (in DNSSEC, your DNS server) doing rollover for you, you're depending on a pile of scripts, leaning on an already insecure DNS, and setting it up is still, comparatively, a pita.
As the Caddy server linked in another comment shows, nothing in LE requires you to depend on a "pile of scripts" to do roll-over for you, it's just early days.
DNSSEC puts the CA monopoly in the DNS. There is no API for a hypothetical web server using DANE, because there's no need for periodic domain validation. Of course, DNSSEC is a disaster, so it's a non-starter... but I'm still going to lament the fact that everything is terrible.
Don't do this. If you have to ask your users to add an SSL exception you're doing it very wrong.
I run my cron job[1] every hour. It checks for the expiry of my existing set of certificates and has a configurable parameter as to how soon before expiry to renew them.
it's what I do
I know for me, it was a choice between farting around with lets-encrypt for hours, or a $40 wildcard cert. so I went with the $40/year cert instead.
There are just too many choices for lets-encrypt with no super-simple how-to for people who don't know this stuff (like myself).
In the next few months we'll be shipping an Nginx installer plugin and model renewal scripts for operating systems to provide native automated renewal with their packages of the client. Both of those should help to reduce the amount of work for your use case!
I'm thinking the only thing that would really fix this is an nginx module that would automatically fetch certificates for domains when they're first requested via SNI. First hit takes some time, then it's cached and refreshed once a month or something... it would effectively mean 0 configuration SSL for all new domains.
Regarding the 5 requests per week, I believe that's only for repeated re-issuances of the same domain. As long as you cache the certs, then this shouldn't be an issue. Registering new certificates for new domains is limited to 500 per 3 hours: https://community.letsencrypt.org/t/rate-limits-for-lets-enc...
this is too hard: https://antipaucity.com/2016/02/26/automated-lets-encrypt-ss... ?