10 Years of Let's Encrypt

Posted by SGran 12 hours ago

Counter595Comment252OpenOriginal

Comments

Comment by jjice 11 hours ago

Let's Encrypt was _huge_ in making it's absurd to not have TLS and now we (I, at least) take it for granted because it's just the baseline for any website I build. Incredible, free service that helped make the web a more secure place. What a wonderful service - thank you to the entire team.

The CEO at my last company (2022) refused to use Let's Encrypt because "it looked cheap to customers". That is absurd to me because 1), it's (and was at the time) the largest certificate authority in the world, and 2) I've never seen someone care about who issued your cert on a sales call. It coming from GoDaddy is not a selling point...

So my question: has anyone actually commented to you in a negative way about using Let's Encrypt? I couldn't imagine, but curious on others' experiences.

Comment by btown 11 hours ago

To be fair, for a CEO in 2022, EV certificates had only lost their special visualizations since September/October 2019 with Chrome 77 and Firefox 70 - and with all that would happen in the following months, one could be forgiven for not adapting to new browser best practices!

https://www.troyhunt.com/extended-validation-certificates-ar...

Comment by charlesbarbier 10 hours ago

It was a red herring the entire time. At Shopify we made experiment regarding conversion between regular certs and EV before they stop being displayed and there was no significant difference. The users don't notice the absence of the fancier green lock.

Comment by bruce511 3 hours ago

I think the rebuttal to the CEO today is really very simple.

a) How many of the sites you visit everyday have DV and how many have EV certificates?

b) Name any site at all, that you have visited, where your behavior or opinion has changed because of the certificate?

In truth the green-bar thing disappeared on mobile long before desktop (and in some cases it was never present.)

In truth if you polled all the company staff, or crumbs just the people round the boardroom table (probably including the person complaining) a rounding error from 0 could show you how to even determine if a cert was DV or EV.

EV could have an inspector literally visit your place of business, and it would still have no value because EVs are invisible to site visitors.

Comment by yabones 11 hours ago

Call me old-school, but I really liked how EV certs looked in the browser. Same with the big green lock icon Firefox used to have. I know it's all theatrics at best and a scam at worst, but I really feel like it's a bit of a downgrade.

Comment by gerdesj 5 hours ago

"it's all theatrics at best"

Only IT understand any of this SSL/TLS stuff and we screwed up the messaging. The message has always been somewhat muddled and that will never work efficiently.

Comment by woleium 8 hours ago

it’s okay, the scam continues with BIMI

Comment by wnevets 10 hours ago

> Call me old-school, but I really liked how EV certs looked in the browser.

I agree, making EV Certs visually more important makes sense to people who know what it means and what it doesn't. Too bad they never made it an optional setting.

Comment by RonanSoleste 10 hours ago

When you request an EV. They call you by the phone number that you give to ask if you requested a certificate. That was the complete extend of the validation. I could be a scammer with a specificity designed domain name and they would just accept it, no questions asked.

Comment by Uvix 10 hours ago

Depends on the registrar. Globalsign required the phone number to be one publicly listed for the company in some business registry (I forget exactly which one), so it had to be someone in our main corporate office who'd deal with them on the phone.

Comment by bangaladore 10 hours ago

For an online business in a dubious (but legal) domain, my co-owner spent a few hundred bucks registering a business in New Mexico with a registered agent to get an EV cert.

So, a barrier to entry, but not much of one.

Comment by invokestatic 6 hours ago

I have an almost identical story except the state in question was Nevada. I’m curious what “dubious” domain it was, for me it was video game cheats. Maybe I’m actually the co-owner you’re talking about. :)

Comment by dale-cooper 4 hours ago

This made me curious. Like selling cheats for games?

Comment by bangaladore 4 hours ago

Yes, both in the case of them and I.

Comment by progmetaldev 6 hours ago

Dun and Bradstreet (?). I believe I'm remembering this correctly. I still deal with a few financial institutions that insist on using an EV SSL certificate on their websites. I may be wrong, but I believe that having an EV SSL gives a larger insurance dollar amount should the security be compromised from the EV certificate (although I imagine it would be nearly impossible to prove).

When I last reissued an EV SSL (recently), I had to create a CNAME record to prove domain ownership, as well as provide the financial institution's CEO's information which they matched up with Dun & Bradstreet and called to confirm. The entire process took about three days to complete.

Comment by pests 5 hours ago

Still required for Apple Dev account last time I had to go through the process a few years ago

Comment by wnevets 10 hours ago

> In addition to all of the authentication steps CAs take for DV and OV certificates, EV certificates require vetting of the business organization’s operational existence, physical address and a telephone call to verify the employment status of the requestor. [1]

[1] https://www.digicert.com/difference-between-dv-ov-and-ev-ssl...

Tying a phone number to a physical address and company is a lot more useful than just proof of control over a domain. Of course its not 100% fool proof and depends on the quality of the CA but still very useful.

Comment by matrss 10 hours ago

> Tying a phone number to a physical address and company is a lot more useful than just proof of control over a domain.

It might be useful in some cases, but it is never any more secure than domain validation. Which is why browsers don't treat it in a special way anymore, but if you want you can still get EV certificates.

Comment by monerozcash 9 hours ago

It was easy to provide the information for an existing business you're completely unrelated to. Reliably verifying that a person actually represents a company isn't possible in most of the world.

Comment by fpoling 9 hours ago

Many countries has official register of companies with at least post box address. Requiring to answer a physical letter sent to an address from the central register will be much more reliable.

Comment by monerozcash 7 hours ago

Sure, and then someone just registers a company with the exact same name in another jurisdiction and EV is thwarted anyway

Comment by AlbinoDrought 8 hours ago

I'd love a referral to your certificate authority and rep - we go through a big kerfluffle each renewal period, only eventually receiving the certificate after a long exchange of government docs and CPA letters. For us, only the last step is the phonecall like you say.

Comment by wnevets 8 hours ago

The replies to my original comment make it obvious who has gotten an EV cert from a quality CA before and who hasn't.

Comment by BHSPitMonkey 7 hours ago

This exchange seemingly proves the argument that user trust gained from the EV treatment is misplaced, and that the endeavor was a farce all along. It's not as though the user's browser was distinguishing the good CAs from the bad!

Comment by wnevets 6 hours ago

I disagree. I specifically said in my original comment they were very useful for those that knew what EV certs were and EV certs weren't.

You may not know that Digicert is a quality CA who wasn't going to risk their position as a CA to sign an EV cert for a typo squatting phishing site pretending to be PayPal but there are those who do. The green UI in chrome & firefox made finding all of this information out incredibly simple and obvious.

Comment by brians 9 hours ago

Having run an EV issuing practice… they were required to contact you at a D&B listed number or address.

Comment by realityking 10 hours ago

EV certs also showed the legal name of the company that requested the certificate - that was an advantage.

Comment by duskwuff 9 hours ago

Which would have made sense if company names were unique - which they aren't. See e.g. https://groups.google.com/g/mozilla.dev.security.policy/c/Nj... for an example of how this was abused.

Comment by wbl 7 hours ago

It was used correctly. What CAs wanted to sell wasn't something browsers wanted to support, and EV was the compromise. It just happens that what EV meant wasn't that useful irl.

Comment by crote 7 hours ago

What's the alternative, showing the company's unique registration ID?

CAs invented EVs because the wanted to sell something which could make them more money than DVs. The fact that company names aren't unique means that the whole concept was fundamentally flawed from the start: there is no identifier which is both human-readable and guaranteed to uniquely identify an entity. They wanted to sell something which can't exist. The closest thing we have got is... domain names.

Comment by duskwuff 4 hours ago

The alternative would have been to have the CA use human judgement when approving EV certificates and reject applications from organizations whose names shadowed better-known firms, or to only accept applications from a select set of organizations (like, say, banks). But either of those possibilities would have increased the cost of the program and limited the pool of applicants, so CAs chose the cheap, easy path which led to EV certificates becoming meaningless.

Comment by crote 7 hours ago

The problem is that people wrongly believe that company names are unique. In reality you're just some paperwork and a token registration fee away from a name clash.

If anything, it's a disadvantage. People are going to be less cautious about things like the website's domain name if they see a familiar-sounding company name in that green bar. "stripe-payment.com" instead of "stripe.com"? Well, the EV says "Stripe, Inc.", so surely you're on the right website and it is totally safe to enter your credentials...

Comment by dismantlethesun 5 hours ago

In many countries, company names are unique to that country. And combined with country TLDs controlled by the nation-state itself, it'd be possible for at least barclays.co.uk to be provably owned by the UK bank itself when a EV cert is presented by the domain.

In the US though, every state has it's own registry, and names overlap without the power of trademark protection applying to markets your company is not in.

Comment by arccy 10 hours ago

i think the point was that EV didn't actually mean anything because the checks were too loose. it's a feel good false sense of security

Comment by smurda 8 hours ago

I loved the visualization of EV certs in browsers, but in 2014 vendors like GoDaddy charged $100/yr for them. https://web.archive.org/web/20131023033903/http://www.godadd...

I'm glad LE, browsers, and others like Cloudflare brought this cost to $0. Eliminating this unnecessary cost is good for the internet.

Comment by unethical_ban 10 hours ago

EV validated not only that a domain was under control of the server requesting the cert, but that the domain was under control of the entity claiming it.

I kind of wish they still had it, and I kind of wish browsers indicated that a cert was signed by a global CA (real cert store trusted by the browsers) or an aftermarket CA, so people can see that their stuff is being decrypted by their company.

Comment by tadfisher 10 hours ago

Problem is, I can easily set up a company and get an EV cert for "FooBar Technologies, LLC" and phish customers looking for "FooBar Incorporated" or "International FooBar Corp.". Approximately zero users know the actual entity name of the real FooBar.

Comment by btown 4 hours ago

BIMI, as misguided as it is, does aim to solve this by tying registration to insanely high prices and government-registered trademark verification. You would have a hard time registering the Stripe trademark nowadays in a way that would get you a BIMI certificate for that name/logo.

https://www.thesslstore.com/resources/bimi-certificate-cost-...

But I'm glad that it hasn't caught on as strongly-expected by the public (or even commonly used). Big brands shouldn't be able to buy their way into inbox placement in ways that smaller companies can't replicate.

Comment by matrss 10 hours ago

Even if the users knew exactly what the name of the entity whose website they wanted to visit was: that name is not unique, as is shown by the "Stripe, Inc" example in the parents linked blog post.

Comment by arccy 10 hours ago

you can find quite of few examples online that the entity check wasn't all that strict...

Comment by merpkz 2 hours ago

I have also heard a negative about it being somehow "cheap" and we can "afford" a proper wildcard for our website from managers back in the day, like, few years ago. Never mind the hours wasted every year changing that certificate in every system out there and always forgetting a few.

Also a valid point from security people is that you leak your internal hostnames to certificate transparency lists once you get a cert for your "internal-service.example.com" and every bot in existence will know about it and try to poke it.

I solved these problems by just not working with people like that anymore and also getting a wildcard Let's Encrypt it certificate for every little service hosted - *.example.com and not thinking about something being on the list anymore.

Comment by qwertox 11 hours ago

I once notified Porsche that one of their websites had an expired certificate, they fixed it within a couple of hours by using Let's Encrypt. It surprised me.

Let's Encrypt is to the internet what SSDs are to the PC. A level up.

Comment by quesera 11 hours ago

There was a time when EV certificates were considered more trustworthy than DV certs. Browsers used to show an indication for EV certs.

Those days are long gone, and I'm not completely sure how I feel about it. I hated the EV renewal/rotation process, so definitely a win on the day-to-day scale, but I still feel like something was lost in the transition.

Comment by hk1337 5 hours ago

This was the only objection I had gotten about using letsencrypt 6 years ago but that guy is gone and now we either have letsencrypt or AWS certificates

Comment by trueismywork 11 hours ago

What about OV?

Comment by ekr____ 11 hours ago

It's never been clear to me what the rationale for OV was, as the UI wasn't even different like EV was.

Comment by quesera 11 hours ago

I've never seen (noticed) an OV cert in real life, and no business I've ever been responsible for pushed for OV over DV. It was always EV or "huh?"

Comment by bostik 11 hours ago

I think I've seen one or two, and only because I noticed them as a weird callout in a $LARGE_FINANCE_INSTITUTION infosec bingo sheet. Of course I had to check that they really were running with OV certs.

Some of the outfits in that space will be heavily hit by the shortening certificate max-lifetimes, and I do hope that the insurance companies at some point also stop demanding a cert rotation before 90 days to expiry. It's a weird feeling to redline a corporate insurance policy when their standard requirements are 15 years out of date.

Comment by quesera 10 hours ago

> when their standard requirements are 15 years out of date

I swear half of my "compensating control" responses are just extended versions of "policy requirement is outdated or was always bad".

Comment by crote 7 hours ago

> I do hope that the insurance companies at some point also stop demanding a cert rotation before 90 days to expiry

It's not like you have a lot of choices when certificates are only valid for 47 days in 2029!

Comment by Sesse__ 11 hours ago

Before LE, we did lots of OV (which you generally could get a couple of for free from somewhere). We had to dig up stuff like a heating bill, because evidently that is proof of organizational control to some people.

Comment by johnebgd 11 hours ago

There are extended certificates that did matter in our sales process for some hosted solutions back about 15 years ago if I recall right… no one has ever cared since…

Comment by rokkamokka 11 hours ago

No! Let's encrypt is easily the best thing that's happened for a secure internet the last 10 years.

Comment by hk1337 5 hours ago

The only pain point I had using letsencrypt, and it wasn 100% not their fault, was I tried using it to generate the certificate to use with FTPS authentication with a vendor. Since LE expires every 90 days and the vendor emails you every week when you’re 2 months from expiring, that became a pain point and it wasn’t easier to just by a 1 or 2 year cert from godaddy. Thank goodness that vendor moved to sftp with key authentication so none of that is needed anymore

Comment by winternett 7 hours ago

Many host providers (Those acquired by companies like Web.Com, allegedly) disable all ability to use outside certs since Google made encryption a requirement in Chrome Browser...

They do things like blocking containers & SSH to make installing free certs impossible.

They also have elevated the price of their own certs (that they can conveniently provide) to ridiculous prices in contrast to free certs their customers can't even use...

It would be a huge price-fixing scandal if Congress had any idea of how technology works.

Comment by Sohcahtoa82 6 hours ago

There are literally thousands of web hosts out there. If your web host is doing something shitty like that, it's trivial to find a new one.

Comment by winternett 2 hours ago

I'd be happy to hear about a traditional hosting company that allows clients to install lets Encrypt certs if you can name any...

Most of my clients don't have budgets big enough for cloud hosting.

Comment by selcuka 4 hours ago

> It would be a huge price-fixing scandal if Congress had any idea of how technology works.

It's shady, but technically not price-fixing unless they are a monopoly. You are free to take your business to somewhere else.

Comment by winternett 2 hours ago

If you read into Web.Com, yes, they are quickly becoming a monopoly on host companies. They do not disclose many of the hosting companies they now own.

If you can find a company that allows clients to install Let's Encrypt Certs on shared hosting, please let me know.

Comment by selcuka 1 hour ago

Yeah, fair point. I have not used shared hosting for a long time now (static sites are easy/free to host, and dynamic ones don't play well with shared hosting), so I didn't know the Web.com story.

I used DreamHost in the past and they had a configuration option in their control panel to automatically install and maintain a Let's Encrypt certificate on your behalf [1]. If you are stuck with Web.com you may consider using a reverse proxy/CDN such as CloudFlare.

[1] https://help.dreamhost.com/hc/en-us/articles/216539548-Addin...

Comment by rkagerer 2 hours ago

Old browsers on old hardware without its CA baked in.

Comment by xxmarkuski 10 hours ago

I have heard, but do not aggree, that Let‘s Encrypt is risky, because phishing sites use it. It’s implied that other CAs do checks against it.

Comment by selcuka 4 hours ago

An SSL provider once refused to sell me a certificate because the domain name had the word "Windows" in it.

Comment by anonymars 10 hours ago

I will say, I have never before this season seen so many seemingly-legit fake web stores. All with their little lock icons in the address bar. I assume LLMs helped kick it into overdrive too

Comment by array_key_first 7 hours ago

Conflating transport-layer encryption with authenticity is the problem. The former should always be standard, the latter is unrelated and IMO needs a different mechanism.

Comment by kbolino 5 hours ago

Absent widespread adoption of DNSSEC, which has just not happened at all, I don't see any alternative.

The authentication must be done before the encryption parameters are negotiated, in order to protect against man-in-the-middle attacks. There must be some continuity between the two as well, since the authenticated party (both parties can be authenticated, but only one has to be) must digitally sign its parameters.

Any competing authentication scheme would therefore have to operate at a lower layer with even more fundamental infrastructure, and the only thing we've really got that fits the bill is DNS.

EDIT: A standard exists for this already, it's called DANE, though it has very little support: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

Comment by anonymars 3 hours ago

This applies to grandparent too (for the record I largely agree with them) but the issue isn't just "authenticity" but "identification" -- there's no real attestation about who is in on the other end of the site. This identity was once at least somewhat part of the certificate itself.

Comment by kbolino 3 hours ago

Yes, it is fair to say that domain names are not the sum total of identity. However, the EV certificate experience showed that, at least in terms of WebPKI and the open Internet, there really isn't anything better than domains yet.

We have clear and seemingly easy go-to examples like proving that yes, this is THE Microsoft, and not a shady fly-by-night spoof in a non-extradition territory, but apart from the headline companies--who as of late seem to like changing their names anyway--this actually isn't easy at all.

Walled gardens like app stores have different trade-offs, admittedly.

Comment by Analemma_ 11 hours ago

I've seen people complain that Let's Encrypt is so easy that it's enabling the forced phaseout of long-lived certificates and unencrypted HTTP.

I sort of understand this, although it does feel like going "bcrypt is so easy to use it's enabling standards agencies to force me to use something newer than MD5". Like, yeah, once the secure way is sufficiently easy to use, we can then push everyone off the insecure way; that's how it's supposed to work.

Comment by mook 10 hours ago

Yeah, I hate how it made housing things locally without a proper domain name very difficult. My router _shouldn't_ have a globally recognized certificate, because it's not on a publicly visible host.

There's certainly advantages to easily available certificates, but that has enabled browsers and others to push too far; to be sure, though, that's not really a fault of Let's Encrypt, just the people who assume it's somehow globally applicable.

Comment by crapple8430 7 hours ago

A related issue is that most consumer devices (both iPhone and current Android) make it impossible or extremely difficult to trust your own root CA for signing such certs.

Comment by ingenium 2 hours ago

Android is pretty easy, you just add it to the keystore and that's it. I've had my own CA long before Let's Encrypt, but now mostly only use it for non-public devices that can't easily use Let's Encrypt (printers, switches, etc).

Comment by crapple8430 2 hours ago

You can add it to your user CA store, but no app will trust it since it's treated differently from the system CA store, which you can't modify without root or building your own ROM. In effect it is out of reach for most normal users, as well as people using security focused ROMs like Graphene, when ironically it can improve security in transit in many cases.

Comment by rplnt 8 hours ago

Random anecdote: I have a device in which the http client can't handle https. Runs out of memory and crashes. Wasn't able to find a free host with a public http to host a proxy.

Comment by cortesoft 8 hours ago

What is the device, if I may ask?

Comment by davidkwast 5 hours ago

This can happen too with Micropython on Esp8266

Comment by mschuster91 11 hours ago

> Like, yeah, once the secure way is sufficiently easy to use, we can then push everyone off the insecure way; that's how it's supposed to work.

The problem is that this requires work and validation, which no beancounter ever plans for. And the underlings have to do the work, but don't get extra time, so it has to be crammed in, condensing the workday even more. For hobbyist projects it's even worse.

That is why people are so pissed, there is absolutely zero control over what the large browser manufacturers decide on a whim. It's one thing if banks or Facebook or other truly large entities get to do work... but personal blogs and the likes?

Comment by crote 7 hours ago

We've reached a point where securing your hobby projects essentially means setting the "use_letsencrypt = true" config option in your web server. I bet configuring it takes less time than you spent reading this HN thread.

And with regards to the beancounters: that is exactly why the browsers are pushing for it. Most companies aren't willing time and effort into proper certificate handling procedures. The only way to get them to secure their shit is by forcing them: do it properly, or your website will go offline. And as it turns out, security magically gets a lot more attention when ignoring it has a clear and direct real-world impact.

Comment by bigstrat2003 6 hours ago

> That is why people are so pissed, there is absolutely zero control over what the large browser manufacturers decide on a whim. It's one thing if banks or Facebook or other truly large entities get to do work... but personal blogs and the likes?

Yep. There are plenty of things on the Internet for which TLS provides zero value. It is absolutely nonsensical to try to force them into using it, but the browser community is hell bent on making that bad decision. It is what it is.

Comment by nottorp 10 hours ago

> but personal blogs and the likes?

Yep, the result of the current security hysteria/theater is it makes it increasingly difficult to maintain an independent web presence.

Yes, I know, you can just use Cloudflare and depend on it...

Comment by Ferret7446 10 hours ago

TLS only takes a few minutes to add to a self hosted solution, just plop caddy in front of your server

Comment by eastbound 10 hours ago

Cloudflare uses HTTP to connect to your website before caching the content. I’ve always found it highly insecure. You could have HTTPS with Letsencrypt, but you need to deactivate Cloudflare when you want to renew (or use the other validation that is complex enough that I didn’t succeed to do it).

Comment by nottorp 8 hours ago

Don't pick on this particular SSL requirement, pick on the deluge of requirements that only make sense for a site that sells something or handles personal data (i.e. has accounts). They get extended to $RANDOM_SITE that only serves static text and the occasional cat photo for no good reason except "your cats will be more secure!".

Comment by ptsd_isv 7 hours ago

GP: At least on business plans this is incorrect, it defaults to (last time I checked) accepting any SSL certificate including self signed from edge to origin and it’s a low friction option to enforce either valid or provided CA/PubKey certs for the same path.

Parent: those innocuous cat photos are fine in the current political climate… “First they came for the cat pic viewers, but I did not speak up…”

Comment by nottorp 34 minutes ago

Wrong metaphor though?

How does SSL on a -ing public site protect you from being arrested by miniluv?

It’s public, you want everyone to see the cat photos, that’s why you set up the site. On the contrary, SSL certs mean another party through which miniluv can track you. They prove or are supposed to prove identity not hide it.

Comment by AnonC 5 hours ago

The statement that Cloudflare uses HTTP to connect to your website can be false depending on how you configure it. For years, I have had personal websites with Cloudflare as the CDN and with Let’s Encrypt providing certificates on the web server. All I do is choose Full (Strict) in the TLS settings on Cloudflare. So the connection between the end user to Cloudflare and from Cloudflare to my web server are on HTTPS. No deactivation of Cloudflare required on my end during renewal (my web host, like many others, has the certificate generation automated and getting a TLS certificate just a toggle on my admin dashboard).

Comment by foresto 10 hours ago

I can understand this in in certain contexts, such as a site that exists solely to post public information of no value to an attacker.

A local volunteer group that posts their event schedule to the web were compelled to take on the burden of https just to keep their site from being labeled as a potential threat. They don't have an IT department. They aren't tech people. The change multiplied the hassles of maintaining their site. To them, it is all additional cost with no practical benefit over what they had before.

Comment by cortesoft 8 hours ago

The work and technical expertise to setup let's encrypt is less than the work to register a domain, set up a web server, and configure DNS to point to it.

Comment by foresto 7 hours ago

You seem to have missed what I wrote in the first place: They aren't tech people.

It is additional work, and requires additional knowledge.

It was also not available from most of the free web hosts that sites like these used before the https push. So investigating alternatives and migrating were required. In other words, still more work.

Comment by charcircuit 9 hours ago

This is why more and more organizations get away with only having social media pages where they don't have to worry about security or other technical issues.

Comment by foresto 9 hours ago

Unfortunately, placing the information on a social media page burdens the people seeking it with either submitting to the social media site's policies and practices, or else not having access to it. This is not a good substitute.

It also contributes to the centralization of the web, placing more information under the control of large gatekeepers, and as a side effect, giving those gatekeepers even more influence.

Comment by charcircuit 7 hours ago

Most social media are free and easy to sign up for taking under a minute to do and have user bases that can be measured in the billions. Most people in the world are willing to follow the rules.

Most people don't use social media via the web. They use it via dedicated apps. I think it's natural that people who don't want to deal with the tech side of things will outsource it to someone else. The idea that everyone will host their own tech is unrealistic.

Comment by tialaramex 7 hours ago

For now, in some jurisdictions, social media is "free" for your customers in the sense that it's supported by advertising.

It's not free for you of course because advertising isn't free and from their point of view what you'd be getting is free advertising so they want you to pay them to put it in front of your customers.

Comment by charcircuit 5 hours ago

You don't have to advertise to have your company's posts gain traction on social media.

Comment by accrual 4 hours ago

Seconding the effect of Let's Encrypt on the world of TLS. I remember getting into web applications in the late 2000s and rolling my own certificates/CA and it was a huge, brittle pain. Now it's just another deployment checkbox thanks to LE.

Comment by UltraSane 11 hours ago

I have worked at companies that refused to use LetsEncrypt for the same reason.

Comment by giancarlostoro 11 hours ago

> It coming from GoDaddy is not a selling point...

I just people who use GoDaddy. They were the one company supporting SOPA when the entire rest of the internet was opposed to SOPA. It's very obvious GoDaddy is run by "business-bros" and not hackers or tech bros.

Comment by dylan604 10 hours ago

This is my feeling as well. Finding out someone uses GoDaddy is a bit of a shibboleth.

Comment by traceroute66 11 hours ago

> has anyone actually commented to you in a negative way about using Let's Encrypt?

A friend of mine has had a negative experience insofar as they are working for a small company, using maybe only 15–20 certs and one day they started getting hounded by Let's Encrypt multiple times on the email address they used for ACME registration.

Let's Encrcypt were chasing donations and were promptly told where to stick it with their unsolicited communications. Let's Encrypt also did zero research about who they were targetting, i.e. trying to get a small company to shell out $50k as a "donation".

My friend was of the opinion is that if you're going to charge, then charge, but don't offer it for free and then go looking for payment via the backdoor.

In a business environment getting a donation approved is almost always an entirely different process, involving completely different people in the company, than getting a product or service purchase approved. Even more so if, like Let's Encrypt, you are turning up on the doorstep asking for $50k a pop.

Comment by cjaybo 10 hours ago

“They sent a few emails soliciting donations” isn’t exactly a horror story in my experience. Seems hardly worth mentioning!

Comment by dylan604 10 hours ago

It's not something to stop using them over, but unsolicited solicitation emails are annoying at the least. It's definitely worth mentioning letting other people know they have warts too

Comment by traceroute66 9 hours ago

To be clear, I was merely answering the question posed "has anyone actually commented to you in a negative way about using Let's Encrypt?"

Well, yes, someone actually commented to me in a negative way about using Let's Encrypt ....

Don't shoot the messenger, as they say.

Comment by jfindper 10 hours ago

>one day they started getting hounded by Let's Encrypt multiple times

>trying to get a small company to shell out $50k as a "donation".

>Even more so if, like Let's Encrypt, you are turning up on the doorstep asking for $50k a pop.

Does your friend have anything to corroborate this claim? Perhaps the email with identifying details censored?

I have a received an occasional email mentioning donations. They are extremely infrequent and never ask me for a specific amount. I would be incredibly surprised to see evidence of "hounding" and requests for $50,000.

Comment by traceroute66 9 hours ago

All the usual phishing checks were done if that's what you're thinking.

In terms of the actual mail with identifying details removed, I'd have to go back and ask.

I did look before posting here as I thought they had already forwarded it to me, but it was last year, so I have almost certainly cleaned up my Inbox since. I'm not an Inbox hoarder.

Comment by 10 hours ago

Comment by pedrozieg 9 hours ago

It’s easy to forget how awful TLS was before Let’s Encrypt: you’d pay per-hostname, file tickets, manually validate domains, and then babysit a 1-year cert renewal calendar. Today it’s basically “install an ACME client once and forget it” and the web quietly shifted from <30% HTTPS to ~80% globally and ~95% in the US in a few years.

The impressive bit isn’t just the crypto, it’s that they attacked the operational problem: automation (ACME), good client ecosystem, and a nonprofit CA that’s fine with being invisible infrastructure. A boring, free cert became the default.

The next 10 years feel harder: shrinking lifetimes (45-day certs are coming) means “click to install cert” can’t exist anymore, and there’s still a huge long tail of internal dashboards, random appliances, and IoT gear that don’t have good automation hooks. We’ve solved “public websites on Linux boxes,” but not “everything else on the network.”

Comment by cortesoft 8 hours ago

Just a few months ago my company was going through some transitions and wanted to get some certs to cover us while we migrated to a different stack with let's encrypt and automated cert renewals.

We had some legacy systems on our network that needed certs and had various subdomains that prevented us from just having a wildcard cert. It ended up that we needed a few dozen subdomains with wildcard certs for each, and it was all for internal traffic between them.

The company we were using wanted to charge us $30,000 for a one year cert with that many wildcards.

We said fuck that, created our own CA, generated a big wildcard cert, and then installed the CA on the few thousand servers as a trusted root. A few months later and we are just using let's encrypt for everything, for free.

I can't believe there is a market for $30,000 certs anymore. We were just shocked that that was deemed a reasonable price to charge us.

Comment by bruce511 2 hours ago

I think the best analogy for this are scams. Once a scammer finds a mark they'll pay, there's a desire to soak them for as much as they'll bear.

EVs are not a scam per-se, but they also don't add any value. 80% of the world already figured that out, do by definition if you are asking you are in the bottom 20%.

Now I get you were in the process of migration, but that's an edge case. In a normal case if you go around asking to buy a wildcard EV, you basically have a sign saying "fleece me".

So yeah, there's still a market for people wanting to throw money at CAs, even in these comments you'll see some. And management types are especially prone to "sounds expensive, must be good" logic when spending other people's money.

Comment by electroly 6 hours ago

Both Let's Encrypt and 3-year certificates were introduced in 2015. We had 5+ year certificates before that. At the time you'd buy the longest certificate possible and forget about it--that's what I did. In 2013 I bought a 5-year certificate (self-service, no tickets) and didn't think about it again until 2018.

Comment by simcop2387 8 hours ago

For IoT myself i'm wondering if it's something that could be thrown into the Matter side of things, make the hub/border router act as an ACME server with it's own CA that gives out mTLS certs so the devices can validate the hub and the hub can validate the devices. It'd never be implemented properly by the swarms of cheap hardware out there but I can dream...

Comment by kbolino 4 hours ago

But why?

There's no reliable source of truth for your home network. Neither the local (m)DNS nor the IP addresses nor the MAC addresses hold any extrinsic meaning. You could certainly run the standard ACME challenges, but neither success nor failure would carry much weight.

And then the devices themselves have no way of knowing your hub/router/AP is legitimate. You'd have to have some way of getting the CA certificate on to them that couldn't be easily spoofed.

EDIT: There is a draft for a new ACME challenge called dns-persist-01, which mentions IoT, but I'm not really sure how it helps that use case exactly: https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-pe...

Comment by vbezhenar 6 hours ago

My experience was: get 3-year certificate for free, install it and forget about it. With LetsEncrypt, it's always pain, expired websites everywhere. Too bad that american IT mafia put these good CA out of business.

Comment by jojomodding 6 hours ago

I was about to say that I never encounter TLS errors while browsing, but that's not strictly true. There is one such website, and it's only because the webmaster had a stroke and can't maintain it currently. But apart from that rather sad story I can't relate to your issues at all.

Comment by selcuka 4 hours ago

I agree. I don't remember the last time I saw an expired cert, and it was probably an abandoned web site (which would eventually expire even with a 3-year certificate as well). At least with Let's Encrypt you have to automate it.

Comment by mardifoufs 2 hours ago

American IT Mafia? That provides free certificates? You'd think setting up renewal would be less of a hassle than dealing and paying CAs even if it's once every 3 years, so that would be a rather benevolent mafia. Which of those CAs went out of business by the way?

Do you think Let's encrypt is less popular outside the US?

Comment by vbezhenar 1 hour ago

StartSSL, WoSign were the ones I've used. Very convenient services, much more convenient, compared to this certbot insanity.

I think that the rest of the world does not have much choice, because US uses their IT superiority to force political decisions to the rest of the world. I experienced that first-hand. When my country wanted to implement MITM to improve Internet usability for their citizens, US companies blacklisted government root certificate which disrupted this scheme and forced my country to roll back this plan. Now I have lots of websites completely blocked, instead of more careful and precise per-page blocking that would only be possible with MITM.

Hopefully, over time, China and Russia will destroy this superiority and will provide viable alternatives.

Comment by ascorbic 22 minutes ago

I had to deal with StartCom once many years ago, before LetsEncrypt. They had the rudest customer service I think I've ever encountered.

Comment by asim 11 hours ago

As a sysadmin in the 2007-2011 timeframe I literally used openssl to generate csrs, went to godaddy to purchase SSL certificates and then manually deployed them to servers. Man what a world of change. Let's encrypt is one the best services we've had on the internet. I wish we had more things like this.

Comment by merpkz 2 hours ago

As a sysadmin in 2020 - 2024 time frame I used to do that all the time at my previous job, got a strong openlssl cli game going whenever needed to generate a new csr for existing key or new key and shovel an exact amount of SANs into the CSR too. Lot of time wasted. There were also a certain set of customers for which we managed systems and they insisted for it to be done this way as something free on the internet is not to be trusted. Oh well, strange times.

Comment by Ayesh 6 hours ago

It's been a long time so this is my fading memory, but CAs used to generate a private key on their end and let you download both private key and the certificate containing the public key. The non-technical person who paid big money for the certificate then emails the zip file to the developer. That's when StartTLS wasn't that big back then either.

Just comically bad way to obtain certs.

Comment by j16sdiz 3 hours ago

Many CA have in browser javascript-based private key generation.

(Of course the same page have GoogleAnalytics and facebook button -- otherwise it would be too secure.)

Comment by noAnswer 7 hours ago

Would be cool to have it for S/MIME too.

Comment by amatecha 8 hours ago

Ah man, I remember those days. So tedious!

Comment by par 9 hours ago

i was doing this until a couple years back when a friend told me about LetsEncrypt! It's like magic!!

Comment by ok123456 10 hours ago

Snowden was the other big reason that TLS became the de facto standard for every site.

Prior to that, the consensus was that you only really needed TLS if you were dealing with money and wasn't worth the hassle otherwise. You could sniff traffic from Facebook and Twitter easily.

I remember listening to a talk given by an IRS investigator in around 2008 about how they were able to do a sting and shutdown illegal internet casinos. They collected a good bulk of that evidence from clear-text packet captures of gambling sessions and messages. He preemptively answered the question of whether encryption was a hurdle, by saying no one used it.

Comment by tptacek 10 hours ago

This is a retcon. Facebook rolled out TLS in 2011, 2 years before Snowden, and went TLS-by-default within a month of the Snowden disclosures. Google Mail was TLS-by-default in 2010. TLS was a universal best practice long before 2013 --- by 2010, you'd have gotten a sev:hi vulnerability flagged on your site if you hadn't implemented TLS. SSLLabs was 2009; BEAST was 2011, and was a huge global news story because of how widely deployed TLS was.

Comment by schoen 9 hours ago

I think you're right that this consensus was clearly emerging then (I remember Firesheep in 2010 as another big identifiable contributing factor), but I remember actively asking smaller sites to enable HTTPS in that era, and they would often refuse. So I think Snowden also contributed to the spread of the norm.

It is possible that there's a retcon element, because it's not always clear in my memory exactly what year various sites became more favorably disposed towards the request to use HTTPS. So I could be misremembering some of them as agreeing post-Snowden when they'd actually agreed one year before, or something.

Comment by tptacek 8 hours ago

I think it would be a stretch to say that Snowden did nothing to accelerate the uptake; for better and worse he clearly did. But he didn't set it into motion; we were going to have an all-TLS Internet within a decade with or without him.

Comment by 8organicbits 10 hours ago

I'm not sure that refutes the idea that encryption was uncommon. A couple tech giants with challenging threat models will be ahead of the curve.

Google started tracking adoption of TLS in 2015, with adoption below 50% and some regions below 30%.

https://transparencyreport.google.com/https/overview?hl=en

Comment by ok123456 10 hours ago

Yes. And I remember sniffing Facebook traffic in clear text in 2011. The fact remains that it was considered a significant engineering problem for them to deploy it. It was a "best practice" that most people rolled their eyes at.

Most users and system owners didn't care unless money was being transacted.

Between Snowden and ISPs injecting content into pages, the consensus changed.

Comment by tptacek 10 hours ago

The consensus obviously changed. It's just that it changed years before the Snowden leaks.

Comment by ok123456 9 hours ago

The adversarial nature of the US Government changed the threat model, and it moved from a "nice to have" best practice to a business necessity. They were caught red-handed undermining the privacy of US citizens by systematically exploiting infrastructure vulnerabilities, for example, in Google, where messages flowed in clear text within nominally trusted contexts.

Comment by johncolanduoni 4 hours ago

I don’t know why the Snowden revelations would prompt a business necessity, at least not a rational one for most businesses. What would the NSA slurping up all your data do to your business, that was both bad enough and likely enough to plan for? What it would do to your country or you as an individual is separate from that.

Comment by kbolino 4 hours ago

There were two main issues.

1) A lot of these businesses have customers outside the U.S. Those customers, including some foreign governments, did not want their data to be snooped by the U.S. government. The business risk here is loss of customers.

2) There is no such thing as a private backdoor. If one entity (admittedly a very well resourced one) can snoop, so can others. The publicity also entices new players to enter the game. The business risk here is loss of reputation.

Comment by 12_throw_away 9 hours ago

I think it was a lot earlier than 2013 - SSL was inevitable by the late 2000's, as soon as major ISPs decided they could make more money by injecting ads into http connections (e.g., [1]). It obviously took a while for the infrastructure to scale up ... but I'd imagine that concerns about stolen ad impressions drove a lot more HTTPS adoption than concerns about the NSA.

Comment by joshstrange 10 hours ago

I still remember the original announcement around LE and thought "Great idea, no idea if they'll be able to get buy-in from browsers/etc", now I use it on all my self-hosted sites and will probably be transitioning my employer over to it when we switch to automated renewal sometime next year.

LE has been an amazing resource and every time I setup a new website and get a LE cert I smile. Especially after having lived/experienced the pain that was SSL/TLS before LE.

Comment by vadepaysa 10 hours ago

LetsEncrypt is on my end of year Donate list for the past 5 years. With all modern browsers requiring HTTPS everywhere, a world without Let's Encrypt would be really difficult for indie developers.

Thank You for an amazing product!

Comment by t1234s 10 hours ago

Lets hope they stay independent and never get acquired by Google or any other large tech company. You can imagine a web where SSL issuance is used as a tool to censor websites. I think most browsers have been made to make standard http sites look malicious to normal users.

Comment by mikeyouse 10 hours ago

They're a nonprofit - so they can't be acquired like a typical for-profit company. They could in theory sell some assets but it'd be very convoluted if they were the core assets -- per US tax law, nonprofit assets must remain in the nonprofit world, so there's no risk of any tech company ruining them.

Comment by johncolanduoni 1 hour ago

Look at OpenAI - where there’s a will (and an army of lawyers), there’s a way. That said, I don’t think any of the big tech orgs would be interested in acquiring them. Google and Amazon even already have their own public CAs that are in the major trust stores.

Comment by xandrius 9 hours ago

I heard similar things about another American nonprofit and now I'm not so sure about it. When money and will comes along, loopholes come as well.

So, I wouldn't be so sure, unfortunately.

Comment by crapple8430 7 hours ago

If Google wants to censor your website, they have a variety of other, more effective methods, like by adding it to their safe browsing blacklist, which is also used in many Firefox installs.

Comment by morshu9001 4 hours ago

Or even more apples to apples, they could ignore your cert in Chrome

Comment by Ayesh 5 hours ago

As someone else mentioned, it's a non-profit, so I guess it's not technically possible to get acquired.

But I personally believe that the people behind LetsEncrypt genuinely care about the mission and will never sell out for their personal benefit.

If there was a list of organizations that bring the most impactful things to tech per each dollar received in donations and per each employee, ISRG will be up there at the top.

Comment by 9 hours ago

Comment by greyface- 11 hours ago

New baseline expectation that web traffic will be encrypted on the wire: very good!

New de-facto requirement that you need to receive the blessing of a CA to make use of basic web platform features... not so good.

Comment by ekr____ 11 hours ago

Can you elaborate a bit about what you mean by "the blessing of a CA"?

I agree that it's true that you need a certificate to do TLS, but importantly Let's Encrypt isn't interested in what you do with your certificate, just that you actually control the domain name. See: https://letsencrypt.org/2015/10/29/phishing-and-malware.html

Comment by greyface- 11 hours ago

Their policy today is to grant certificates liberally. There is no technical guarantee that this remains the case indefinitely, only a political one. I don't doubt the sincerity of this guarantee, but I wish I didn't have to rely on it.

Comment by crote 7 hours ago

A big factor is that they are serving so many certs, with only a tiny amount of funding. Anything beyond the most basic pre-written list of blocked domain names is infeasible. Analyzing the content of every single domain would increase their resource needs by several orders of magnitude. That's reasonably close to a technical guarantee, if you ask me.

Comment by ekr____ 11 hours ago

I agree that technical guarantees are better than policy guarantees.

Comment by jovial_cavalier 11 hours ago

That's not new, LetsEncrypt just didn't solve it. And if you think this is the only single point of failure in the stack, I have news for you.

Comment by greyface- 11 hours ago

It's absolutely new. No HTML5 features were restricted to secure origins only pre-LE. Today, many are. Google was able to push these requirements in large part due to Let's Encrypt's success making secure origins ubiquitous.

Comment by ekr____ 11 hours ago

The order of events is a bit more complicated than this.

Google initially proposed restricting powerful features to secure origins back in February of 2015 (https://web.archive.org/web/20150125103531/https://www.chrom...) and Mozilla proposed requiring secure origins for all new features in April of 2015 (https://blog.mozilla.org/security/2015/04/30/deprecating-non...). Let's Encrypt issued its first certificate in September of 2015.

This isn't to say that these two things are unrelated: Mozilla obviously knew about Let's Encrypt and we considered it an important complement for this kind of policy, and at least some people at Chrome knew about LE, though I'm not sure how it played into their thinking. However, it's not as simple as "LE happened and then people started pushing for secure origins for new features".

Comment by bruce511 2 hours ago

I'd also argue, very necessary.

A lot of thd new APIs have to do with accessing hardware. Camera, Microphone, Serial ports (currently experimental) etc.

Given how easy a MITM attack to injection JavaScript or HTML into insecure pages is, a world where insecure pages had access to hardware makes that hardware very vulnerable.

Even though all you'd be doing is reading some random blog etc.

To those who still think serving HTTP is some sort of principled stand, just be aware that injecting malware onto your page at delivery time is pretty trivial. Quite honestly, and I mean this in a constructive way, it doesn't signal "principles" it signals "incompetence".

Comment by unethical_ban 10 hours ago

Kinda hear you, but DNS is a defacto requirement as well. Neither DNS (common TLDs) nor any of the major cert vendors I'm aware of ask you your site's business before issuing.

Comment by charcircuit 9 hours ago

>ask you your site's business before issuing.

Because they want your money. If they ask you after they get to keep your money.

Comment by stego-tech 10 hours ago

Let’s Encrypt is something so amazingly valuable that I was certain it’d be killed dead within a year to prop up the existing SSL cert business.

Congrats on a decade, ya’ll, here’s to many, many more in securing the free internet.

Comment by npodbielski 11 hours ago

I am glad to be one of the users using that for around 7 years. I can't think of how much better is life of people just doing blogs or some silly websites with free https certs. Would I pay 50$ bucks a year for ability to self host nextcloud? Probably not. But security enhancement is so enormous with that service. Thanks to everyone involved for making world a little bit better.

Comment by Decoy1008 11 hours ago

I am so grateful for this. Bummer that they stopped with the email reminder, anyways I was wondering how this would work without active payments. Still amazing.

Comment by callumgare 8 hours ago

Out of interest why do you care? I assume you’re using acme to automate renewals. Is it in case that fails? Or do you work with some system that can’t be automated?

Comment by tempaccountabcd 2 hours ago

[dead]

Comment by Gud 2 hours ago

I use Let’s Encrypt. It is an amazing service and I am forever grateful.

However, it is time for a second source of free certificates. It is not good that we rely on one supplier.

Comment by RandyOrion 3 hours ago

Thank you Let's Encrypt, together with the acme.sh , caddy and the whole ecosystem for TLS.

You simply cannot emphasize the information security enough if all your Internet traffic is audited, censored and manipulated by a number of adversaries supported by (authoritarian) governments and what not.

Comment by 8cvor6j844qw_d6 2 hours ago

Caddy's way of using plugins seems to require building custom binaries, may I know if that's what you did?

I preferred to use wildcard certs, which requires a plugin for the dns

Comment by victorbjorklund 11 hours ago

Wow. Feels like Let’s encrypt been around for longer.

Comment by Aardwolf 11 hours ago

Agreed! What were we using before Let's Encrypt again? Maybe just plain HTTP

Comment by ZeroConcerns 11 hours ago

Mostly Verisign, which required faxing forms and eye-watering amounts of money. Then Thawte, which brought down prices to a more manageable US$500 per host or so. Which might seem excessive, but was really peanuts compared to the price of the 'SSL accelerator' SBus card that you also needed to serve more than, like, 2 concurrent HTTPS connections.

And you try telling young people that ACME is a walk in the park, and they won't believe you...

Comment by anamexis 10 hours ago

And then sketchy resellers for Verisign/Thawte, which were cheap but invariably had websites that ironically did not inspire confidence in typing in your credit card number.

Comment by dylan604 10 hours ago

As GP posited, because of this headache, lots of web traffic was plain ol' HTTP. Let's Encrypt is owed a lot of credit for drastically reducing plain ol' HTTP.

Comment by SirMaster 11 hours ago

I was using StartCom StartSSL which was offering free 1 year certificates at least for my personal sites.

Comment by 0x0 10 hours ago

They were great in the beginning, and then when you issued a few more certs than they liked you were asked to pony up some $$$, and then when you did that and actually "verified" who you were on a personal international phone call, you got a grace, and then issued a few more, they decided they didn't like you so they would randomly reject your renewals close to the expiration date, and then they got bought out by some scummy foreign outfit which apparently caused the entire CA to be de-listed as untrustworthy in all major browsers. Quite the ride.

Also, the only website I've ever encountered that actually used the HTML <keygen> tag.

Comment by 11 hours ago

Comment by bakies 11 hours ago

Self signed certs. I wasn't paying.

Comment by Thaxll 11 hours ago

Some of them were not expensive but it was not convenient at all.

Comment by asadotzler 11 hours ago

SSL/TLS via expensive and hard to work with providers and tooling. Let's Encrypt made it free and easy to maintain.

Comment by rew0rk 11 hours ago

either you used http, self signed if you did not mind the warning, and i remember there being one company that did offer free certificates that validated, but cant remember the name of it

Comment by SahAssar 11 hours ago

> i remember there being one company that did offer free certificates that validated, but cant remember the name of it

You're probably thinking of StartSSL, and it was a bit of a pain to get it done.

Comment by tomklein 11 hours ago

I believe it was StartSSL and/or WoSign back then

Comment by 1f60c 10 hours ago

The pros were using client-side encryption :D

Comment by quesera 11 hours ago

I was going to say the opposite. LE still feels like the "new" way, to me. :)

Comment by omani 4 hours ago

only downside to LE is the attack surface presented by CTLs (Certificate Transparency Logs). as soon as you request a cert, you will get attacks on the endpoint/subdomain you have registered by countless IPs trying to login etc.

Comment by phillipseamore 8 hours ago

10 great years.

For the next years I'm hoping for more resilience/global distribution in the issuance process. Since I live on an island for about half the year I do have experience with internet outages, and we do appear to live in turbulent times. That could be an issue with the ever decreasing certificate lifetime. I'd love to see LE exploring options like working with ccTLD registrars to work on local issuance.

Comment by mmooss 8 hours ago

Another amazing success born at Mozilla:

"The Let's Encrypt project was started in 2012 by two Mozilla employees, Josh Aas and Eric Rescorla, together with Peter Eckersley at the Electronic Frontier Foundation and J. Alex Halderman at the University of Michigan."

https://en.wikipedia.org/wiki/Let%27s_Encrypt

What was Mozilla's role, beyond conception? Parenting? Care and feeding? A roof?

Comment by ekr____ 2 hours ago

A lot of this is covered in the Let's Encrypt retrospective paper from 2019: https://www.abetterinternet.org/documents/letsencryptCCS2019....

From Section 3.1.

"Let’s Encrypt was created through the merging of two simultaneous efforts to build a fully automated certificate authority. In 2012, a group led by Alex Halderman at the University of Michigan and Peter Eckersley at EFF was developing a protocol for automatically issuing and renewing certificates. Simultaneously, a team at Mozilla led by Josh Aas and Eric Rescorla was working on creating a free and automated certificate authority. The groups learned of each other’s efforts and joined forces in May 2013.

...

Initially, ISRG had no full-time staff. Richard Barnes of Mozilla, Jacob Hoffman-Andrews of EFF, and Jeff Hodges (under contract with ISRG) began developing Let’s Encrypt’s CA software stack. Josh Aas and J.C. Jones, both with Mozilla at the time, led infrastructure development with assistance from Cisco and IdenTrust engineers. ISRG’s first full-time employee, Dan Jeffery, joined in April 2015 to help prepare the CA’s infrastructure for launch. Simultaneously, James Kasten, Peter Eckersley, and Seth Schoen worked on the initial ACME client (which would eventually become Certbot) while at the University of Michigan and EFF. Kevin Dick of Right Side Capital Management, John Hou of Hou & Villery, and Josh Aas constituted the team responsible for completing a trusted root partnership deal and signing initial sponsors."

Comment by tptacek 7 hours ago

You can ask them; both Josh and Eric are HN people, and Erik is already on this thread. :)

Comment by 1970-01-01 6 hours ago

Getting yourself an IP address certificate still seems like an idea that's too crazy to work. I'm actually looking forward to seeing all the things breaking by becoming more secure.

Comment by stephenr 58 minutes ago

10 years and still no S/MIME.

Comment by bruvva 5 hours ago

This is something that legitimately made the world a better place.

Comment by nofunsir 2 hours ago

Still not convinced it's not a honeypot. Would like to see concrete evidence.

Comment by nixpulvis 8 hours ago

Is there a notion of tier 1 and tier 2 certificates? Like if I setup paid and backed by contract agreements with a cert provider, does this give users more confidence that their lock icon in the browser actually means they are talking to who they think they are?

It's one thing to provide a cert to provide secure encrypted TLS, it's another thing to establish identity with the user. Though, most users would never notice either way.

Comment by kbolino 4 hours ago

There are Extended Validation (EV) certificates, and for a couple of years browsers gave them special treatment (typically, a green lock indicator instead of gray, sometimes accompanied by the validated business name). However, they were eventually demoted to the same appearance as ordinary Domain Validation (DV) certificates for a couple reasons:

1) This is not as useful as it sounds. Business names are not unique, and the legal entity behind a legitimate business may have a different name that no one has ever heard of.

2) Validation gets dicier as the world gets opened up and as laws and customs change. The higher tier confers greater prestige and legitimacy, but the only discriminator really backing it is money.

Comment by nixpulvis 3 hours ago

Yea, this was what I thought I'd dealt with before but I couldn't remember.

It's too bad the same hasn't happened to software notarization and signing systems.

People will argue that having payments enforced some accountability, but I'm not really convinced.

Comment by dilawar 2 hours ago

A couple of years ago, I went through the process of signing a kenel minifiter that I wrote for our endpoint-security product. It was complicated, to put it mildly.

Imagine if we had a similar process for websites! Thanks Let's Encrypt.

Comment by awaseem 10 hours ago

Incredibly grateful for this project

Comment by tracker1 10 hours ago

I'm not sure that I'm more surprised that it's only been 10 years or that it's been that long. I mean, that's a relatively quick turn around to pretty much dominate TLS certs to the point that it's the default for so many platforms... that HTTPS has become such a norm over the exception.

On the other hand, has it really been that long, it seems just yesterday I was first trying to configure nginx for it. That said, since I discovered Caddy, I haven't really looked back, though I do use Traefik too.

I mean, by comparison, it feels like IE6 took longer to die than Let's Encrypt has been around.

Comment by kyawzazaw 10 hours ago

my friends work here! and it was founded by an alum from my school Macalester College

Comment by hbn 10 hours ago

Yes let's. But that doesn't answer my question.

Comment by hinkley 9 hours ago

The thing that has made me feel the oldest this week is that someone I used to mentor posted a holiday pictures with visible wrinkles. If people you think are young look old, then buddy, check the mirror.

But this is a close second. 10 years? That can't be right. Even accounting for Covid Time Dialation.

Comment by racl101 7 hours ago

Just 10, it feels like more.

Comment by jrochkind1 11 hours ago

it is hard to believe it's been ten years.

Comment by mpingu 8 hours ago

That is awesome i love how you change the TLS Scene for ever! Keep pushing it!

Comment by 1 hour ago

Comment by 8 hours ago

Comment by amelius 7 hours ago

Next step: Let's Tor?

Comment by scblock 11 hours ago

LE has been really great, particularly in running hobby web sites on the public internet. Getting certbot up and running wasn't hard, automating renewal wasn't hard, and because they have DNS-based pathways to verification you can use LE certificates for sites not exposed to the public internet as well. Combine it with something like Caddy and getting SSL for an app becomes the default without ever having to manage certificates by hand.

I find it pretty amazing how far its come, and how big a change it has made to the internet in the decade it's been operating.

Comment by cyberax 6 hours ago

The next steps:

1. Add support for DNS-based persistent authentication: https://datatracker.ietf.org/doc/draft-ietf-acme-dns-persist...

2. Allow the user to just publish their public key into that TXT record.

3. Cut out the middleman and do the authentication directly in the browser.

4. DANE

Comment by zeagle 2 hours ago

For someone who runs a small personal website and uses LE to secure this + some web exposed services, could you explain how this is different/better than acme-dns-certbot?

Comment by tptacek 5 hours ago

DANE isn't going to happen, and if you want to tilt at that windmill, it's Chrome and Mozilla you need to pressure, not LetsEncrypt.

Comment by cyberax 5 hours ago

I mean, these are the steps that can bring it. And with Let's Encrypt as a safe fallback, it actually is feasible this time.

Long shot? Yes. But not impossible.

Comment by ekr____ 4 hours ago

What's the incentive for individual sites or browsers to do this?

From the site's perspective, they're going to need to have a WebPKI certificate for the foreseeable future, basically until there is no appreciable population of WebPKI-only clients, which is years in the future. So DANE is strictly more work.

From the browser's perspective, very few sites actually support DANE, and the current situation is satisfactory, so why go to any additional effort?

In order for technologies to get wide deployment, they usually need to be valuable to individual ecosystem actors at the margin, i.e., they have to get value by deploying them today. Even stipulating that an eventual DANE-only system is better, it doesn't provide any benefit in the near term, so it's very hard to get deployment.

Comment by tptacek 3 hours ago

A fun note: I vibecoded a dumb thingy that monitors the top 1000 zones on the Tranco research list of popular zones for DNSSEC status:

https://dnssecmenot.fly.dev/

Obviously, the headline is that just 2% of the top 100 zones are signed (thanks to Cloudflare). But the funnier thing is: in 5+ months of letting this thing run, it's picked up just three changes to DNSSEC status among all the zones it monitors. The third happened just an hour or so ago, when Canva disabled DNSSEC.

Comment by tptacek 5 hours ago

The first step you'd need is a reliable way to deliver DNSSEC records to browsers, which does not currently exist. So I feel like you're missing at least a step 0, if not a step -1 (of getting ~anybody to actually sign zones.)

Comment by kbolino 4 hours ago

Aren't browsers generally implementing their own DNS resolution (via DoH) nowadays anyway? Not sure it helps that much, but operating systems not enforcing/delivering DNSSEC seems like a side-stepped problem now.

Comment by tptacek 3 hours ago

No, not as a general rule they aren't. And remember, the DNSSEC record delivery problem isn't an issue for the majority of all browser sessions, just a small minority that are on paths that won't pass DNSSEC records reliably. Since you can't just write those paths off, and you can't really reliably detect them, you end up needing a resolution fallback --- at which point you might as well not be using DANE.

This was a big enough issue that there was a whole standards push to staple DNSSEC records to the TLS handshake (which then fell apart).

Comment by nodesocket 6 hours ago

Would be interesting to hear what database they are using and how they are doing replication? Is it simple master / slave or multi-master?

Comment by mcpherrinm 2 hours ago

Let’s Encrypt currently has a single primary with a handful of replicas, split across a primary and backup DC.

We’re in progress of adopting Vitess to shard into a handful of smaller instances, as our single big database is getting unwieldy.

Comment by nodesocket 2 hours ago

Thanks. Would love to see a tech blog post once you get Vitess implemented.

Comment by mcpherrinm 32 minutes ago

We’ve already started drafting it :)

Comment by Ayesh 5 hours ago

https://github.com/letsencrypt/boulder

You can find a docker-compose.yml file to get some idea.

Appears to be using MariaDB.

They shut down OCSP responders and expiry email reminders, so there really is no need to have a database apart from rate limits, auth data, and caching.

For Certificate Transparency, they are submitted to Google and CloudFlare run trees but I don't think LetsEncrypt run their own logs.

Comment by mcpherrinm 2 hours ago

Let’s Encrypt does operate CT logs. I wrote a blog post about our current-generation logs at https://letsencrypt.org/2024/03/14/introducing-sunlight

Comment by nodesocket 5 hours ago

I assume they want to store metadata instead of having to pull from the certificates itself, but maybe that’s actually easier and more performant.

Comment by ZebusJesus 7 hours ago

They helped change the security game, hats off to Let's Encrypt making it accessible. I remember when people would get upset about having to pay 400$ for a cert from go daddy nearly 2 decades ago. Google pushing the HTTPs requirement was also a good thing and Let's Encrypt made it possible for many that otherwise wouldn't have bought a cert in the first place.

Comment by 9 hours ago

Comment by postbase 10 hours ago

thank you for your service

Comment by hulitu 11 hours ago

> 10 Years of Let's Encrypt

Aren't they only 45 days [1] old ?

[1] https://letsencrypt.org/2025/12/02/from-90-to-45

Comment by p2detar 11 hours ago

Not sure if you're joking or not, but I have to deal with this upcoming change at some point and still haven't read in detail why they decided to do this.

Could anyone clarify?

Comment by bifurcation 10 hours ago

Hi there, ISRG co-founder and current board member here. In brief, shorter lifetimes force people to automate (which, e.g., avoids outages from manual processes) and mitigates the broken state of revocation in the Web PKI. That latter point especially is what I understand to be driving the Web PKI toward ever-shorter lifetimes.

I actually remember the discussion we had in ~2014 about what the default certificate lifetime should be. My opening bid was two weeks -- roughly the lifetime of an OCSP response. The choice to issue certificates with 90 day lifetimes was still quite aggressive in 2015, but it was a compromise with an even more aggressive position.

Comment by everfrustrated 9 hours ago

With the move to ever shorter certs the risk to letsencrypt having an outage is higher.

It would be nice to read more about what the organization is doing around resilience engineering so we can continue to be confident in depending on it issuing renewals in time.

Do you publish any of this? DR plans? Etc.

I don't mean for this to be a negative - really impressed by LE - but we've had a lot of Cloudflare outages recently and my mind is on vendor reliability & risk at the moment.

Comment by mcpherrinm 9 hours ago

I'm the technical lead for Let's Encrypt SRE.

Publishing more about our resilience engineering sounds like a great idea!

I'll get that on our blogging schedule for next year

Comment by Ayesh 5 hours ago

Considering how many ACME clients are available today with all sorts of convenient features, and that many web servers nowadays have ACME support built in (Caddy, Apache mod_md, and recent Nginx), I believe that people who don't automate ACME certificates are the people who get paid hourly and want to keep doing the same boring tasks to get paid.

Comment by crote 7 hours ago

Because big companies have a habit of growing layers of bureaucracy. If a cert is valid for three years, a decent bunch of them will invent a three-month process around cert renewal, involving two dozen stakeholders, several meetings, and sign-off from the CTO.

The side-effect of this is that they become incapable of doing it any faster during an emergency. Private key compromised? Renewal takes two months, so better hope the attackers can't do too much damage before that. CAs in turn have large (=profitable) customers which such processes who they really don't want to lose, so historically when they've failed to renew in time during incidents CAs have granted those customers exceptions on the revocation rules because they are "business critical" and doing it by-the-book would cause "significant harm". No CA is willing to be strict, because they'd lose their most valuable customers to their competition.

The only way to solve this is to force companies into adopting efficient renewal processes via an industry-wide reduction of certificate validity time. When you have to renew once a month you can't afford to have a complicated process, so you end up automating it, so there's no reason for CAs to delay cert revocation during incidents, so the internet is more secure. And because every CA is doing it, companies don't gain anything by switching to more lenient CAs, so the individual CAs have no incentive to violate the industry rules by delaying revocation.

Comment by chippiewill 10 hours ago

Lets Encrypt are doing is because of the decision that CAs and browser makers made that it needs to be reduced (browsers have been reducing the length of certs that they trust).

The why is because it's safer: it reduces the validity period of private keys that could be used in a MITM attack if they're leaked. It also encourages automation of cert renewal which is also more secure. It also makes responding to incidents at certificate authorities more practical.

Comment by dingaling 10 hours ago

> it reduces the validity period of private keys that could be used in a MITM attack if they're leaked

If a private key is leaked, 45 days is sufficient to clean-out the accounts of all that company's customers. It might as well be 10 years.

If cert compromise is really common enough to require a response then the cert lifetime should be measured in minutes.

Comment by nvader 10 hours ago

Wow, this might be the push I needed to automate certificate renewal on my personal website [0].

Manually clicking `make renew-cert` was barely tolerable every quarter, but if I have to do it twice as frequently I may as well ask an LLM to figure it out on my behalf.

[0]: https://danverbraganza.com

Comment by dylan604 10 hours ago

And that is the very point of the short life span. One year certs had the potential of the person responsible for the cert no longer being the same person at time of renewal. Making it easy to automate so that it was just a cron task meant it didn't matter how often the person responsible changed.

Your pain and intolerance to that button push proves their intent.

Comment by bifurcation 10 hours ago

Heh, as I was saying about shorter lifetimes encouraging automation...

https://news.ycombinator.com/item?id=46210786

Comment by nvader 9 hours ago

Yep, it's just the push I needed to get off my seat ;)

Comment by Havoc 10 hours ago

Reminder that it’s a non profit

Comment by tempaccountabcd 2 hours ago

[dead]

Comment by sam_lowry_ 11 hours ago

[flagged]

Comment by schoen 9 hours ago

You might want to be more specific about the meaning of "between" here. It's not a cryptographic MITM attack, and if it ever facilitated someone else in performing one, that should be detectable.

https://en.wikipedia.org/wiki/Certificate_Transparency

(It's also true that the level of active monitoring of CT logs has never gotten very high.)

Comment by jsheard 10 hours ago

It's not like Let's Encrypt is the only game in town, Actalis in Italy provides free ACME certs too if you'd prefer to keep things in Europe.

Comment by charlesbarbier 10 hours ago

Not sure if there is a point to "keep things in Europe" when it come to certificate authority.

- LetsEncrypt don't have the private key tied to your certificate - Any of the Certificate Authorities could potentially emit unauthorized certificate

Your only protection for all of these problems is HPKP. If you prefer to keep things in Europe, keep that pinned private key in Europe, but the rest doesn't matter.

That said, it's pretty nice that LetsEncrypt forced the ACME protocol on this industry. Not only it create redundancy with mostly interchangeable alternatives but before ACME, there was no way to fully automate certificate provisioning cleanly.

Comment by 7 hours ago

Comment by bifurcation 10 hours ago

Just to clear up one point -- Let's Encrypt did not at all force ACME on the industry. We deliberately took it to the IETF so that we could get input from more parts of the industry (including some major refactors!). Instead of pressure from Let's Encrypt, I would attribute its success to the open process of the IETF, the awesome open-source community that made great ACME software (shoutout to Matt and Caddy!), and the resulting pressure on CAs for a better user experience from users and customers.

Comment by charlesbarbier 9 hours ago

I didn't express myself well but what I meant by force is that by building a standardized to automate way manage certificate, ACME imposed itself and became mandatory.

Previously, most CA had no programmatic way to order certificate, it was all done manually.

As far as I know, the only providers with that would let you automate certificate provisioning at the time where Comodo, GlobalSign and Digicert.

They all had their own quirky API. Just to give you an idea, we ended up selecting GlobalSign at Shopify a few years before LetsEncrypt, and it was this SOAP nightmare: https://www.globalsign.com/en/repository/GlobalSign_Client_A...

At first none of them were warm at the idea of providing an ACME endpoint. I'm assuming part of it is the cost of implementing it but they probably liked the stickiness of their custom APIs too tied to million dollars contracts.

Nowadays they all implement ACME. At some point, they where effectively forced to implement it to acquire new customers and keep their existing base around because nobody would accept poorly designed custom made protocol anymore.

Comment by everfrustrated 9 hours ago

Their website seems to suggest the renewal isn't free?

Comment by 8 hours ago

Comment by charlesbarbier 10 hours ago

They are definitively not the most shady organization in the CA/Browser Forum.

Comment by letsgetreal 9 hours ago

Let's Encrypt allows anyone to have secure https communication, sure, but it doesn't address the question of website authenticity. I groan when I'm on an e-commerce site and I click on the browser URL lock icon and see a Let's Encrypt certificate because frankly anyone can create one for no cost and I don't know if it's the real website or if I made a URL typo. Say what you will about the expensive cert providers, but it's reassuring when you see DigiCert or Sectigo - with a company name and the address of the head office.

Comment by tptacek 9 hours ago

It was never a reasonable goal of the WebPKI to authenticate entities; only to help establish end-to-end encryption between unrelated parties on the Internet. The WebPKI can ensure you're talking to whoever controls `ycombinator.com`, but it has to be up to some other layer of the security stack to decide whether you want to be talking to `ycombinator.com`. (This is in fact part of the logic behind FIDO2 and phishing-proof authentication).

Comment by schoen 9 hours ago

> It was never a reasonable goal of the WebPKI to authenticate entities

The confusing thing is that this goal nonetheless appeared in some original marketing and explanations about the web PKI from the late 1990s when it was first introduced. There was another smaller burst of this when people were arguing over the formalization of DV certificates and of Google's UI changes that stopped treating EV specially (as some people found both of those changes objectionable).

I agree with you that the goal of authenticating entities was impractical, but the mental association and expectation around it still hasn't been completely dispelled. (I think I saw some form of this when doing support on the Let's Encrypt Community Forum, as people would sometimes complain that a site shouldn't have been allowed to have a certificate, either because it wasn't the organization they expected, or because it was malicious somehow.)

Comment by tptacek 8 hours ago

Right, and when people who haven't paid that much attention to the machinations of the WebPKI (who could blame them) talk about how weird it is that the browsers killed EV, this is an important part of the backstory: EV was mostly a failed attempt to make the WebPKI do this kind of "do-what-I-mean" entity authentication.

The problem as I see it is: there simply isn't one coherent global notion of what entity authentication means. It's situational.

Comment by letsgetreal 9 hours ago

FIDO2 doesn't solve the first website contact trust problem - only the HTTPS certificate does that.

Comment by tptacek 8 hours ago

It's good to want things!

Comment by Ayesh 5 hours ago

To prove a very important point, that EV certificates are broken, someone obtained a "Stripe Inc." EV certificate by registering a company in a different state.

https://arstechnica.com/information-technology/2017/12/nope-...

(The original site is no more, but this Arstechnica article has screenshots and a good summary)

Comment by xandrius 9 hours ago

Not really the point of ssl certs though. And I'm pretty sure those limitations are the smallest hurdle, most people wouldn't even care checking.

Comment by letsgetreal 9 hours ago

The "most people won't care argument" doesn't inspire confidence in the authenticity of the website.

It's essentially a self-signed cert that anyone could make with the false security of a root certificate authority.

Comment by ekr____ 7 hours ago

This isn't correct.

There are two authentication properties that one might be interested in:

1. The binding of some real world identity (e.g., "Google") to the domain name ("google.com). 2. The binding of the domain name to a concrete Web site/connection.

The WebPKI is responsible for the second of these but not the first, and ensures that once you have the correct domain name, you are talking to the right site. This still leaves you with the problem of determining the right domain name, but there are other mechanisms for that. For example, you might search for the company name (though of course the search engines aren't perfect), or you might be given a link to click on (in which case you don't need to know the binding).

Yes, it is useful to know the real world identity of some site, but the problem is that real world identity is not a very well-defined technical concept, as names are often not unique, but instead are scoped geographically, by industry sector, etc. This was one of the reasons why EV certificates didn't really work well.

Obviously, this isn't a perfect situation, but the real world is complicated and it significantly reduces the attack surface.

Comment by letsgetreal 7 hours ago

Nothing mentioned will help for a website with a Let's Encrypt SSL cert. How can I know with confidence that I can conduct commerce with this website that purports to be the company and it's not a typo squatter from North Korea? A google search doesn't cut it. Nothing in this thread has answered that basic question.

It's a non-issue for DigiCert and Sectigo certs. I can click on the certs and see for myself that they're genuine.

Comment by bentley 6 hours ago

Worse than typosquatting is EV’s problem that anyone can register a corporation with an identical name.

https://web.archive.org/web/20171211181630/https://stripe.ia...

Comment by tptacek 6 hours ago

No you can't. Even during the EV years, clowning an EV cert was more like a casual stunt for researchers than an actual disclosable event. In reality, there's nothing DigiCert is meaningfully doing to assure you about "conducting commerce" on sites.

Comment by tialaramex 6 hours ago

> It's a non-issue for DigiCert and Sectigo certs. I can click on the certs and see for myself that they're genuine.

You can see for yourself that a Let's Encrypt certificate is genuine too.