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.
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!
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.
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.
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.
> 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.
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.
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.
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.
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.
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. :)
> 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]
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.
> 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.
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.
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.
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.
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!
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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
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…
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
> 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?
> 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.
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.
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).
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).
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!".
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…”
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.
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.
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.
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.
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.
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.
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.
> 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.
> 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.
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
>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.
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.
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.”
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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".
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.
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.
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.
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?
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.
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...
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.
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.
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.
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
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.
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.
"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."
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.
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.
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.
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.
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.
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.)
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
> 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.)
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.
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.
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.
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.
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.
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.
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...
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.
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.
"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.
it’s okay, the scam continues with BIMI
> 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.
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.
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.
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.
Still required for Apple Dev account last time I had to go through the process a few years 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.
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. :)
This made me curious. Like selling cheats for games?
Yes, both in the case of them and I.
> 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.
> 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.
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.
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.
Sure, and then someone just registers a company with the exact same name in another jurisdiction and EV is thwarted anyway
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.
The replies to my original comment make it obvious who has gotten an EV cert from a quality CA before and who hasn't.
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!
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.
Having run an EV issuing practice… they were required to contact you at a D&B listed number or address.
EV certs also showed the legal name of the company that requested the certificate - that was an advantage.
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.
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.
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.
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.
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...
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.
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
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.
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.
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.
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.
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.
you can find quite of few examples online that the entity check wasn't all that strict...
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.
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.
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
What about OV?
It's never been clear to me what the rationale for OV was, as the UI wasn't even different like EV was.
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?"
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.
> 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".
> 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!
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.
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
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…
No! Let's encrypt is easily the best thing that's happened for a secure internet the last 10 years.
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.
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.
> 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.
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.
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.
An SSL provider once refused to sell me a certificate because the domain name had the word "Windows" in it.
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
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.
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...
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.
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.
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.
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.
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.
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.
What is the device, if I may ask?
This can happen too with Micropython on Esp8266
> 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?
> 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.
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.
> 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...
TLS only takes a few minutes to add to a self hosted solution, just plop caddy in front of your server
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).
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).
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!".
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…”
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.
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.
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.
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.
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.
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.
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.
You don't have to advertise to have your company's posts gain traction on social media.
I have worked at companies that refused to use LetsEncrypt for the same reason.
> 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.
This is my feeling as well. Finding out someone uses GoDaddy is a bit of a shibboleth.
> 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.
“They sent a few emails soliciting donations” isn’t exactly a horror story in my experience. Seems hardly worth mentioning!
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
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.
>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.
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.
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.”
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.
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.
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.
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.
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.
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...
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...
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.
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.
Would be cool to have it for S/MIME too.
Ah man, I remember those days. So tedious!
i was doing this until a couple years back when a friend told me about LetsEncrypt! It's like magic!!
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.
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.
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.
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.
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
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.
The consensus obviously changed. It's just that it changed years before the Snowden leaks.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
Or even more apples to apples, they could ignore your cert in Chrome
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.
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.
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
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.
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.
I agree that technical guarantees are better than policy guarantees.
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.
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.
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".
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.
>ask you your site's business before issuing.
Because they want your money. If they ask you after they get to keep your money.
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.
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.
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.
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?
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.
Wow. Feels like Let’s encrypt been around for longer.
Agreed! What were we using before Let's Encrypt again? Maybe just plain HTTP
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...
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.
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.
I was using StartCom StartSSL which was offering free 1 year certificates at least for my personal sites.
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.
Self signed certs. I wasn't paying.
Some of them were not expensive but it was not convenient at all.
SSL/TLS via expensive and hard to work with providers and tooling. Let's Encrypt made it free and easy to maintain.
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
> 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.
I believe it was StartSSL and/or WoSign back then
The pros were using client-side encryption :D
I was going to say the opposite. LE still feels like the "new" way, to me. :)
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.
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.
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?
You can ask them; both Josh and Eric are HN people, and Erik is already on this thread. :)
This is something that legitimately made the world a better place.
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.
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.
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.
Incredibly grateful for this project
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.
my friends work here! and it was founded by an alum from my school Macalester College
Just 10, it feels like more.
Yes let's. But that doesn't answer my question.
That is awesome i love how you change the TLS Scene for ever! Keep pushing it!
Next step: Let's Tor?
it is hard to believe it's been ten years.
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
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.
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.
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.
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.
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.)
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.
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).
Would be interesting to hear what database they are using and how they are doing replication? Is it simple master / slave or multi-master?
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.
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.
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.
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.
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.
thank you for your service
> 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
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?
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.
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.
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
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.
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.
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.
> 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.
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
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.
Heh, as I was saying about shorter lifetimes encouraging automation...
https://news.ycombinator.com/item?id=46210786
Yep, it's just the push I needed to get off my seat ;)
Reminder that it’s a non profit
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.
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).
> 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.)
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.
FIDO2 doesn't solve the first website contact trust problem - only the HTTPS certificate does that.
It's good to want things!
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)
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.
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.
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.
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.
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...
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.
> 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.