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.
I think the rebuttal to the CEO today is really very simple.
a) How many of the sites you visit everyday have DV and how many have EV certificates?
b) Name any site at all, that you have visited, where your behavior or opinion has changed because of the certificate?
In truth the green-bar thing disappeared on mobile long before desktop (and in some cases it was never present.)
In truth if you polled all the company staff, or crumbs just the people round the boardroom table (probably including the person complaining) a rounding error from 0 could show you how to even determine if a cert was DV or EV.
EV could have an inspector literally visit your place of business, and it would still have no value because EVs are invisible to site visitors.
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.
> 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.
IMO it would make sense to tie into the trademark system. Allowing companies to build a brand reputation and protect it from impersonators is literally the whole point of that part of our legal system.
Imagine if only the owner of the McDonald's trademark could issue a certificate which displays the McDonald's name and logo, for example.
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. :)
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.
How many CAs do you think there are? How many countries do you think they operate in?
Maybe we could augment the old EV cert indicator with a flag icon, but now there's yet another thing that users have to pay attention to. Maybe the CA/Browser Forum could run a clearinghouse for company names, but apart from trivial examples, there might very well be legitimate cases of two companies with the same name in the same country, just in different industries. Now do we augment the indicator with an industry icon too? Then the company changes its name, or forms a subsidiary relationship, or what have you. Now do we need to put "Meta (formerly Facebook)" or "Facebook (division of Meta)" etc. in the name?
There's just so many problems with the EV cert approach at Internet scale and they're largely beyond solvable with current infrastructure and end-user expectations.
How do you decide when a company is "well-known"? What's going to happen when there are two well-known companies with the same name or a very similar name? What if a well-known company in country A expands to country B, where a well-known company with that name (but active in a different industry) already exists? How are you going to deal with subsidiaries which are both legally and organizationally separate? Who gets to keep the EV when a company spins off a division but both parts retain the same name?
"Use human judgement" might work for trivial examples of fraud, but it quickly breaks down once you try applying it to the real world. Besides, how are you going to apply the same "human judgement" across hundreds of employees at dozens of CAs? If anything, you're just begging to get sued by large corporations whose complex situation fell on the wrong side of your human judgement.
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.
Are company names even unique within the UK? Sure, there can be only one bank named Barclays because of trademark laws, but can't there be a company in a different sector with the same name? Like Apple the computer business vs Apple the record company?
Or don't you have small local businesses (restaurants, pubs, stores) with duplicate names as long as they're in different locations? I know here in Flanders we have, for example, tens if not more places called "Café Onder den toren" (roughly translated as "Pub beneath the tower"). Do all local businesses in the UK have different names?
That's not exactly a great example, is it? "Barclay" even has a disambiguation page on Wikipedia, because it's a reasonably common Scottish surname.
For example, there used to be a Scottish company constructing steam locomotives which traded under the "Barclays & Co" name - because it was founded by one Andrew Barclay. There's also the Barclay Academy secondary school, and a Bentley dealer which until recently operated as Jack Barclay Ltd.
And that's just the UK ones! Barclays operates internationally, which means they want "barclays.com", so suddenly there's also Barclay-the-record-label, Barclay-the-cigarette-brand, Barclay-the-liquor-brand, Barclay College, golf tournament The Barclays, Barclays Center (whose naming rights were bought by the bank, but they of course want their own completely distinct website), Barclay Theatre, three Barclay Hotels.
Of course there's also all the stuff under "Barkley", "Barkly", "Berkley", and probably a dozen other variations just waiting to be used to scam dyslexic Barclays custumers.
Barclays used to operate under Barclays Bank PLC. IMO, if disambiguation was problematic online they would have reverted back to that name.
You bring up good points, but I don't think that company naming has to be 100% proof against confusion, it's just one more helpful thing for consumers to identify whom they are doing business with.
In the case of close names like "Barkley", if they're doing banking, there is probably a trademark case against if they actually use it to confuse customers.
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.
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.
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.
Trademarks are industry-specific. Ordinarily, a painting company called Stripe isn't going to cause confusion with the payment platform Stripe, so there's no reason to deny the trademark.
It's how you end up with both Apple Corps (the Beatles' record label) and Apple Computer (the tech company). They've been involved in quite a few lawsuits over the years, mostly because the tech company decided to expand into the multimedia business.
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.
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.
> My router _shouldn't_ have a globally recognized certificate, because it's not on a publicly visible host.
If you're not encrypting local network traffic then any rogue device on that network can decide to intercept it and steal your admin password. That's one of the biggest reasons why we adopted HTTPS in the first place - whether a host is public or not isn't relevant.
It doesn't need a "globally" recognized certificate signed by a public CA, self-signed ones are fine. At home I manage mine with XCA. I have a root CA that's installed on all of my devices, with name constrains set to ".internal", ensuring it can't be used to sign certificates for any other domains.
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.
Android is pretty easy, you just add it to the keystore and that's it. I've had my own CA long before Let's Encrypt, but now mostly only use it for non-public devices that can't easily use Let's Encrypt (printers, switches, etc).
You can add it to your user CA store, but no app will trust it since it's treated differently from the system CA store, which you can't modify without root or building your own ROM. In effect it is out of reach for most normal users, as well as people using security focused ROMs like Graphene, when ironically it can improve security in transit in many cases.
It's technically possible to get any Android app to accept user CAs. Unfortunately it requires unpacking it with apktool, adding a networkconfigoverride to the XML assets and pointing the AndroidManifest.xml to use it. Then restitch the APK with apktool, use jarsigner/apksigner and finally use zipalign.
Doesn't need a custom ROM, but it's so goddamn annoying that you might as well not bother. I know how to do these things; most users won't and given the direction the big G is heading in with device freedom, it's not looking all that bright for this approach either.
A long time ago when I was playing with rolling my own PKI, each of Android, iOS, Chrome, Firefox, and even Internet Explorer allowed me to install a root CA by opening the .crt file. From what I remember, iOS popped up some warnings and added the cert as part of a profile, but it did work.
I know things like MDM/Intune/Group Policy/etc and such can A) faciliate doing this on a large number of devices and B) prevent users from doing this on their own.
I don't want to trust my own root CA as I don't trust myself to keep it secure.
I want to important it only for a specific set of domains. "Allow this rootca to authenticate mydomain.com, addmanager.com, debuggingsite.com", which means even if compromised it won't be intercepting mybank.com
You can absolutely do that with name constraints extension set on the root CA certificate. You should verify compatibility but it's pretty universally supported on modern browsers and consumer devices last I checked.
If you generate the root CA sure. However name constraints aren't well supported.
A far better option would be to allow me, the user, to do this in the user agent. I can import my mitm cert and today I can trust it for "abc123.com" and point that to something I want to access in that manner for some reason, but tomorrow simply toggle that trust off.
If I find that I want to use a specific website and want to do something with the traffic, then I could point that DNS to my middle-box and turn that on in my browser. With name constraints I'd have to regenerate the root certificate with the new domain, and then re-import it.
the entire concept of the name constraints puts the power into the CA issuing person rather than the user.
Where are you finding that name constraints aren't supported? I've only come across that on embedded/IoT devices. They work fine for me across Firefox and Chrome on Linux, on Android, and they are supposed to work fine on Apple devices too.
> If I find that I want to use a specific website and want to do something with the traffic...
I agree but that's a different problem. If you just need a certificate for your router and some internal services (the original discussion), you can do that using an internal root CA and you have nothing to worry about as long as you using name constraints.
On IoT devices without nameConstraints support I just use an alternative CA certificate without name constraints (same key, different extensions).
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?
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).
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…”
How does SSL on a -ing public site protect you from being arrested by miniluv?
It’s public, you want everyone to see the cat photos, that’s why you set up the site. On the contrary, SSL certs mean another party through which miniluv can track you. They prove or are supposed to prove identity not hide it.
Sorry that wasn’t particularly clear, I was taking more about the general advantageous nature of normalising encryption.
WRT to another party to track you, one of the benefits of LE is that you only need to provide proof of domain ownership (eg dns txt) so the only tie back to you is whatever information you give to the registrar that you have to provide anyway.
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).
> 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.
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.
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.
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.
> The CEO at my last company (2022) refused to use Let's Encrypt because "it looked cheap to customers".
Spoken like a true dinosaur. How can a certificate based on open, public and proven secure protocols be cheap?
> So my question: has anyone actually commented to you in a negative way about using Let's Encrypt?
No, but I personally judge businesses which claim to be tech savvy if they don’t have an ACME issued certificate, because to me that instantly shows I’m not dealing with someone who has kept up with technology for the last 10 years.
Yeah you've correctly identified the mindset there that the leadership had in my case. They didn't want to upgrade to an in-support version of MySQL either...
I only hear justified praises of letsencrypt. Also thanks to the EFF and developers of certbot, which massively improved the toolchain around certificate deployment. Not the favorite activity for admins, but this made processes like certificate renewal/revokation much more convenient.
I think the portion of users that check a certificate after the browser treated it as secure is well smaller than 1%, probably well below 0.1%. And I guess these TLS connoisseurs have a positive inclination to letsencrypt as well.
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.
I have also heard a negative about it being somehow "cheap" and we can "afford" a proper wildcard for our website from managers back in the day, like, few years ago. Never mind the hours wasted every year changing that certificate in every system out there and always forgetting a few.
Also a valid point from security people is that you leak your internal hostnames to certificate transparency lists once you get a cert for your "internal-service.example.com" and every bot in existence will know about it and try to poke it.
I solved these problems by just not working with people like that anymore and also getting a wildcard Let's Encrypt it certificate for every little service hosted - *.example.com and not thinking about something being on the list anymore.
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…
Modern browsers are going out of their way to hide every bit of information about the website (including even the URL) — so I don't know how these customers would actually even find out what CA issued the certificate.
In Safari, I don't even know how to find that information anymore. When I want to check expiration dates for my own sites, I start Firefox.
It’s the symbol to the left of the URL > Show Certificate. They even make it available on iOS Safari (Page Info > Connection Security Details), but if it’s expired, you’ll know by the big red warning page.
I don't have that :-) — what I see when I click the thingamajig on the left side of the URL is a menu with "Hide Distracting Items", "Zoom", "Find" and "Website settings".
Well, either it isn't there in my Safari (macOS 15.7.2) or I can't find it.
I have found "Connection Security Details…" in the "Safari" menu, though. But my point still stands: average users won't see any certificate information without serious effort.
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.
Not only do they just allow you to import any certificate you want, but they literally have a button on the panel to get one from Let's Encrypt for free.
If you read into Web.Com, yes, they are quickly becoming a monopoly on host companies. They do not disclose many of the hosting companies they now own.
If you can find a company that allows clients to install Let's Encrypt Certs on shared hosting, please let me know.
Yeah, fair point. I have not used shared hosting for a long time now (static sites are easy/free to host, and dynamic ones don't play well with shared hosting), so I didn't know the Web.com story.
I used DreamHost in the past and they had a configuration option in their control panel to automatically install and maintain a Let's Encrypt certificate on your behalf [1]. If you are stuck with Web.com you may consider using a reverse proxy/CDN such as CloudFlare.
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 used to deal with a couple people who were against any automatic or free certs. It was part of their jobs to procure the annual certs, look them over, present them to the developers and maintain automatic checks to regularly inspect the certificates. This was partly how they justified their jobs, but they relished the ceremony and being able to tell developers what to do, even if only for a few minutes a year. They repeatedly blocked introduction of LetsEncrypt.
Just checked. They’re still using that manually installed cert!
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
has anyone actually commented to you in a negative way about using Let's Encrypt? I couldn't imagine, but curious on others' experiences.
One thing I heard recently which might be a valid point - that LE is based in US, which makes it a subject to US laws. Read from that what you will though.
No matter where they were based they would be subject to US laws since they offer services to US peoples. (similar to how everyone here always points out that US companies are subject to EU laws if they offer services in the EU).
Why is that problematic? They don't have your private keys and their "level of access" is equivalent to any other certificate authority that your browser trusts.
> Why is that problematic? They don't have your private keys and their "level of access" is equivalent to any other certificate authority that your browser trusts.
Let's Encrypt could stop issuing certificates to you, if the administration decided that necessary. This would at least disrupt whatever you were serving.
Not that I think this is likely, only possible.
I think LE clealy demonstrated the need for a accessible free ACME authority. But it is high time for more alternatives (EU and China at least).
FWIW: Everything around public infrastructure should be run decentralized not-for-profit using national resources. Things like DNS Registrars are silly if you think about it. They just buy it from TLD holders anyway.
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.
> 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.
I think the best analogy for this are scams. Once a scammer finds a mark they'll pay, there's a desire to soak them for as much as they'll bear.
EVs are not a scam per-se, but they also don't add any value. 80% of the world already figured that out, do by definition if you are asking you are in the bottom 20%.
Now I get you were in the process of migration, but that's an edge case. In a normal case if you go around asking to buy a wildcard EV, you basically have a sign saying "fleece me".
So yeah, there's still a market for people wanting to throw money at CAs, even in these comments you'll see some. And management types are especially prone to "sounds expensive, must be good" logic when spending other people's money.
I think you've left out the ecosystem of semi-scam, without that the decisions look less logical.. If you go and add a private rootCA to all your servers there are risks. You can convince yourself the risks are covered, you can convince a highly qualified security analyst. Can you convince a business intern with a checklist hired by a certification firm that underbid the one with specialists? 30K to engage with no one on the topic starts to look ideal.
I was replying in the context of what you were replying to where they either could spend 30k or make a private root. I'm not sure they were actually using EV but for it to cost $30k and given the topic of the thread it seems plausible they were using some technicality on EV or similar to reduce public domain validation requirements.
> 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.
I remember getting a 10(I think?) year wildcard cert in ~2009. I get why that changed and, while it's not great for my personal usage, I see the value for the majority of the web, but the story definitely looked more like "we decided to make TLS so difficult you have no choice but to automate" when it came time to finally replace it.
If there were two things which would make me happier with it all it'd be 10x rate limits on Let's Encrypt (so you don't have to even think of it when you screw something up/test different things for a week) and some more extension/standardisation of ACME on an internal facing service talking with an external DNS server to do the DNS challenge more easily in this scenario.
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.
For public websites most probably don't even need to touch cron as Apache/Caddy/NGINX/Traefik have built-in options these days. The only time I run something like a cron task is for certain internal IoT type certs.
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.
American IT Mafia? That provides free certificates? You'd think setting up renewal would be less of a hassle than dealing and paying CAs even if it's once every 3 years, so that would be a rather benevolent mafia. Which of those CAs went out of business by the way?
Do you think Let's encrypt is less popular outside the US?
StartSSL, WoSign were the ones I've used. Very convenient services, much more convenient, compared to this certbot insanity.
I think that the rest of the world does not have much choice, because US uses their IT superiority to force political decisions to the rest of the world. I experienced that first-hand. When my country wanted to implement MITM to improve Internet usability for their citizens, US companies blacklisted government root certificate which disrupted this scheme and forced my country to roll back this plan. Now I have lots of websites completely blocked, instead of more careful and precise per-page blocking that would only be possible with MITM.
Hopefully, over time, China and Russia will destroy this superiority and will provide viable alternatives.
I just explained that. Basically government wants to block some specific webpage, say https://en.wikipedia.org/wiki/Nursultan_Nazarbayev. Without MITM, they'll end up with blocking the entire en.wikipedia.org domain, so citizens will lose access to a lot of information. With MITM, they'll be able to target precisely one page and I can read any other wikipedia article without issues.
And with MITM they can read literally all of your private internet traffic… That seems like a significantly worse tradeoff to just using a VPN to browse Wikipedia.
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.
As a sysadmin in 2020 - 2024 time frame I used to do that all the time at my previous job, got a strong openlssl cli game going whenever needed to generate a new csr for existing key or new key and shovel an exact amount of SANs into the CSR too. Lot of time wasted. There were also a certain set of customers for which we managed systems and they insisted for it to be done this way as something free on the internet is not to be trusted. Oh well, strange times.
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.
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.
Look at OpenAI - where there’s a will (and an army of lawyers), there’s a way. That said, I don’t think any of the big tech orgs would be interested in acquiring them. Google and Amazon even already have their own public CAs that are in the major trust stores.
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.
> That's reasonably close to a technical guarantee, if you ask me.
Until the feds show up like:
Okay, either you block these domains, or you're going to jail:
politician-x-did-something-bad.com
politician-y-is-corrupt.com
country-z-did-crimes-against-humanity.com
political-opposition-party-w-homepage.com
blog-that-mentions-any-of-the-above.com
... (rest of the list that works for 10 or 100'000 domains)
I complained about the centralization that reminds me of Cloudflare in another place, but in general the more distributed this sort of infra is, the better. Both for technical reasons, as well as political ones. In general, one can plan around potential risks like "Okay, what if I assume that this infra of mine is actually running in Russia and the govt hates me and I need to migrate."
VPSes and domains are pretty easy to move across country borders (e.g. moving from NameCheap to INWX and from something like AWS to Hetzner, at least for simple setups), less so when you don't control the CA.
Yes, but that's still a pre-defined list. They can't say "block every website mentioning politician x doing bad things from getting a cert", because that'd be impossible to validate.
The feds are left playing whack-a-mole, and getting the right paperwork to block each new domain popping up is probably going to take a few weeks. Besides, at that point they could also force the .com operator to do the same, could they not?
I do agree that it would be better if LE was more distributed, though. Having a legally-independent second nonprofit running the same software in Switzerland or something would prevent LE from turning into a massive target for the US government.
Why would the feds bother with let’s encrypt in this situation when it would make way more sense to just go to ICANN and get the domain names unregistered. They already do that all the time.
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".
A lot of thd new APIs have to do with accessing hardware. Camera, Microphone, Serial ports (currently experimental) etc.
Given how easy a MITM attack to injection JavaScript or HTML into insecure pages is, a world where insecure pages had access to hardware makes that hardware very vulnerable.
Even though all you'd be doing is reading some random blog etc.
To those who still think serving HTTP is some sort of principled stand, just be aware that injecting malware onto your page at delivery time is pretty trivial. Quite honestly, and I mean this in a constructive way, it doesn't signal "principles" it signals "incompetence".
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 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.
We actually spent some time making sure that we weren't going to run into problems with browsers. However, as the OP points out, because LE had a cross-signature from an existing CA, browsers didn't have to any positive action to make LE certificates work. This was absolutely essential to getting things off the ground.
Oh, I know you all did and I remember the cross-signing. I worried that you'd get slapped down somehow, that the crappy cert companies would find a way to stop/reverse it, that the project would fizzle out, etc. I thought it was cool as hell but it seemed something so clearly good couldn't stay good but you all have only gotten better over time.
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.
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?
Literally just got bit by this. I added a wildcard domain to a cert servicing multiple sites. Apparently the verification process for wildcards is more onerous and even when you have it working it wont renew in the same way as a normal cert. It requires specific workarounds based on your dns provider. Appreciative that we moved away from paid certs that required manual work to renew every year but this feels like a mismanaged backslide.
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
Seems longer than 10 years ago? But hey... Let's Encrypt absolutely changed the game... TLS and certificates were a huuuuuge PITA and expensive... we only used them when money was moving around online and they were slow most times. It was also a process to add one, update one, etc. I remember not trusting it at first because it was so easy lol.
THANK YOU Let's Encrypt... you made us all more sane, saved time, and secured us all up too. Firm handshakes.
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.
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.
Thank you Let's Encrypt, together with the acme.sh , caddy and the whole ecosystem for TLS.
You simply cannot emphasize the information security enough if all your Internet traffic is audited, censored and manipulated by a number of adversaries supported by (authoritarian) governments and what not.
Besides, I don't use wildcard certs. I use caddy to reverse proxy a number of self-hosting things, and manually assign domain names to each of them. Caddy can handles many certs just fine.
I plan to make use of a Caddy on a cheap VPS to expose some self-hosted services behind Tailscale, behind Caddy will be a mix of Raspberry Pi and a occasional hosted VPS when trying things out.
How's your experience with Caddy regarding memory usage? I am currently serving a static site with 500 MB, but this is with very low to zero traffic.
Congratulations to Let’s Encrypt. I do wish there was something akin to them for code signing. OV and EV certificates are out of reach for many indie devs.
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.
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.
"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."
"Let’s Encrypt was created through the merging of two simultaneous efforts to build a fully automated certificate authority. In 2012, a group led by Alex Halderman at the University of Michigan and Peter Eckersley at EFF was developing a protocol for automatically issuing and renewing certificates. Simultaneously, a team at Mozilla led by Josh Aas and Eric Rescorla was working on creating a free and automated certificate authority. The groups learned of each other’s efforts and joined forces in May 2013.
...
Initially, ISRG had no full-time staff. Richard Barnes of Mozilla, Jacob Hoffman-Andrews of EFF, and Jeff Hodges (under contract with ISRG) began developing Let’s Encrypt’s CA software stack. Josh Aas and J.C. Jones, both with Mozilla at the time, led infrastructure development with assistance from Cisco and IdenTrust engineers. ISRG’s first full-time employee, Dan Jeffery, joined in April 2015 to help prepare the CA’s infrastructure for launch. Simultaneously, James Kasten, Peter Eckersley, and Seth Schoen worked on the initial ACME client (which would eventually become Certbot) while at the University of Michigan and EFF. Kevin Dick of Right Side Capital Management, John Hou of Hou & Villery, and Josh Aas constituted the team responsible for completing a trusted root partnership deal and signing initial sponsors."
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.
DANE could've worked as an alternative to LetsEncrypt, if all CAs had refused to cross-sign it and essentially killed it for years until everyone's cert stores had caught up.
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.)
The reliable way is DoH/DoT that are rapidly going to become the standard. They don't suffer from fragmentation issues, so they can reliably get the DNSSEC chain.
Or maybe the next step is putting the stapled response into the certificate. Perhaps it can even be used by Let's Encrypt as a part of the challenge, providing the incentive to get it right.
The original stapled DNSSEC experiment was suffering from misaligned incentives. CAs didn't care at all about it.
Stapling needs to be an intermediary step, in parallel with existing trusted CAs. When stapling was tried first in Chrome, no CAs were interested in setting up something like Let's Encrypt, using DNSSEC to automatically issue certificates.
No it doesn't? Why would it? I'm confused by what it is you think CAs have to do with DNSSEC stapling. CAs are absolutely not the reason DANE staples failed.
Staples failed because they couldn't work alone. They were considered a replacement for completely self-signed certificates.
That's why the committee tried to mandate the stillborn pinning idea.
The option to use stapling in addition to a CA-signed certificate was not really considered. After all, if you paid for a CA-signed cert then why would you bother with stapling?
It does? The idea was to staple the DNSSEC chain to the TLS, so that clients wouldn't have needed to do the whole DNS pointer chasing themselves.
The problem is that the MITM-ing adversary can just strip the DNSSEC chain and then replace the certificate. Without having a DNSSEC-enabled resolver, the client can't detect that. So stapling doesn't provide any additional security over the self-signed certificates.
The only proposed fix was to pin the DNSSEC-enabled URLs, using TOFU (Trust On First Use). And nobody wanted that.
There was no real discussion about adding the stapling in _addition_ to CA-signed certificates. Because at that time there was no point in doing that, no CA wanted to provide free signing.
This is changed now. The self-signed certificates are no longer status quo.
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).
For someone who runs a small personal website and uses LE to secure this + some web exposed services, could you explain how this is different/better than acme-dns-certbot?
WebPKI also suffers from an inability to properly do delegation. It's not possible for me to create an intermediary certificate valid only for *.mycompany.com
If I want to use WebPKI, I have to either expose every host inside my company to everyone (via CT transparency logs) or use a wildcard certificate. And wildcard certs allow attackers to impersonate anything within my domain, if they get access to just one host.
X.509 technically supports name constraints ( https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 ), but its implementation was inconsistent. In particular, some implementations did not apply it to the Common Name. Fortunately, Common Name is on the path to deprecation.
CT logs do allow enumeration, but avoiding that is just security through obscurity. WebPKI is intended for publicly-accessible hosts, so hopefully you already have some kind of firewall in place to protect them! If you want to avoid enumeration of internal-only hosts: just use your own self-signed root cert. CT logs are a crucial part of protecting against rogue CAs, so don't expect that to go away any time soon.
With ACME most of the delegation issues have pretty much been solved. Publicly-accessible hosts can easily get a cert - if and only if the domain resolves to that host. Want even stricter enforcement? Nobody's stopping you from writing an ACME proxy which only forwards requests from known-good hosts to LE & friends.
> CT logs do allow enumeration, but avoiding that is just security through obscurity.
Well, yes. There are also other issues, like rate limits. Some companies have hundreds of thousands of hosts (some virtual) and requesting certificates for all of them might be problematic.
> If you want to avoid enumeration of internal-only hosts: just use your own self-signed root cert.
This becomes increasingly problematic, as browsers start relying on DoH/DoT, or making it more difficult to enroll custom root certs.
> Nobody's stopping you from writing an ACME proxy which only forwards requests from known-good hosts to LE & friends.
I actually tried that. LE uses multiple viewpoints to resolve the challenges, so you need to open your internal DNS resolvers/HTTPS to basically all the world. Or play with the horror of split-horizon DNS.
I probably downloaded terabytes of data from the internet unnecessarily because https everywhere makes makes it prohibitively complicated to setup local caching proxy.
No to mention time lost waiting for downloads to finish.
I'll never understand why caching proxy is not a default part of every OS.
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.
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.
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.
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.
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.
The pathetic part of EVs is that they should have been issued by whatever the business register/regulator is in the country of issue.
Not some arbitrary group like D&B etc.
The US/other countries should have ensured that each state/registration area had an appropriate cert to sign with.
It should be part of my company's annual registration/reporting expenses that they issue the appropriate certificate for "*.<mycompany>.<2LDs>.<gTLD>", signed by them (and by the TLD root cert of the nation of registration).
Companies probably prefer to use "apple.com" instead of "apple-computer-inc.co.ca.us". It's even worse if you want to use truly unique identifiers like ISIN, LEI, DUNS, or IBRN, as that means something closer to "US0378331005.com".
The point is that I (as an Australian) don't trust a private organization like D&B any more than any other organization.
Corporate existence is dependent on some form of government regulator granting the corporation existence.
If EVs are/were a good idea (debatable at best), then having those EVs issued by the same government regulator that allows corporates to use trademarks etc makes sense.
If "apple" is a trademark for computers, then Apple Computer Inc as the owner of that trademark should get an EV issued by the regulator of trademarks.
Of course, the URL should be apple.com.us or apple.tm.us.
The historical error was not requiring the US to move to 2LDs for it's com/org/net/gov/mil etc domains.
Note this is for corporate entities, none of which exist outside regulatory environments.
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.
Cloudflare: "Oh no, we can't have that much centralization, that's horrible, just think of the impact outages have!"
Let's Encrypt: crickets
Obviously I use LE myself and like what they do, and even in the example above some downtime would have less of an impact than Cloudflare would (due to renewals being less time sensitive), I'm just surprised that there aren't like 5 other orgs that do the same at scale, like an EU based one for example. If there's a lot of domain registrars, why doesn't every single one of them have ACME compatible services?
I think there was ZeroSSL but I vaguely remember something scummy about upsells there a few years back.
If LE goes down for a week you can't deploy new certs, but your existing ones will work, as you renew them a few weeks before expiry anyway
That also gives you enough time to change to get your certs from elsewhere
As you mention zerossl exista, and I think google GCM will give you free certs too.
Globalsign has an ACME interface for paying customers, although I'm told it has issues (you have to rotate keys manually every X days / N certificates)
There's no (current) plans to drop below 45 day certificates with an expected renewal with 2 weeks to go.
I agree if cert lifetimes drop towards week long then it becomes problematic. A sensible thing at that point is to ensure you can issue certificates from different CAs on different underlying stacks, in the same way you use multiple DNS servers
A couple of years ago, I went through the process of signing a kenel minifiter that I wrote for our endpoint-security product. It was complicated, to put it mildly.
Imagine if we had a similar process for websites! Thanks Let's Encrypt.
You might want to be more specific about the meaning of "between" here. It's not a cryptographic MITM attack, and if it ever facilitated someone else in performing one, that should be detectable.
Not sure if there is a point to "keep things in Europe" when it come to certificate authority.
- LetsEncrypt don't have the private key tied to your certificate
- Any of the Certificate Authorities could potentially emit unauthorized certificate
Your only protection for all of these problems is HPKP. If you prefer to keep things in Europe, keep that pinned private key in Europe, but the rest doesn't matter.
That said, it's pretty nice that LetsEncrypt forced the ACME protocol on this industry. Not only it create redundancy with mostly interchangeable alternatives but before ACME, there was no way to fully automate certificate provisioning cleanly.
Just to clear up one point -- Let's Encrypt did not at all force ACME on the industry. We deliberately took it to the IETF so that we could get input from more parts of the industry (including some major refactors!). Instead of pressure from Let's Encrypt, I would attribute its success to the open process of the IETF, the awesome open-source community that made great ACME software (shoutout to Matt and Caddy!), and the resulting pressure on CAs for a better user experience from users and customers.
I didn't express myself well but what I meant by force is that by building a standardized to automate way manage certificate, ACME imposed itself and became mandatory.
Previously, most CA had no programmatic way to order certificate, it was all done manually.
As far as I know, the only providers with that would let you automate certificate provisioning at the time where Comodo, GlobalSign and Digicert.
At first none of them were warm at the idea of providing an ACME endpoint. I'm assuming part of it is the cost of implementing it but they probably liked the stickiness of their custom APIs too tied to million dollars contracts.
Nowadays they all implement ACME. At some point, they where effectively forced to implement it to acquire new customers and keep their existing base around because nobody would accept poorly designed custom made protocol anymore.
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.
I think the rebuttal to the CEO today is really very simple.
a) How many of the sites you visit everyday have DV and how many have EV certificates?
b) Name any site at all, that you have visited, where your behavior or opinion has changed because of the certificate?
In truth the green-bar thing disappeared on mobile long before desktop (and in some cases it was never present.)
In truth if you polled all the company staff, or crumbs just the people round the boardroom table (probably including the person complaining) a rounding error from 0 could show you how to even determine if a cert was DV or EV.
EV could have an inspector literally visit your place of business, and it would still have no value because EVs are invisible to site visitors.
it used to be that EV certs had higher insurance if there was a leak of the intermediate private keys and lost data.
Since nobody ever actually leaked an intermediate private key for a CA, people don't recognise the value.
If we had lost payment card information through MITM, we would have been liable for a lot more money.
That was the business justification for EV back when I was doing major ecommerce stuff.
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.
> 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
IMO it would make sense to tie into the trademark system. Allowing companies to build a brand reputation and protect it from impersonators is literally the whole point of that part of our legal system.
Imagine if only the owner of the McDonald's trademark could issue a certificate which displays the McDonald's name and logo, for example.
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
I do believe Dun & Bradstreet was it. Thanks!
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.
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.
How many CAs do you think there are? How many countries do you think they operate in?
Maybe we could augment the old EV cert indicator with a flag icon, but now there's yet another thing that users have to pay attention to. Maybe the CA/Browser Forum could run a clearinghouse for company names, but apart from trivial examples, there might very well be legitimate cases of two companies with the same name in the same country, just in different industries. Now do we augment the indicator with an industry icon too? Then the company changes its name, or forms a subsidiary relationship, or what have you. Now do we need to put "Meta (formerly Facebook)" or "Facebook (division of Meta)" etc. in the name?
There's just so many problems with the EV cert approach at Internet scale and they're largely beyond solvable with current infrastructure and end-user expectations.
How do you decide when a company is "well-known"? What's going to happen when there are two well-known companies with the same name or a very similar name? What if a well-known company in country A expands to country B, where a well-known company with that name (but active in a different industry) already exists? How are you going to deal with subsidiaries which are both legally and organizationally separate? Who gets to keep the EV when a company spins off a division but both parts retain the same name?
"Use human judgement" might work for trivial examples of fraud, but it quickly breaks down once you try applying it to the real world. Besides, how are you going to apply the same "human judgement" across hundreds of employees at dozens of CAs? If anything, you're just begging to get sued by large corporations whose complex situation fell on the wrong side of your human judgement.
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.
Are company names even unique within the UK? Sure, there can be only one bank named Barclays because of trademark laws, but can't there be a company in a different sector with the same name? Like Apple the computer business vs Apple the record company?
Or don't you have small local businesses (restaurants, pubs, stores) with duplicate names as long as they're in different locations? I know here in Flanders we have, for example, tens if not more places called "Café Onder den toren" (roughly translated as "Pub beneath the tower"). Do all local businesses in the UK have different names?
That's not exactly a great example, is it? "Barclay" even has a disambiguation page on Wikipedia, because it's a reasonably common Scottish surname.
For example, there used to be a Scottish company constructing steam locomotives which traded under the "Barclays & Co" name - because it was founded by one Andrew Barclay. There's also the Barclay Academy secondary school, and a Bentley dealer which until recently operated as Jack Barclay Ltd.
And that's just the UK ones! Barclays operates internationally, which means they want "barclays.com", so suddenly there's also Barclay-the-record-label, Barclay-the-cigarette-brand, Barclay-the-liquor-brand, Barclay College, golf tournament The Barclays, Barclays Center (whose naming rights were bought by the bank, but they of course want their own completely distinct website), Barclay Theatre, three Barclay Hotels.
Of course there's also all the stuff under "Barkley", "Barkly", "Berkley", and probably a dozen other variations just waiting to be used to scam dyslexic Barclays custumers.
Barclays used to operate under Barclays Bank PLC. IMO, if disambiguation was problematic online they would have reverted back to that name.
You bring up good points, but I don't think that company naming has to be 100% proof against confusion, it's just one more helpful thing for consumers to identify whom they are doing business with.
In the case of close names like "Barkley", if they're doing banking, there is probably a trademark case against if they actually use it to confuse customers.
Intrestingly enough, "Barkley Holdings" was registered by competing bank HSBC: https://find-and-update.company-information.service.gov.uk/c...
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.
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.
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.
Trademarks are industry-specific. Ordinarily, a painting company called Stripe isn't going to cause confusion with the payment platform Stripe, so there's no reason to deny the trademark.
It's how you end up with both Apple Corps (the Beatles' record label) and Apple Computer (the tech company). They've been involved in quite a few lawsuits over the years, mostly because the tech company decided to expand into the multimedia business.
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.
An apt metaphor, … until I read recently on HN that storage on SSDs only last 1 year when unplugged.
https://news.ycombinator.com/item?id=46038099
Let's Encrypt certificates last even only 90 days when unplugged.
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.
> My router _shouldn't_ have a globally recognized certificate, because it's not on a publicly visible host.
If you're not encrypting local network traffic then any rogue device on that network can decide to intercept it and steal your admin password. That's one of the biggest reasons why we adopted HTTPS in the first place - whether a host is public or not isn't relevant.
It doesn't need a "globally" recognized certificate signed by a public CA, self-signed ones are fine. At home I manage mine with XCA. I have a root CA that's installed on all of my devices, with name constrains set to ".internal", ensuring it can't be used to sign certificates for any other domains.
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.
Android is pretty easy, you just add it to the keystore and that's it. I've had my own CA long before Let's Encrypt, but now mostly only use it for non-public devices that can't easily use Let's Encrypt (printers, switches, etc).
You can add it to your user CA store, but no app will trust it since it's treated differently from the system CA store, which you can't modify without root or building your own ROM. In effect it is out of reach for most normal users, as well as people using security focused ROMs like Graphene, when ironically it can improve security in transit in many cases.
It's technically possible to get any Android app to accept user CAs. Unfortunately it requires unpacking it with apktool, adding a networkconfigoverride to the XML assets and pointing the AndroidManifest.xml to use it. Then restitch the APK with apktool, use jarsigner/apksigner and finally use zipalign.
Doesn't need a custom ROM, but it's so goddamn annoying that you might as well not bother. I know how to do these things; most users won't and given the direction the big G is heading in with device freedom, it's not looking all that bright for this approach either.
I mean it works fine for me on Chrome
A long time ago when I was playing with rolling my own PKI, each of Android, iOS, Chrome, Firefox, and even Internet Explorer allowed me to install a root CA by opening the .crt file. From what I remember, iOS popped up some warnings and added the cert as part of a profile, but it did work.
I know things like MDM/Intune/Group Policy/etc and such can A) faciliate doing this on a large number of devices and B) prevent users from doing this on their own.
Does this not work anymore?
I don't want to trust my own root CA as I don't trust myself to keep it secure.
I want to important it only for a specific set of domains. "Allow this rootca to authenticate mydomain.com, addmanager.com, debuggingsite.com", which means even if compromised it won't be intercepting mybank.com
You can absolutely do that with name constraints extension set on the root CA certificate. You should verify compatibility but it's pretty universally supported on modern browsers and consumer devices last I checked.
- "critical" ensures that any clients who don't understand this extension fail the certificate validation outright instead of ignoring it.- "DNS:.iso1631.internal" limits the scope to all subdomains of the given domain, e.g. "www.iso1631.internal"
https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
If you generate the root CA sure. However name constraints aren't well supported.
A far better option would be to allow me, the user, to do this in the user agent. I can import my mitm cert and today I can trust it for "abc123.com" and point that to something I want to access in that manner for some reason, but tomorrow simply toggle that trust off.
If I find that I want to use a specific website and want to do something with the traffic, then I could point that DNS to my middle-box and turn that on in my browser. With name constraints I'd have to regenerate the root certificate with the new domain, and then re-import it.
the entire concept of the name constraints puts the power into the CA issuing person rather than the user.
Where are you finding that name constraints aren't supported? I've only come across that on embedded/IoT devices. They work fine for me across Firefox and Chrome on Linux, on Android, and they are supposed to work fine on Apple devices too.
> If I find that I want to use a specific website and want to do something with the traffic...
I agree but that's a different problem. If you just need a certificate for your router and some internal services (the original discussion), you can do that using an internal root CA and you have nothing to worry about as long as you using name constraints.
On IoT devices without nameConstraints support I just use an alternative CA certificate without name constraints (same key, different extensions).
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
Yes, ESP8266. FWIW, https worked when bluetooth was disabled.
> 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?
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).
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…”
Wrong metaphor though?
How does SSL on a -ing public site protect you from being arrested by miniluv?
It’s public, you want everyone to see the cat photos, that’s why you set up the site. On the contrary, SSL certs mean another party through which miniluv can track you. They prove or are supposed to prove identity not hide it.
Sorry that wasn’t particularly clear, I was taking more about the general advantageous nature of normalising encryption.
WRT to another party to track you, one of the benefits of LE is that you only need to provide proof of domain ownership (eg dns txt) so the only tie back to you is whatever information you give to the registrar that you have to provide anyway.
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).
> 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.
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.
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.
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.
> The CEO at my last company (2022) refused to use Let's Encrypt because "it looked cheap to customers".
Spoken like a true dinosaur. How can a certificate based on open, public and proven secure protocols be cheap?
> So my question: has anyone actually commented to you in a negative way about using Let's Encrypt?
No, but I personally judge businesses which claim to be tech savvy if they don’t have an ACME issued certificate, because to me that instantly shows I’m not dealing with someone who has kept up with technology for the last 10 years.
Yeah you've correctly identified the mindset there that the leadership had in my case. They didn't want to upgrade to an in-support version of MySQL either...
I only hear justified praises of letsencrypt. Also thanks to the EFF and developers of certbot, which massively improved the toolchain around certificate deployment. Not the favorite activity for admins, but this made processes like certificate renewal/revokation much more convenient.
I think the portion of users that check a certificate after the browser treated it as secure is well smaller than 1%, probably well below 0.1%. And I guess these TLS connoisseurs have a positive inclination to letsencrypt as well.
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.
I have also heard a negative about it being somehow "cheap" and we can "afford" a proper wildcard for our website from managers back in the day, like, few years ago. Never mind the hours wasted every year changing that certificate in every system out there and always forgetting a few.
Also a valid point from security people is that you leak your internal hostnames to certificate transparency lists once you get a cert for your "internal-service.example.com" and every bot in existence will know about it and try to poke it.
I solved these problems by just not working with people like that anymore and also getting a wildcard Let's Encrypt it certificate for every little service hosted - *.example.com and not thinking about something being on the list anymore.
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…
Modern browsers are going out of their way to hide every bit of information about the website (including even the URL) — so I don't know how these customers would actually even find out what CA issued the certificate.
In Safari, I don't even know how to find that information anymore. When I want to check expiration dates for my own sites, I start Firefox.
It’s the symbol to the left of the URL > Show Certificate. They even make it available on iOS Safari (Page Info > Connection Security Details), but if it’s expired, you’ll know by the big red warning page.
I don't have that :-) — what I see when I click the thingamajig on the left side of the URL is a menu with "Hide Distracting Items", "Zoom", "Find" and "Website settings".
For me it’s hidden behind a kebab menu in that thingamajig you described.
Well, either it isn't there in my Safari (macOS 15.7.2) or I can't find it.
I have found "Connection Security Details…" in the "Safari" menu, though. But my point still stands: average users won't see any certificate information without serious effort.
Ah no, i am on iOS 26.
No! Let's encrypt is easily the best thing that's happened for a secure internet the last 10 years.
And equally as much for a centralized internet...
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.
I'd be happy to hear about a traditional hosting company that allows clients to install lets Encrypt certs if you can name any...
Most of my clients don't have budgets big enough for cloud hosting.
DreamHost allows it.
Not only do they just allow you to import any certificate you want, but they literally have a button on the panel to get one from Let's Encrypt for free.
> 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.
If you read into Web.Com, yes, they are quickly becoming a monopoly on host companies. They do not disclose many of the hosting companies they now own.
If you can find a company that allows clients to install Let's Encrypt Certs on shared hosting, please let me know.
Yeah, fair point. I have not used shared hosting for a long time now (static sites are easy/free to host, and dynamic ones don't play well with shared hosting), so I didn't know the Web.com story.
I used DreamHost in the past and they had a configuration option in their control panel to automatically install and maintain a Let's Encrypt certificate on your behalf [1]. If you are stuck with Web.com you may consider using a reverse proxy/CDN such as CloudFlare.
[1] https://help.dreamhost.com/hc/en-us/articles/216539548-Addin...
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 used to deal with a couple people who were against any automatic or free certs. It was part of their jobs to procure the annual certs, look them over, present them to the developers and maintain automatic checks to regularly inspect the certificates. This was partly how they justified their jobs, but they relished the ceremony and being able to tell developers what to do, even if only for a few minutes a year. They repeatedly blocked introduction of LetsEncrypt.
Just checked. They’re still using that manually installed cert!
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
has anyone actually commented to you in a negative way about using Let's Encrypt? I couldn't imagine, but curious on others' experiences.
One thing I heard recently which might be a valid point - that LE is based in US, which makes it a subject to US laws. Read from that what you will though.
No matter where they were based they would be subject to US laws since they offer services to US peoples. (similar to how everyone here always points out that US companies are subject to EU laws if they offer services in the EU).
Why is that problematic? They don't have your private keys and their "level of access" is equivalent to any other certificate authority that your browser trusts.
> Why is that problematic? They don't have your private keys and their "level of access" is equivalent to any other certificate authority that your browser trusts.
Let's Encrypt could stop issuing certificates to you, if the administration decided that necessary. This would at least disrupt whatever you were serving. Not that I think this is likely, only possible.
I think LE clealy demonstrated the need for a accessible free ACME authority. But it is high time for more alternatives (EU and China at least). FWIW: Everything around public infrastructure should be run decentralized not-for-profit using national resources. Things like DNS Registrars are silly if you think about it. They just buy it from TLD holders anyway.
I have worked at companies that refused to use LetsEncrypt for the same reason.
> Let's Encrypt was _huge_ in making it's absurd to not have TLS
I still find it too much of pain in the ass to deal with to justify for my personal stuff. Easier to just click through the warning every time.
Old browsers on old hardware without its CA baked in.
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.
> 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.
I think the best analogy for this are scams. Once a scammer finds a mark they'll pay, there's a desire to soak them for as much as they'll bear.
EVs are not a scam per-se, but they also don't add any value. 80% of the world already figured that out, do by definition if you are asking you are in the bottom 20%.
Now I get you were in the process of migration, but that's an edge case. In a normal case if you go around asking to buy a wildcard EV, you basically have a sign saying "fleece me".
So yeah, there's still a market for people wanting to throw money at CAs, even in these comments you'll see some. And management types are especially prone to "sounds expensive, must be good" logic when spending other people's money.
I think you've left out the ecosystem of semi-scam, without that the decisions look less logical.. If you go and add a private rootCA to all your servers there are risks. You can convince yourself the risks are covered, you can convince a highly qualified security analyst. Can you convince a business intern with a checklist hired by a certification firm that underbid the one with specialists? 30K to engage with no one on the topic starts to look ideal.
I'm not sure the alternative is sef-created RootCA. (But perhaps I don't understand the underlying case.)
To me, the alternative is just a LE cert. Can do wildcards via DNS challenge.
I was replying in the context of what you were replying to where they either could spend 30k or make a private root. I'm not sure they were actually using EV but for it to cost $30k and given the topic of the thread it seems plausible they were using some technicality on EV or similar to reduce public domain validation requirements.
> 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.
I remember getting a 10(I think?) year wildcard cert in ~2009. I get why that changed and, while it's not great for my personal usage, I see the value for the majority of the web, but the story definitely looked more like "we decided to make TLS so difficult you have no choice but to automate" when it came time to finally replace it.
If there were two things which would make me happier with it all it'd be 10x rate limits on Let's Encrypt (so you don't have to even think of it when you screw something up/test different things for a week) and some more extension/standardisation of ACME on an internal facing service talking with an external DNS server to do the DNS challenge more easily in this scenario.
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.
Literally all you have to do is configure a cronjob to renew the cert?
I've got a website I build for a friend running that I haven't touched in 5 years TLS-wise, never had any issues.
For public websites most probably don't even need to touch cron as Apache/Caddy/NGINX/Traefik have built-in options these days. The only time I run something like a cron task is for certain internal IoT type certs.
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.
American IT Mafia? That provides free certificates? You'd think setting up renewal would be less of a hassle than dealing and paying CAs even if it's once every 3 years, so that would be a rather benevolent mafia. Which of those CAs went out of business by the way?
Do you think Let's encrypt is less popular outside the US?
StartSSL, WoSign were the ones I've used. Very convenient services, much more convenient, compared to this certbot insanity.
I think that the rest of the world does not have much choice, because US uses their IT superiority to force political decisions to the rest of the world. I experienced that first-hand. When my country wanted to implement MITM to improve Internet usability for their citizens, US companies blacklisted government root certificate which disrupted this scheme and forced my country to roll back this plan. Now I have lots of websites completely blocked, instead of more careful and precise per-page blocking that would only be possible with MITM.
Hopefully, over time, China and Russia will destroy this superiority and will provide viable alternatives.
In what way do MITM certificates "improve Internet usability for their citizens"?
I just explained that. Basically government wants to block some specific webpage, say https://en.wikipedia.org/wiki/Nursultan_Nazarbayev. Without MITM, they'll end up with blocking the entire en.wikipedia.org domain, so citizens will lose access to a lot of information. With MITM, they'll be able to target precisely one page and I can read any other wikipedia article without issues.
And with MITM they can read literally all of your private internet traffic… That seems like a significantly worse tradeoff to just using a VPN to browse Wikipedia.
I had to deal with StartCom once many years ago, before LetsEncrypt. They had the rudest customer service I think I've ever encountered.
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.
Many CA have in browser javascript-based private key generation.
(Of course the same page have GoogleAnalytics and facebook button -- otherwise it would be too secure.)
As a sysadmin in 2020 - 2024 time frame I used to do that all the time at my previous job, got a strong openlssl cli game going whenever needed to generate a new csr for existing key or new key and shovel an exact amount of SANs into the CSR too. Lot of time wasted. There were also a certain set of customers for which we managed systems and they insisted for it to be done this way as something free on the internet is not to be trusted. Oh well, strange times.
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.
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.
Look at OpenAI - where there’s a will (and an army of lawyers), there’s a way. That said, I don’t think any of the big tech orgs would be interested in acquiring them. Google and Amazon even already have their own public CAs that are in the major trust stores.
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.
> That's reasonably close to a technical guarantee, if you ask me.
Until the feds show up like:
I complained about the centralization that reminds me of Cloudflare in another place, but in general the more distributed this sort of infra is, the better. Both for technical reasons, as well as political ones. In general, one can plan around potential risks like "Okay, what if I assume that this infra of mine is actually running in Russia and the govt hates me and I need to migrate."VPSes and domains are pretty easy to move across country borders (e.g. moving from NameCheap to INWX and from something like AWS to Hetzner, at least for simple setups), less so when you don't control the CA.
Yes, but that's still a pre-defined list. They can't say "block every website mentioning politician x doing bad things from getting a cert", because that'd be impossible to validate.
The feds are left playing whack-a-mole, and getting the right paperwork to block each new domain popping up is probably going to take a few weeks. Besides, at that point they could also force the .com operator to do the same, could they not?
I do agree that it would be better if LE was more distributed, though. Having a legally-independent second nonprofit running the same software in Switzerland or something would prevent LE from turning into a massive target for the US government.
Why would the feds bother with let’s encrypt in this situation when it would make way more sense to just go to ICANN and get the domain names unregistered. They already do that all the time.
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".
I'd also argue, very necessary.
A lot of thd new APIs have to do with accessing hardware. Camera, Microphone, Serial ports (currently experimental) etc.
Given how easy a MITM attack to injection JavaScript or HTML into insecure pages is, a world where insecure pages had access to hardware makes that hardware very vulnerable.
Even though all you'd be doing is reading some random blog etc.
To those who still think serving HTTP is some sort of principled stand, just be aware that injecting malware onto your page at delivery time is pretty trivial. Quite honestly, and I mean this in a constructive way, it doesn't signal "principles" it signals "incompetence".
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.
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.
We actually spent some time making sure that we weren't going to run into problems with browsers. However, as the OP points out, because LE had a cross-signature from an existing CA, browsers didn't have to any positive action to make LE certificates work. This was absolutely essential to getting things off the ground.
Oh, I know you all did and I remember the cross-signing. I worried that you'd get slapped down somehow, that the crappy cert companies would find a way to stop/reverse it, that the project would fizzle out, etc. I thought it was cool as hell but it seemed something so clearly good couldn't stay good but you all have only gotten better over time.
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!
Seems Let's Encrypt also have control of https://letsdecrypt.org.
It takes you to https://www.nsa.gov rather than Let's Encrypt.
Not sure what to make of that!
http://letsdecrypt.org, no encryption on letsdecrypt :).
Seems like a joke, including the fact it is only acceptable over HTTP.
letsdecrypt.org doesn't load for me.
Here's a curl from my connection:
Seems to be hosted by InterNetX GmbH.Edit: Ah, over HTTPS protocol it doesn't respond.
Web browsers that add it automatically probably get stuck.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.
10 years of solving a problem that didn't exist, and creating a few dozen new ones in the process.
Not evening mentioning the massive security risk they pose; Well, I did now.
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.
https://community.letsencrypt.org/t/revoking-certain-certifi...
https://community.letsencrypt.org/t/2020-02-29-caa-recheckin...
https://bugzilla.mozilla.org/show_bug.cgi?id=1619047
https://www.theregister.com/2020/03/03/lets_encrypt_cert_rev...
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?
Literally just got bit by this. I added a wildcard domain to a cert servicing multiple sites. Apparently the verification process for wildcards is more onerous and even when you have it working it wont renew in the same way as a normal cert. It requires specific workarounds based on your dns provider. Appreciative that we moved away from paid certs that required manual work to renew every year but this feels like a mismanaged backslide.
[dead]
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. :)
Seems longer than 10 years ago? But hey... Let's Encrypt absolutely changed the game... TLS and certificates were a huuuuuge PITA and expensive... we only used them when money was moving around online and they were slow most times. It was also a process to add one, update one, etc. I remember not trusting it at first because it was so easy lol. THANK YOU Let's Encrypt... you made us all more sane, saved time, and secured us all up too. Firm handshakes.
Thats what I thought when I read this too, I feel like they have been around forever.
Guess a lot has happened in 10 years.
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.
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.
Thank you Let's Encrypt, together with the acme.sh , caddy and the whole ecosystem for TLS.
You simply cannot emphasize the information security enough if all your Internet traffic is audited, censored and manipulated by a number of adversaries supported by (authoritarian) governments and what not.
Caddy's way of using plugins seems to require building custom binaries, may I know if that's what you did?
I preferred to use wildcard certs, which requires a plugin for the dns
Well, I use Arch Linux and the caddy package from pacman just works. You may checkout https://github.com/caddyserver/xcaddy for custom caddy build.
Besides, I don't use wildcard certs. I use caddy to reverse proxy a number of self-hosting things, and manually assign domain names to each of them. Caddy can handles many certs just fine.
I plan to make use of a Caddy on a cheap VPS to expose some self-hosted services behind Tailscale, behind Caddy will be a mix of Raspberry Pi and a occasional hosted VPS when trying things out.
How's your experience with Caddy regarding memory usage? I am currently serving a static site with 500 MB, but this is with very low to zero traffic.
I see 3-4% of 1GB ram usage for caddy only. Note that in my case caddy serves as reverse proxy and there is also very little traffic.
Congratulations to Let’s Encrypt. I do wish there was something akin to them for code signing. OV and EV certificates are out of reach for many indie devs.
This is something that legitimately made the world a better place.
I use Let’s Encrypt. It is an amazing service and I am forever grateful.
However, it is time for a second source of free certificates. It is not good that we rely on one supplier.
I only recently realized that Caddy by default uses LetsEncrypt and ZeroSSL, so seems like there already is an alternative. Haven't used it myself yet
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.
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.
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?
A lot of this is covered in the Let's Encrypt retrospective paper from 2019: https://www.abetterinternet.org/documents/letsencryptCCS2019....
From Section 3.1.
"Let’s Encrypt was created through the merging of two simultaneous efforts to build a fully automated certificate authority. In 2012, a group led by Alex Halderman at the University of Michigan and Peter Eckersley at EFF was developing a protocol for automatically issuing and renewing certificates. Simultaneously, a team at Mozilla led by Josh Aas and Eric Rescorla was working on creating a free and automated certificate authority. The groups learned of each other’s efforts and joined forces in May 2013.
...
Initially, ISRG had no full-time staff. Richard Barnes of Mozilla, Jacob Hoffman-Andrews of EFF, and Jeff Hodges (under contract with ISRG) began developing Let’s Encrypt’s CA software stack. Josh Aas and J.C. Jones, both with Mozilla at the time, led infrastructure development with assistance from Cisco and IdenTrust engineers. ISRG’s first full-time employee, Dan Jeffery, joined in April 2015 to help prepare the CA’s infrastructure for launch. Simultaneously, James Kasten, Peter Eckersley, and Seth Schoen worked on the initial ACME client (which would eventually become Certbot) while at the University of Michigan and EFF. Kevin Dick of Right Side Capital Management, John Hou of Hou & Villery, and Josh Aas constituted the team responsible for completing a trusted root partnership deal and signing initial sponsors."
You can ask them; both Josh and Eric are HN people, and Erik is already on this thread. :)
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.
DANE could've worked as an alternative to LetsEncrypt, if all CAs had refused to cross-sign it and essentially killed it for years until everyone's cert stores had caught up.
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.)
I sign my zones :)
The reliable way is DoH/DoT that are rapidly going to become the standard. They don't suffer from fragmentation issues, so they can reliably get the DNSSEC chain.
Or maybe the next step is putting the stapled response into the certificate. Perhaps it can even be used by Let's Encrypt as a part of the challenge, providing the incentive to get it right.
The original stapled DNSSEC experiment was suffering from misaligned incentives. CAs didn't care at all about it.
Huh? What did CAs have to do with stapling?
Stapling needs to be an intermediary step, in parallel with existing trusted CAs. When stapling was tried first in Chrome, no CAs were interested in setting up something like Let's Encrypt, using DNSSEC to automatically issue certificates.
No it doesn't? Why would it? I'm confused by what it is you think CAs have to do with DNSSEC stapling. CAs are absolutely not the reason DANE staples failed.
Staples failed because they couldn't work alone. They were considered a replacement for completely self-signed certificates.
That's why the committee tried to mandate the stillborn pinning idea.
The option to use stapling in addition to a CA-signed certificate was not really considered. After all, if you paid for a CA-signed cert then why would you bother with stapling?
Whatever thing you're talking about, it does not appear to be DANE stapling.
It does? The idea was to staple the DNSSEC chain to the TLS, so that clients wouldn't have needed to do the whole DNS pointer chasing themselves.
The problem is that the MITM-ing adversary can just strip the DNSSEC chain and then replace the certificate. Without having a DNSSEC-enabled resolver, the client can't detect that. So stapling doesn't provide any additional security over the self-signed certificates.
The only proposed fix was to pin the DNSSEC-enabled URLs, using TOFU (Trust On First Use). And nobody wanted that.
There was no real discussion about adding the stapling in _addition_ to CA-signed certificates. Because at that time there was no point in doing that, no CA wanted to provide free signing.
This is changed now. The self-signed certificates are no longer status quo.
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).
For someone who runs a small personal website and uses LE to secure this + some web exposed services, could you explain how this is different/better than acme-dns-certbot?
Let's Encrypt is a single point of failure.
WebPKI also suffers from an inability to properly do delegation. It's not possible for me to create an intermediary certificate valid only for *.mycompany.com
If I want to use WebPKI, I have to either expose every host inside my company to everyone (via CT transparency logs) or use a wildcard certificate. And wildcard certs allow attackers to impersonate anything within my domain, if they get access to just one host.
X.509 technically supports name constraints ( https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 ), but its implementation was inconsistent. In particular, some implementations did not apply it to the Common Name. Fortunately, Common Name is on the path to deprecation.
CT logs do allow enumeration, but avoiding that is just security through obscurity. WebPKI is intended for publicly-accessible hosts, so hopefully you already have some kind of firewall in place to protect them! If you want to avoid enumeration of internal-only hosts: just use your own self-signed root cert. CT logs are a crucial part of protecting against rogue CAs, so don't expect that to go away any time soon.
With ACME most of the delegation issues have pretty much been solved. Publicly-accessible hosts can easily get a cert - if and only if the domain resolves to that host. Want even stricter enforcement? Nobody's stopping you from writing an ACME proxy which only forwards requests from known-good hosts to LE & friends.
> CT logs do allow enumeration, but avoiding that is just security through obscurity.
Well, yes. There are also other issues, like rate limits. Some companies have hundreds of thousands of hosts (some virtual) and requesting certificates for all of them might be problematic.
> If you want to avoid enumeration of internal-only hosts: just use your own self-signed root cert.
This becomes increasingly problematic, as browsers start relying on DoH/DoT, or making it more difficult to enroll custom root certs.
> Nobody's stopping you from writing an ACME proxy which only forwards requests from known-good hosts to LE & friends.
I actually tried that. LE uses multiple viewpoints to resolve the challenges, so you need to open your internal DNS resolvers/HTTPS to basically all the world. Or play with the horror of split-horizon DNS.
I probably downloaded terabytes of data from the internet unnecessarily because https everywhere makes makes it prohibitively complicated to setup local caching proxy.
No to mention time lost waiting for downloads to finish.
I'll never understand why caching proxy is not a default part of every OS.
Let's Encrypt is awesome. Is there any other ridiculously overpriced good/service that could be Let's Encrypt'ed today?
> 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 ;)
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.
I remember buying certs from Godaddy then Namecheap then using Let's Encrypt feels like when GitHub offered free private repos
One domain parking actor is responsible for nearly 10% of all issued ssl certificates. 185.53.178.99. This is just one of many bad actors.
This belongs to a German company called Team Internet AG [1]. Are they really a bad actor? What's the reason to issue so many SSL certificates?
https://www.whois.com/whois/185.53.178.99
> What's the reason to issue so many SSL certificates?
Might be related to https://www.teaminternet.de/en/parkingcrew
Interesting. Personally I find it questionable to squat so many domains for ads. But they pay for it and it is within the legal framework.
I love Let's Encrypt
A small VPS + LetsEncrypt + Dokku is a fantastic way to run personal side projects/hustles at minimal cost.
Would be interesting to hear what database they are using and how they are doing replication? Is it simple master / slave or multi-master?
Let’s Encrypt currently has a single primary with a handful of replicas, split across a primary and backup DC.
We’re in progress of adopting Vitess to shard into a handful of smaller instances, as our single big database is getting unwieldy.
Let’s Encrypt is an incredible project and the internet is better off for it. If you ever have questions about vitess or need help please let me know.
Thanks. Would love to see a tech blog post once you get Vitess implemented.
We’ve already started drafting it :)
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.
Let’s Encrypt does operate CT logs. I wrote a blog post about our current-generation logs at https://letsencrypt.org/2024/03/14/introducing-sunlight
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.
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.
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.
The pathetic part of EVs is that they should have been issued by whatever the business register/regulator is in the country of issue.
Not some arbitrary group like D&B etc.
The US/other countries should have ensured that each state/registration area had an appropriate cert to sign with.
It should be part of my company's annual registration/reporting expenses that they issue the appropriate certificate for "*.<mycompany>.<2LDs>.<gTLD>", signed by them (and by the TLD root cert of the nation of registration).
Companies probably prefer to use "apple.com" instead of "apple-computer-inc.co.ca.us". It's even worse if you want to use truly unique identifiers like ISIN, LEI, DUNS, or IBRN, as that means something closer to "US0378331005.com".
The point is that I (as an Australian) don't trust a private organization like D&B any more than any other organization.
Corporate existence is dependent on some form of government regulator granting the corporation existence.
If EVs are/were a good idea (debatable at best), then having those EVs issued by the same government regulator that allows corporates to use trademarks etc makes sense.
If "apple" is a trademark for computers, then Apple Computer Inc as the owner of that trademark should get an EV issued by the regulator of trademarks.
Of course, the URL should be apple.com.us or apple.tm.us.
The historical error was not requiring the US to move to 2LDs for it's com/org/net/gov/mil etc domains.
Note this is for corporate entities, none of which exist outside regulatory environments.
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.
Incredibly grateful for this project
my friends work here! and it was founded by an alum from my school Macalester College
That is awesome i love how you change the TLS Scene for ever! Keep pushing it!
What else is kept behind paperwork and fees that could be freed?
Yes let's. But that doesn't answer my question.
Cloudflare: "Oh no, we can't have that much centralization, that's horrible, just think of the impact outages have!"
Let's Encrypt: crickets
Obviously I use LE myself and like what they do, and even in the example above some downtime would have less of an impact than Cloudflare would (due to renewals being less time sensitive), I'm just surprised that there aren't like 5 other orgs that do the same at scale, like an EU based one for example. If there's a lot of domain registrars, why doesn't every single one of them have ACME compatible services?
I think there was ZeroSSL but I vaguely remember something scummy about upsells there a few years back.
If LE goes down for a week you can't deploy new certs, but your existing ones will work, as you renew them a few weeks before expiry anyway
That also gives you enough time to change to get your certs from elsewhere
As you mention zerossl exista, and I think google GCM will give you free certs too.
Globalsign has an ACME interface for paying customers, although I'm told it has issues (you have to rotate keys manually every X days / N certificates)
> If LE goes down for a week you can't deploy new certs, but your existing ones will work, as you renew them a few weeks before expiry anyway
Assuming certificate expiration times remain over 7 days per certificate.
There's no (current) plans to drop below 45 day certificates with an expected renewal with 2 weeks to go.
I agree if cert lifetimes drop towards week long then it becomes problematic. A sensible thing at that point is to ensure you can issue certificates from different CAs on different underlying stacks, in the same way you use multiple DNS servers
it is hard to believe it's been ten years.
10 years and still no S/MIME.
Just 10, it feels like more.
Next step: Let's Tor?
Still not convinced it's not a honeypot. Would like to see concrete evidence.
A couple of years ago, I went through the process of signing a kenel minifiter that I wrote for our endpoint-security product. It was complicated, to put it mildly.
Imagine if we had a similar process for websites! Thanks Let's Encrypt.
Reminder that it’s a non profit
thank you for your service
[dead]
[flagged]
You might want to be more specific about the meaning of "between" here. It's not a cryptographic MITM attack, and if it ever facilitated someone else in performing one, that should be detectable.
https://en.wikipedia.org/wiki/Certificate_Transparency
(It's also true that the level of active monitoring of CT logs has never gotten very high.)
It's not like Let's Encrypt is the only game in town, Actalis in Italy provides free ACME certs too if you'd prefer to keep things in Europe.
Not sure if there is a point to "keep things in Europe" when it come to certificate authority.
- LetsEncrypt don't have the private key tied to your certificate - Any of the Certificate Authorities could potentially emit unauthorized certificate
Your only protection for all of these problems is HPKP. If you prefer to keep things in Europe, keep that pinned private key in Europe, but the rest doesn't matter.
That said, it's pretty nice that LetsEncrypt forced the ACME protocol on this industry. Not only it create redundancy with mostly interchangeable alternatives but before ACME, there was no way to fully automate certificate provisioning cleanly.
Just to clear up one point -- Let's Encrypt did not at all force ACME on the industry. We deliberately took it to the IETF so that we could get input from more parts of the industry (including some major refactors!). Instead of pressure from Let's Encrypt, I would attribute its success to the open process of the IETF, the awesome open-source community that made great ACME software (shoutout to Matt and Caddy!), and the resulting pressure on CAs for a better user experience from users and customers.
I didn't express myself well but what I meant by force is that by building a standardized to automate way manage certificate, ACME imposed itself and became mandatory.
Previously, most CA had no programmatic way to order certificate, it was all done manually.
As far as I know, the only providers with that would let you automate certificate provisioning at the time where Comodo, GlobalSign and Digicert.
They all had their own quirky API. Just to give you an idea, we ended up selecting GlobalSign at Shopify a few years before LetsEncrypt, and it was this SOAP nightmare: https://www.globalsign.com/en/repository/GlobalSign_Client_A...
At first none of them were warm at the idea of providing an ACME endpoint. I'm assuming part of it is the cost of implementing it but they probably liked the stickiness of their custom APIs too tied to million dollars contracts.
Nowadays they all implement ACME. At some point, they where effectively forced to implement it to acquire new customers and keep their existing base around because nobody would accept poorly designed custom made protocol anymore.
Their website seems to suggest the renewal isn't free?
They are definitively not the most shady organization in the CA/Browser Forum.
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.
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.
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...
I think it is working as intended.
Register a corporation often meant it is linked to a real life, government issued ID.
If you do scam or fraud on that web site, they know where to find you.
... unless, of course, if the CA ain't doing the verification.....
> 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.