10 Years of Let's Encrypt
letsencrypt.org
letsencrypt.org
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.
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.
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.
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?
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...
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.
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.
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.
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.
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.
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 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.
It's not free for you of course because advertising isn't free and from their point of view what you'd be getting is free advertising so they want you to pay them to put it in front of your customers.
It 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.
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.
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 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
nameConstraints=critical,permitted;DNS:.iso1631.internal
- "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....
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.
> 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).
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?
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.
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.
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.
I swear half of my "compensating control" responses are just extended versions of "policy requirement is outdated or was always bad".
It's not like you have a lot of choices when certificates are only valid for 47 days in 2029!
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.
>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.
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.
Well, yes, someone actually commented to me in a negative way about using Let's Encrypt ....
Don't shoot the messenger, as they say.
https://www.troyhunt.com/extended-validation-certificates-ar...
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.
So, a barrier to entry, but not much of one.
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.
[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.
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.
Imagine if only the owner of the McDonald's trademark could issue a certificate which displays the McDonald's name and logo, for example.
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.
"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.
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.
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 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.
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?
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.
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...
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.
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.
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.
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.
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.
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.
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.
I'm glad LE, browsers, and others like Cloudflare brought this cost to $0. Eliminating this unnecessary cost is good for the internet.
Let's Encrypt is to the internet what SSDs are to the PC. A level up.
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...
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.
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.
Most of my clients don't have budgets big enough for cloud hosting.
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's shady, but technically not price-fixing unless they are a monopoly. You are free to take your business to somewhere else.
If you can find a company that allows clients to install Let's Encrypt Certs on shared hosting, please let me know.
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...
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.
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.
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.
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.
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.
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.
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 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.
Just checked. They’re still using that manually installed cert!
Setting up an encrypted web-domain with continual Let's Encrypt certificate renewal has become tedious cargo-culting around the relicts of the idea of a certificate that establishes trust by identity verification.
The collapse of identity-based certification is not Let’s Encrypt’s fault. People naturally choose the easiest option, and Let’s Encrypt supplied it.
Entrusting a handful of commercial certificate authorities with global identity is dubious on first principles anyway, but at least they tried; yet, for all its flaws, that centralized system has proven more practical than the idealistic, decentralized "web of trust".
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.”
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...
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.
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.
To me, the alternative is just a LE cert. Can do wildcards via DNS challenge.
Do you think Let's encrypt is less popular outside the US?
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've got a website I build for a friend running that I haven't touched in 5 years TLS-wise, never had any issues.
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.
Just comically bad way to obtain certs.
(Of course the same page have GoogleAnalytics and facebook button -- otherwise it would be too secure.)
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.
Most users and system owners didn't care unless money was being transacted.
Between Snowden and ISPs injecting content into pages, the consensus changed.
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.
Google started tracking adoption of TLS in 2015, with adoption below 50% and some regions below 30%.
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.
So, I wouldn't be so sure, unfortunately.
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 de-facto requirement that you need to receive the blessing of a CA to make use of basic web platform features... not so good.
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".
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".
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
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)
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.
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.
Because they want your money. If they ask you after they get to keep your money.
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.
Thank You for an amazing product!
Congrats on a decade, ya’ll, here’s to many, many more in securing the free internet.
It takes you to https://www.nsa.gov rather than Let's Encrypt.
Not sure what to make of that!
$ curl -v letsdecrypt.org
* Host letsdecrypt.org:80 was resolved.
* IPv6: (none)
* IPv4: 62.116.130.8
* Trying 62.116.130.8:80...
* Connected to letsdecrypt.org (62.116.130.8) port 80
* using HTTP/1.x
> GET / HTTP/1.1
> Host: letsdecrypt.org
> User-Agent: curl/8.14.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Wed, 10 Dec 2025 15:20:48 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Redirector-ID: 14c2d856bcd2de3beae30791793b40ae43db49fc9ea482a825177a36e20108c4
< Location: http://www.nsa.gov/
< IX-Cache-Status: MISS
<
* Connection #0 to host letsdecrypt.org left intact
Edit: Ah, over HTTPS protocol it doesn't respond.
$ curl -v https://letsdecrypt.org
* Host letsdecrypt.org:443 was resolved.
* IPv6: (none)
* IPv4: 62.116.130.8
* Trying 62.116.130.8:443...
You're probably thinking of StartSSL, and it was a bit of a pain to get it done.
And you try telling young people that ACME is a walk in the park, and they won't believe you...
Also, the only website I've ever encountered that actually used the HTML <keygen> tag.
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.
Guess a lot has happened in 10 years.
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.
I preferred to use wildcard certs, which requires a plugin for the dns
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.
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.
However, it is time for a second source of free certificates. It is not good that we rely on one supplier.
For the next years I'm hoping for more resilience/global distribution in the issuance process. Since I live on an island for about half the year I do have experience with internet outages, and we do appear to live in turbulent times. That could be an issue with the ever decreasing certificate lifetime. I'd love to see LE exploring options like working with ccTLD registrars to work on local issuance.
"The Let's Encrypt project was started in 2012 by two Mozilla employees, Josh Aas and Eric Rescorla, together with Peter Eckersley at the Electronic Frontier Foundation and J. Alex Halderman at the University of Michigan."
https://en.wikipedia.org/wiki/Let%27s_Encrypt
What was Mozilla's role, beyond conception? Parenting? Care and feeding? A roof?
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."
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
Long shot? Yes. But not impossible.
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).
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.
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?
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.
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.
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.
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.
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.
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 evening mentioning the massive security risk they pose; Well, I did now.
Aren't they only 45 days [1] old ?
Could anyone clarify?
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.
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.
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.
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.
Publishing more about our resilience engineering sounds like a great idea!
I'll get that on our blogging schedule for next year
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.
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.
Your pain and intolerance to that button push proves their intent.
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.
We’re in progress of adopting Vitess to shard into a handful of smaller instances, as our single big database is getting unwieldy.
Might be related to https://www.teaminternet.de/en/parkingcrew
But this is a close second. 10 years? That can't be right. Even accounting for Covid Time Dialation.
A small VPS + LetsEncrypt + Dokku is a fantastic way to run personal side projects/hustles at minimal cost.
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.
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.
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.
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.
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).
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.
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.
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)
Assuming certificate expiration times remain over 7 days per certificate.
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
Imagine if we had a similar process for websites! Thanks Let's Encrypt.
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.)
The problem as I see it is: there simply isn't one coherent global notion of what entity authentication means. It's situational.
It's essentially a self-signed cert that anyone could make with the false security of a root certificate authority.
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.
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.
https://web.archive.org/web/20171211181630/https://stripe.ia...
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.....
https://arstechnica.com/information-technology/2017/12/nope-...
(The original site is no more, but this Arstechnica article has screenshots and a good summary)