Hacker News new | comments | show | ask | jobs | submit login
Let’s Encrypt 2016 in Review (letsencrypt.org)
429 points by dankohn1 262 days ago | hide | past | web | 82 comments | favorite

Just want to say, I'm not affiliated with LE, but I think it makes a lot of sense to donate to them if you use their services regularly.

From my own use case, integrating TLS for my site via LE and the autocert package in Go has been seamless. It's completely free (if you want it to be), and it looks like I won't have to worry about renewing certs anymore. The service LE is providing is amazing. Just thinking of the millions of dollars they're collectively saving everyone, yearly, is pretty crazy.

If anyone at LE reads this, thank you for your work!

Yes! At my job I've setup a per-paycheck donation to LE because they have saved me so much time (apache, nginx and caddy automagic SSL) and in the long run it'll probably still be cheaper than buying one of the SSL certs from the other companies.

Our company made a small donation of $25 per month. https://letsencrypt.org/donate/

It is a small token of how much time they saved us from setting up ssl for our clients. These small monthly donations can add up help them thrive in the future.

That's wonderful! How does your company write that off? Is it a business expense? I know a lot of companies don't really care to "donate" for various reasons, am wondering why your company is so willing when it is not required.

Maybe LE should set up subscriptions for some small service (priority support?), just to give companies a deductible reason to donate.

This. Everything is easier with an invoice; Accountants and tax inspectors are always suspicious about donations with only an email as a confirmation. It's a point patio11 already made in the past about OSS.

It sounds like your company should be the ones donating! Kudos to you either way and I agree, with how easy this has become compared to other solutions I have no problem donating to them.

That's the great part, my company matches my donation!

I fully agree, which is why I set up a recurring donation for what I would otherwise pay to some commercial certificate authority. LetsEncrypt is doing great work!

What's crazy to me is that their crowdfunding campaign [1] has only raised $100K so far, considering what they're doing.

1: https://www.generosity.com/community-fundraising/make-a-more...

Which Go package do you use?

You can probably get pretty far with the package written by Russ Cox:


Sorry just saw this, it's the autocert package bradfitz linked to.

It sounds like everything is running fantastically for them, and I'm really glad.

LE has saved us from spending many man hours of time updating certificates across all dev, staging, and live machines across all of our servers every year (which just so happens to be almost exactly the amount of time needed to forget some of the details of what needs to be done...).

But all that being said, when are we going to see a competitor pop up? Clearly what they are doing is working, so when are we gonna see some others attempt to do this? Having all your eggs in one basket is never a good thing in any part of life (no matter how perfect that basket is).

Having more than one "Let' Encrypt" would at the very least spread out some of the risk, and might even enable them to specialize a bit more (perhaps the competitor could target the issue of wildcard certs, or be somehow tailored for the use case of needing thousands of subdomains).

Has there been anyone else trying this?

I agree, for two reasons:

1) Let's Encrypt are based in the United States and are already forbidden from issuing domains to certain people[0] due to US law.

2) Having a separate production implementation of an ACME-compliant system would help make sure that the protocol is as robust as it can be

[0] Notably Iran and Syria - several certificates issued for gov.[ir|sy] had to be revoked after they slipped past their blocklist: https://community.letsencrypt.org/t/blocklist-incident-novem...

Just to be clear, Let's Encrypt does issue for non-governmental entities in U.S.-sanctioned countries (which some other U.S.-based CAs don't do).

https://crt.sh/?Identity=%25.sy&iCAID=16418 https://crt.sh/?Identity=%25.cu&iCAID=16418 https://crt.sh/?Identity=%25.sd&iCAID=16418 https://crt.sh/?Identity=%25.ir&iCAID=16418

LE arose from a EFF/Mozilla effort to get encryption everywhere, an aim that obviously is close to the EFFs mission.

What would be the motivation for a competitor?

Wildcard certificates, long-life server certs, and signed client certificates. There's a lot of other stuff that LE doesn't handle, too.

I don't think 'competitor' is the right word here -- maybe 'second basket so all our eggs aren't in one'.

I agree with the eggs/basket argument, though I suppose there's an argument to be made about a number of CAs being essentially too big to fail already, so what's one more?

Regarding client certificates: There aren't really many good reasons to use publicly-trusted certificates for client authentication, but if you insist, you can use Let's Encrypt for that. The certificates do have the id-kp-ClientAuth EKU.

I think it would be nice to move toward having a lot of medium-sized nonprofit CAs instead of a handful of crappy commercial ones, which is the current situation.

"Too big to fail" is the problem with the current CA system, and today's well-run TBTFCA is tomorrow's global security crisis.

When I think "mission critical audited security practices", non-profits don't exactly come to mind.

Oh, but Comodo does? Good luck.

A small sample does not generalize to a trend.

OMG yes on wildcard certs! My company has multiple domains and uses subdomains for every affiliate and we have thousands of affiliates. One *.example.com cert per domain and we're good to go. Now if only we could get IIS to support multi-domain wildcard certs so we could get all of our domains and subdomains under one master cert I'd be in heaven! (SNI doesn't work for us b/c ~12% of our traffic still uses IE7 or earlier).

So why not buy one now? I get the excitement about simple certification process, free access and refresh, etc. But if you have thousands of affiliates, current wildcard cert providers should offer a pretty good solution. Is anything missing there? I mean, if we ignore the idea why LE is good in general, $100 / year is nothing if you actually need a wildcard.

Oh we absolutely do just buy them now through RapidSSL. It's all of those other reasons I wish LE supported them. I wouldn't mind paying LE for them, I want an API for requesting them, a simpler certification process, and easier refreshes.

I don't get the desire for longer-life certs. I would argue that they should be shorter to keep the exposure of a leaked cert down. Whether a cert is good for a week or a year you should be automating the renewal.

basically no 3rd party system is designed to execute programs to obtain new certs when they expire. so can't use LE for existing workflows.

Same as EFF/Mozilla. Let's Encrypt hasn't fulfilled their goal until everyone can get free HTTP encryption.

As a user, if I have to wait 24 hours (or more, depending on queue depth) for a Let's Encrypt batch queue to be processed after I sign up for some free blogging platform before I can use an assigned subdomain, then I'm probably going to close my tab and never come back. Let's Encrypt hasn't fulfilled its goal until this doesn't happen any more. This batch queuing model is necessary so that sites don't exceed the Let's Encrypt daily quota.

Some applications rely on wildcard subdomains, and require a wildcard certificate to be instantly responsive.

To anyone thinking "just don't use encryption until after the cert has been provisioned"—not going to work if you use HSTS. Your users have to wait all day before they can use their subdomain.

This sounds more like a design decision by that blogging platform rather than something that's caused by Let's Encrypt. Excluding maintenance windows or any other unplanned downtime or performance issues (which happen relatively rarely), the issuance process doesn't take anywhere near close to 24 hours. Account registration, domain validation and certificate issuance is typically done in less than ten seconds.

The existing rate limits[1] should have very little effect even for very large integrators. A form for rate limit adjustments exists for those who need a large number of subdomains (and would rather not obtain a wildcard certificate) or need to add new domains at a very high rate (i.e. the WordPress.com's and OVH's of this world).

[1]: https://letsencrypt.org/docs/rate-limits/

Edit: The document you linked to was recently updated, but the top of the page incorrectly says "Last updated: August 10, 2016". I wrote my response with the old document in mind. It's obvious to me now that this page was actually last updated in December 2016.

If I don't batch multiple SANs into one certificate and stagger a certificate queue, I will very quickly run into the Let's Encrypt rate limit.

If I don't want my users to wait for the queue to be processed, I could immediately request a new certificate for every new user's subdomain, but then I'd be limited to 10 new users every 3 hours.

I assume by "multiple SANs", you're referring to subdomains under the same registered domain? In that case, you can use the rate limit adjustment form or register your domain as a public suffix if that's more appropriate. The form has been available since August. The rate limits in general have not changed since back then (or even before, I don't recall) either.

Why do any non-profits pop up?

Obviously LE employs a handful of people, and they are in some ways an "advertisement" for Mozilla (not that it's a bad thing). Those alone are some reasons why something might want to be attempted.

But I'm not necessarily thinking of a standalone "free certificate company" but maybe more of a "bonus" to some other product or service.

Think something like a domain host providing certificates themselves (which IMO makes a hell of a lot of sense).

> But I'm not necessarily thinking of a standalone "free certificate company" but maybe more of a "bonus" to some other product or service.

This is what I expect we'll see more of, rather than a second (and perhaps slightly different) Let's Encrypt. Major cloud providers will probably add their own variants of what Amazon offers with AWS Certificate Manager (ACM); more CDNs will start offering one-click SSL (like Cloudflare); "traditional" web hosting providers and control panel vendors will (hopefully) support SSL by default (like cPanel with AutoSSL, which supports Comodo and Let's Encrypt).

Yeah, and I'm also hoping they will gravitate toward more "standard" interfaces like you touched on at the end there.

With the help of Let's Encrypt and through some cooperation, we could make easily "pluggable" SSL cert providers where you can choose who you want with the click of a button.

I think it's fairly likely we'll see a number of CAs adding ACME support at some point. Judging by participation on the ACME mailing list, there seems to be interest from (at the very least) DigiCert, Entrust and cough StartSSL. I guess most of them will want to wait for the standardization process to finish before announcing any plans.

CloudFlare creates certs as part of its service.

> LE has saved us from spending many man hours of time updating certificates

Just out of interest, how are you managing the 90-day renewal schedule? Don't you need some means of verifying that timely renewal has occurred.

Since you mention dev and staging I assume you've implemented a central certificate-management server that talks with LE and then issues the certs to the internal machines?

Use cert bot to auto renew https://certbot.eff.org/docs/using.html#renewing-certificate...

Also include command like below as part of your automated audit scripts:

echo | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -dates


FYI, you can simplify that to

openssl s_client -connect google.com:443 </dev/null 2>&1 | openssl x509 -noout -enddate

> Just out of interest, how are you managing the 90-day renewal schedule?

Not the parent, but I use certbot running monthly with a cron job. It skips any domains that aren't up for renewal, and renews domains when they are close to expiry.

I then get a monthly email telling me which domains were updated and which ones were skipped.

It's completely painless. 90-day renewal isn't a problem when the whole process is completely automated.

I would (and do) run it weekly.

If it runs monthly, and one of your renewals fails (i.e. transient network error), your certificate may expire before it next gets the opportunity to renew it.

And then I get an email from cron telling me it failed, and I log in and run certbot manually.

I don't run enough sites that this is a problem.

No, we tend to keep our staging and dev servers public-facing for the most part. We do a lot of remote work, and it's easier that way.

Everything is kept behind our application authentication, and they almost never have "real data" on them so it's not really an issue for us. And having the certs on the dev machines just makes setting up and testing with HTTPS that much easier and it's a no-brainer with LE (plus it lets us ensure that everything there is working correctly, and gives us fully authenticated HTTPS connections with our dev servers!)

In the rare event that we need a dev server and can't put it behind our application auth, it's generally locked to localhost and we use SSH forwarding until it can be.

As for managing the lifetimes, we just use certbot the same as we do for the production machines, similar to the way the other commenter pointed out. And I believe one of our guys has some alerts setup for monitoring the expiration of the certs and warning if it gets too close to expiring, but I don't really know anything about how that works.

Presumably, you would want to have monitoring in place for certificate expiration either way, so this expense is not really specific to short-lived certificates.

StartCom (the name behind StartSSL launched StartAPI/StartPKI in May. I would call it a direct competitor to LetsEncrypt.

That's what StartCom might thought when they announced their new service "Start Encrypt" around the same time when Comodo tried to get hold of the "Let's Encrypt" trademark which Let's Encrypt successfully fought back.[0] Then some more deserved buckets of shit hit their fan. I can't bring myself to call StartCom a competitor of Let's Encrypt.

[0] https://news.ycombinator.com/item?id=11961034

Given the recent events regarding them and their parent company, I'd be wary of using them for anything at this point.

Even if you wanted to, you can't really use them right now. Mozilla, Google, and Apple untrusted their (recently issued) certs.

Let's Encrypt + widespread SNI adoption is making it dead easy for SaaS companies like ours to host customer content on customer chosen domains. So their existence doesn't just help the technically proficient -- the "long tail" of websites published through various platforms will start seeing HTTPS as a default. And that's very much a good thing. For example, there should be no reason for publication platforms (like say Medium to pick on an example) to have such complicated custom domain + SSL configurations in the future.

The next step I'd like to see is all the $5 shared hosts supporting HTTPS by default via something like Let's Encrypt. There's really no excuse anymore.

BTW, shameless plug: We've found this process so easy that we've spun a side project out of our main SaaS project called clearalias.com. It's basically a Let's Encrypt proxy that makes it even easier to publish customer content via custom domains secured with HTTPS.

They already do; cPanel supports native LE https://documentation.cpanel.net/display/CKB/The+Let's+Encry...

> The next step I'd like to see is all the $5 shared hosts supporting HTTPS by default via something like Let's Encrypt. There's really no excuse anymore.

Excellent point. I can see Lets Encrypt turn into one of those crucial infrastructure providers (similar to square/stripe/paypal for payments) but for https

Love LE. I've got people who didn't even know about TLS to use it as a matter of course, they now see it as a badge of honour to pass the ssllabs tests with an A+. They've changed the internet for the better.

I got an F.

I should probably update things.

How the hell did you get an F? Do you not have SSL at all?

I ran into something similar. In my case, it was due to nginx running with an old (vulnerable) version of openssl.

Old version of OpenSSL. Still vulnerable to padding attack.

The fact that these certificates are free and the fact that it's so easy to use has enabled me to move almost all of my websites to https. A project like this really is moving the web forward.

Honest question: is there a catch?

Why do all the other CAs cost so much and take so long when the actual cert is generated in seconds?

Isn't that how it's supposed to work and LE is breaking the rules, thus living on borrowed time?

If it was possible to be so easy why no else did it? What is the secret ingredient?

It depends on the level of certification done. If you are getting a regular SSL cert you only need to prove ownership of the domain, which can be automated easily and requires no human work. However EV(Extended Validation)[0] certificates involve a lot more due diligence on the part of the issuer. EV certs require validation of the legal entity behind the domain and this is requires work to be done by a human.

AFAIK the cost of previous SSL certs have been largely artificial. Obviously running servers and paying staff to keep an automated process in place isn't free, but I recon the cost has always been inflated quite a bit. There's also an artificial scarcity introduced because not everyone can start a CA and getting a root certificated trusted is non trivial. Let's Encrypt is sponsored so they do make some money, but this allows them to issue certs for free.

0: https://en.wikipedia.org/wiki/Extended_Validation_Certificat...

> Why do all the other CAs cost so much and take so long when the actual cert is generated in seconds?

I guess "so much" should be put in perspective: Domain Validation certificates, like the ones Let's Encrypt issue, are not really expensive - resellers typically offer them for something like $10/year. The more expensive certificates - OV and EV - involve some degree of manual verification of the information on the certificate (such as the company name). That's a large part of the cost.

But yeah, commercial CAs are (were?) money printing machines. Running Let's Encrypt costs about $3M/year, and they support >20M active certificates. Commercial CAs are going to have some marketing and support expenses, but the rest would be profit.

> Isn't that how it's supposed to work and LE is breaking the rules, thus living on borrowed time?

All CAs (should) follow the same set of rules - the Baseline Requirements. Let's Encrypt has had a pretty good track record so far - definitely better than some of the big commercial CAs like Symantec or Comodo.

> If it was possible to be so easy why no else did it? What is the secret ingredient?

To be fair, they were not the first free CA - both StartSSL and WoSign offered free DV certificates (for non-commercial usage). Not the best examples, I suppose.

Cloudflare offered free SSL (via Comodo) for their customers as well, as does cPanel via AutoSSL It's definitely viable, just took some time for people to care enough about encrypting the web to make it happen.

> But yeah, commercial CAs are (were?) money printing machines.

Which is how we got Canonical/Ubuntu (and how Shuttleworth could afford to be a space tourist):


It takes a lot of work and isn't something someone in their college dorm room can make. It takes industry contacts, specialized skills, and solid marketing to build a network and trust in the system. To do this for nonprofit is a sacrifice when the people with these skills could be chasing big money. LE is a good example of the tech community doing something that probably a government agency should be doing with tax dollars to support the industry. Private sector altruism.

Well, it captures the niche target userbase that would otherwise self-sign a certificate to protect the channel. It's a lot easier to push Lets Encrypt for the master keys, than go after N people that would go through the trouble to generate a self signed cert to secure the channel.

Why do banknotes costs so much? It's just a stupid paper made up of cotton with ink on top.

Because some agencies have the monopole to print them and they've made it very difficult for anyone else to get into that printing business and it turns out that that product is valuable to a lot of people and they're willing to assign a lot of money to it.

Somewhat related: https://www.eff.org/deeplinks/2016/12/https-deployment-growi... (my post on HTTPS deployment improvements during 2016, a whole lot of which involved Let's Encrypt)

My experience with Let's Encrypt hasn't been great, but that's not LE's fault. Long story short, don't use Namecheap, at the very least not their shared servers.

From their support:

"Though we believe increased web security is a good thing, we also think that using certificates from free providers can get more risk and uncertainty into your business. Additionally, we would like to draw your attention to several disadvantages and drawbacks of Let's Encrypt certificates:

1. No OV/EV support or possibility (no possibility to issue a certificate with medium or high assurance and user trust level);

2. Insufficient level of domain validation and the absence of brand validation ( All publicly trusted CAs are flagging the certificate containing IT, financial and other public words, brands etc for additional security checks, which is not applicable for LE.)

3. Short validity period (for LE certificates - only 90 days, for all trusted certificate provides - up to 39 months).

Since the nature of shared and reseller hosting implies having a significant number of independent customers' accounts on the same server instance, we cannot put at risk our other clients by enabling not fully secure technology.

These and other concerns (for example the fact that ACME-script for Let's Encrypt requires root access and is able to overwrite server configs) make us refrain from supporting Let's Encrypt on our shared servers. We hope for your kind understanding on the matter."


Feel free to reply with other hosts that don't support LE, so I can avoid them (and hopefully others too!)

"These and other concerns (for example the fact that ACME-script for Let's Encrypt requires root access and is able to overwrite server configs) make us refrain from supporting Let's Encrypt on our shared servers. We hope for your kind understanding on the matter."

This is one of the problems I've had with LE, and the community defends it by saying that there are other tools, and forks of tools you can use, when the problem with those is that they could easily go out of date if LE changes anything and they'd never be fixed. Updating your certificates needs to be done in a reliable and contained manner, but nobody wanted to admit that LE tools doesn't do that.

I don't recommend LE unless you're actively maintaining a server and can invest the time into creating your own contained update script. I know hosters like Dreamhost have it built in and will auto-update for you, which is nice.

I can't think of a single person or entity that has a reason to dislike LE (except for the for-profit certificate companies, maybe).

We live in a world where people take strong and increasingly indecipherable stances on the things they know almost nothing about.

There are unpaid supporters for three-letter agencies who have made moves to ban encryption. With LE anyone can obtain a certificate and set up an in-memory ephemeral message board that uses "unbreakable encryption." I don't know of any people who would be able to explain how to implement cryptography actually taking this stance.

There are apologists for the rent-seeking behaviour of academic journals, usually ill-informed (wrongly assuming that editing and peer review are not volunteer positions) and repeating arguments verbatim from those on the payroll that happen to resonate with whatever political line they follow. Still, they themselves are not on the payroll.

I can imagine, given sufficient technical knowledge or an article aimed a mass audience, certain pro-market contrarians could definitely find reason to hate this. Maybe even twice.

If you're genuinely pro-market, you should have no problem with an industry that pools funds to mitigate rent-seeking behaviours of an oligopoly, reduce the cost of a product for which there is no substitute and increase utilisation of other resources.

People who want to eavesdrop on your HTTP connections.

btw there if you are not totally comfortable with certbot, there is a free monitoring service at https://letsmonitor.org

That's a bit odd. "It’s completely free." vs. "Register for a LetsMonitor.org Free Trial"

Which is it?

Is there a list of major B2B and eCommerce sites using LE for their primary customer facing sites? This would be useful if our customers brought it up.

Are there any plans or water-cooler discussions around supporting wildcard or multi-sub-domain SAN wildcard certs?

> Is there a list of major B2B and eCommerce sites using LE for their primary customer facing sites? This would be useful if our customers brought it up.

W3Techs[1] is generally a good source for this kind of information. Themeforest seems to be using them, for example. (Certificates issued by Let's Encrypt are counted under the IdenTrust root on W3Tech, since that's the CA that cross-signed Let's Encrypt.) Generally speaking, they get used on low-traffic sites (compared to the other major CAs), but that's not really surprising.

[1]: https://w3techs.com/technologies/details/sc-identrust/all/al...

I had not seen that site before, thank you! I will keep an eye on the popular sites using IdenTrust.

If you're interested in getting better idea of where LE is being used and under what configurations this may be useful:


Still no official client for IIS. Maybe in 2017!

What does "y" mean on the graph labels?

I'm going to go with "y axis" but it's just a guess.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact