Just because something is free, doesn't make it better. And having 12x more points in same timeframe where the automated renewal can fail, certainly doesn't make it better statistically.
Also i grew up with the notion, 'nothing in the world is free, except the sun'. So i wouldn't be surprised if they will start to monetise this LE user base at some point in time.
I have my certbot set to run once a week with --keep-until-expiring, so it will try to issue a new certificate when the old one's remaining validity is less than a month. I could also set it to run daily, because it doesn't actually do anything if the cert is still valid for long enough. But a week works on my (admittedly small) scale.
So unless you're experiencing a multi-week DNS malfunction or multi-week DDoS (in which case you're in some deep shit anyway), you should be fine.
Is this really what i am reading?
Professionally, it's not once every three years, it's that x the number of clients we host. Which is a lot. Many are clamoring for LE, because it's within their budget: $0. So yea, I want to automate that.
Edit: Also, it's a persistent myth that certbot needs to run as root. It most certainly doesn't on my servers.
Fortunately, we can also discard some of the high stakes gambles we take to avoid cert costs. Your cert lives for 90 days. Why wait until day 89 to renew? It's certainly not to avoid the expense. The LE defaults renew at day 70. That gives you 20 days for transient failures to resolve themselves, so that's a concern you can dismiss out of hand. And if you don't think that's enough time for ops team to work out whatever problem they have, you can configure your tooling to renew sooner.
Yes, renewals every 70 days introduces a 5th renewal every year, but IMO the hardest and most important renewal is the first one, and you might as well take it sooner than later.
TANASTAAFL is a thing, but even if the only lasting impact LE has is to arm-twist CAs into a commonly accepted API, that's still a win in my books for competition and near-frictionless competition. Anyone seen the Comodo API? And how it compares to the Symantec API?
Remember there's multiple benefits that Lets Encrypt claims. A few that come to mind is it's free, transparent instead of shady, and has this tooling ecosystem forming. The free and non-shady parts are the most compelling advantages over prior, commercial CA's. On top of that, it's a public-benefit corporation with board members who have a history fighting against abuses of online privacy. You therefore have more assurance that the tooling you're investing time in might not get more evil or low-quality at the rate another offering might be if driven only by corporate greed.
On the plus side, I was aware of every cert that got set up and several of them were going to be created improperly or for sketchy reasons.
I have a node that can log in to other nodes, enumerate the domains they host, and then go through the LetsEncrypt authentication process for every domain on that node, retrieve the new certificate, copy it up to that node, and kick any services that need to be kicked. It runs once a day to handle renewals, or I can run it manually any time the hosting on a node changes.
I haven't had to think about SSL for quite a while now and that's fantastic.
If you're only responsible for one or a few domains, I can see how that wouldn't seem like a big deal.
But once you get past that, it's soooo much easier. All my domains are renewed via a cronjob. I don't have to do anything.
(Not that I think cron is unreliable - I only recently stopped getting monitoring summary email from a cron job I set up in '99 or '00 on a server that'd been migrated at least 3 times while I still worked there, and who knows how many times after I left in '08, I stopped getting the mail in '14 or '15... But I've also had cron jobs silently die when OS updates break perl/python/shell scripts or permissions - looking at _you_ OS X...)
So with a weekly cron (for example) you should never get any mail from LE. That's why I meant. Thanks again.
From the URL:
Second, ACME v2 was designed with additional input from other CAs besides Let’s Encrypt, so it should be easier for other CAs to use. We want a standardized ACME to work for many CAs, and ACME v1, while usable by other CAs, was designed with Let’s Encrypt in particular in mind. ACME v2 should meet more needs.
Either use Caddy (1) or integrate with nginx, traefik, gke or any other kubernetes ingress server via kube-lego (2).
1: https://caddyserver.com/ 2: https://github.com/jetstack/kube-lego
So great to just push an ingress manifest and 10 minutes later suddenly get redirected to HTTPS.
I don't find the process of generating a CSR and submitting it to a CA for signing to be more complicated than setting up letsencrypt. In fact I think it's quite a bit easier.