Let’s Encrypt in the spotlight
dancvrcek.com
dancvrcek.com
The current link is just a poor summary of the data on that page.
I see 'Secure' on my Chromium running under Debian, without any antivirus software.
https://support.google.com/chrome/answer/95617?visit_id=1-63...
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.
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.
Let's Encrypt is a non-profit service and we don't use your data for our benefit. We work hard to collect and retain as little of your data as possible.
We do not require you to run software from us on your server. You can use any client you want. In fact, we don't even produce client software -- all Let's Encrypt clients are built and maintained by our community (the client we often recommend, Certbot, is an EFF project).
If you don't like Certbot, we definitely encourage you to use one of the many other implementations:
https://community.letsencrypt.org/t/list-of-client-implement...
Some of these are much lighter weight than Certbot and have many fewer dependencies. You can also take your pick of what language they are written in and how they are installed on your system.
You're also welcome to write your own client that speaks the ACME protocol. Let's Encrypt is near to rolling out an API endpoint that will speak the IETF-standardized version of ACME, developed through an open standards process and in consultation with other implementers.
I know that some people have said they don't like running a large new application as root, even when it's open source. So, please have a look at some of the other clients and see if one of them strikes your fancy!
Let's Encrypt's operational funding is thanks to these entities
https://letsencrypt.org/sponsors/
which view the service as worthwhile and important and have chosen to donate funds to support its operation. The organization is overseen by these people
In this model there is no need to charge users for certificates or try to indirectly monetize the use of the service, although users are very welcome to donate if they find the service useful, and Let's Encrypt may be more sustainable if some users choose to do so.
Certbot could be configured to run without root with little effort, at least the part exposed to the web that was my concern.
letsencrypt doesn't require you to run anything on your server.
But the issue here is what is "reputable". Most of (all?) the major commercial suppliers that I am aware of have been involved in major incidents.
The only reputable supplier I could name, is LE.
But I personally like the fact there's much less commercial pressure on LE - for the time being at least.