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.

Followed by a link to a page with all the limits we could find.

The submission URL should probably be changed to https://keychest.net/content/letsencrypt_numbers_to_know

The current link is just a poor summary of the data on that page.

Funny enough, the page with a full analysis didn't get any upvotes. It seems that a short summary is more interesting.

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.

Not true, it means that the certificate is not EV.

I see 'Secure' on my Chromium running under Debian, without any antivirus software.

That's not true. Where did you get that idea?

https://support.google.com/chrome/answer/95617?visit_id=1-63...

Know the difference between extended validation and regular certs please

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.

Looks really nice! But starting at $395/yr sounds steep.

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 [email protected] to know more about the product.

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.

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?

Is this really what i am reading?

Certbot isn't the only acme client in town. I use Chef personally: https://github.com/schubergphilis/chef-acme/

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.

I have another cronjob that fits the same description, runs daily, and it's called "unattended security updates". Just saying.

Edit: Also, it's a persistent myth that certbot needs to run as root. It most certainly doesn't on my servers.

> 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 didn't find CSR creation to be that complicated either, but a lot of people on my team were intimidated by it when we were doing a code signing app.

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.

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.

Setting up LE requires you to do/learn a new process, so it's expected that it looks more complicated than the process you already know.

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.

… 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.

Yes (thank you for clarifying this point for others), the first mail is sent a month before expiration, and the certs are renewable after a month.

So with a weekly cron (for example) you should never get any mail from LE. That's why I meant. Thanks again.

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...

The magic isn't Let's Encrypt per se, but the ACME protocol seems to be something traditional CAs should be getting behind.

They are! https://letsencrypt.org/2017/06/14/acme-v2-api.html

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.

I'm very excited that Letsencrypt is free.

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.

So that's the provisioning process at server setup/instantiation; how do you handle the 90 day renewal?

The ansible role installs my ACME client of choice (https://github.com/lukas2511/dehydrated), invokes it once, and adds a cronjob.

We do the same and I found it a breeze, I even have some hooks which talk to the cloudflare API to setup the txt records for verification.

Thanks!

I assume the GP's ansible role writes a crontab entry to perform the renewal.

If the acme client is integrated into your web server, then there's literally zero effort to use let's encrypt.

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

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.

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 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.

Certbot developer here.

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.

> I know that some people have said they don't like running a large new application as root, even when it's open source.

Certbot could be configured to run without root with little effort, at least the part exposed to the web that was my concern.

> runs software on your server

letsencrypt doesn't require you to run anything on your server.

Cronjob != anything?

They are not running anything on the server, you can implement your own renewal software with their protocols.

I don't like the idea of a monopoly either.

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.

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.