Like with a lot of tech trends, I seem to be one of those people who doesn't "get" the excitement about letsencrypt.
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.
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.
… except ensure the cron job runs reliably on a timescale of years…
(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...)
I personally think it being a cron job is a bad idea. I do my LE cert renewal in the web server itself, so the web server would have to crash for the LE cert renewal to not run.
LE send you a mail if you have a cert going to expire. Easy to spot if something went wrong in your cron tasks (not that you can totally rely on automated task of course, but it's another layer of security)
Before someone complains that LE is going to spam you with expiry notices: If you set up your process right (i.e. certbot cronjob with --keep-until-expiring), certs will be renewed early enough that the mail reminder never triggers unless there's an actual problem.
It still seems wrong to do it that way. Plus, the TLS-SNI-01 challenge is just such a clean way of handling it, no need to have a special path handling or anything. Server up and running? Then my cert is being renewed, assuming LE isn't broken at least...
It's free, and automated so you don't run into TLS outage post-mortems where the question "why does the cert expire at christmas anyways?" is "Because it expired same time last year and during the emergency repair we used the default lifetime period of one year."
Why is your LE broken? 'because 1 of the 12 automated renewals last 3 years (to compare vs 3 year paid certificate at 4 euro) failed for reason X, Y or Z'. Be it them being down, be it your uplink being down, be it your dns malfunctioning, be it another massive spamhaus-sized-internet-disrupting-ddos. There are plenty of ways a LE renewal can go wrong, and having this 'chance' occur 4 times a year, i find bad practice.
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.
> Be it them being down, be it your uplink being down, be it your dns malfunctioning, be it another massive spamhaus-sized-internet-disrupting-ddos.
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.
So you prefer to have something (which most people have ) with root privileges to pull data unattended, 52 times a year, from some 3rd party host via python then to manually do (if you wanted ONLY once in 3 years) something once a year manually?
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.
> There are plenty of ways a LE renewal can go wrong, and having this 'chance' occur 4 times a year, i find bad practice.
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?
"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."
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.
I just have an ansible role which runs against a server and SSL gets set up 100% for free. It's wonderful. One time time investment to write the ansible role, and now it takes like 5 seconds to enable for any server I'd like.
It depends on your use case a bit. I'm responsible in some way for a small pile of other people's domains; for those that I do all the hosting on, I get to have SSL-by-default totally effortlessly thanks to LetsEncrypt.
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.
The nginx ingress controller with kube-lego is officially my new favourite thing. Got it up and running on three clusters I manage a month or so ago and haven't looked back.
So great to just push an ingress manifest and 10 minutes later suddenly get redirected to HTTPS.
Every time LetsEncrypt is brought up I am reminded of "if it's for free, You are the product". In this case it is one's servers. A single company has a hand on the pulse and runs software on your server in exchange for continuous "convenience". I am still NOT buying in, diversifying SSL certs from reputable companies with 12 (or sometimes 13) months validity are still ok for me in 2017.
This seems a little tin-foil-hatty. The only information which Let's Encrypt receives is the domain name that the certificate is for (which is public anyways for any CA implementing certificate transparency). The Certbot software is open-source and easily verifiable, and there's multiple independently developed alternatives available if you don't like it.
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
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.
I agree, but you could say that any of major issuers was reputable 2, 5, ... years into issuing certificates. Being new doesn't mean you're better long term.
But I personally like the fact there's much less commercial pressure on LE - for the time being at least.
I don't really understand what you're implying but here's some information that might help.
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).
This seems like a basic explanation of some of the stuff on the Let's Encrypt rate limit page (with some funny stuff mixed in to make it sounds like the rate limits for IPv6 are somehow higher), followed by a link to a product.
Ironic that the "https in browsers" figure uses a screenshot with a certificate MITM'd by the antivirus software. If you see "Secure" in the green bar instead of the domain name and EV attributes - your antivirus software is MITM'ing you.
ManageEngine Key Manager Plus (https://www.manageengine.com/key-manager/) automates the entire process of procuring certificates, track expiry, renew and deployment of Let's Encrypt certificates.
Thanks for your kind words. ManageEngine Key Manager Plus has got lot more features than just SSL Certificate Management. Please get in touch with us via keymanagerplus-support@manageengine.com to know more about the product.
50 comments
[ 0.24 ms ] story [ 97.8 ms ] threadI 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.
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.
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.
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.
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.
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
https://letsencrypt.org/isrg/
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.
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).
The current link is just a poor summary of the data on that page.
https://support.google.com/chrome/answer/95617?visit_id=1-63...
I see 'Secure' on my Chromium running under Debian, without any antivirus software.