▲ 543 points
back
189 comments
Hands down one of the greatest services out there, stopped a racket and made the internet secure.
I remember a time when having an HTTPS connection was for "serious" projects only because the cost of the certificate was much higher than the domain. You go commando and if it sticks then you purchase a certificate for a 100 bucks or something.
There's still enough people out there who don't know better, manually (or auto-renew) purchasing new a certificate every year from their hosting provider like it's 2013.
I have dealt with banking environment when they required SSL with at least 1-year validity on the callback API URL. Which excluded Let's Encrypt.
We were looking for a SSL provider that had > 1 year old certs AND supported ACME... for some reason we ended up with SSL.com that did support ACME for longer lasting certs; however, there was some minor incompatibilities in how kubernetes cert-manager implemented ACME and how SSL.com implemented ACME; we ended up debugging SSL.com ACME protocol implementation.
Fun. We should have just clicked once per 3 years, better than debugging third parties APIs.
No, I don't remember the details and they are all lost in my old work emails.
(Nowadays I think zerossl.com also supports ACME for >1 year certs? but they did not back then. edit: no they still don't, it's just SSL.com I think)
AFAIK there's things like Extended Validation Certificate Verification that used to make the browser address bar look more trustworthy by making it green but I don't know if its still a thing. At least in Safari, I don't see a green padlock anywhere.
Related point - we interface with Singapore gov services (MYINFO).
They don't recognize LE nor AWS's certs. Only the big paid ones. Such an annoying process too - to pay, to obtain and update the certs.
Our company bans the use of letsencrypt because of the legal terms. Nobody at the CxO level will sign off on it, so we end up paying whatever to globalsign.
Doesn't necessarily have anything to do with knowing, some environments are just not worth automating or support it so badly that even paying twice or more would still be nothing compared to the annoyance. It's been getting better over the years though.
I had a lazily configured proxy which would request a cert for any domain you threw at it. An attacker figured this out and started peppering it with http requests with randomly generated subdomains prefixed. When I discovered it, my first thought wasn’t, “Oh, I hope I didn’t get flagged by Let’s Encrypt.” It was, “Oh, man. I feel really bad that my laziness caused undue load on Let’s Encrypt.”
Let’s Encrypt is the best thing to happen to the web in at least a decade.
Mozilla is getting a lot of criticism, but just for letsencrypt alone they are making the world a better place.
Before them I never used SSL for anything, because the cost/benefit ratio was just not there for my services.
Since then, I never not use it.
At least there were some services where you could get a single domain "real" certificate for free before (But a complicated and annoying process) but then if you wanted a wildcard certificate to cover a bunch of subdomains for personal projects it became really expensive.
Glad this problem just got completely resolved.
Google/Chrome and Firefox also deserve credit for making a free and open CA viable.
We consider our ten year anniversary to be in 2025 but I appreciate the kind words here!
Today is roughly the ten year anniversary of when we publicly announced our intention to launch Let's Encrypt, but next year is the ten year anniversary of when Let's Encrypt actually issued its first certificate:
https://letsencrypt.org/2015/09/14/our-first-cert/
In December of 2015 (~9 years ago today) is was made available to everyone, no invitation needed:
It's actually serendipitous that it happened exactly on December 2015. That's when I had only enough for a domain, but not for a ssl, and my site needed an ssl. Thanks to let's encrypt free ssl, the project hit.
It feels like just yesterday I was paying for certs, or worst, just running without.
Can't believe its been ten years.
Can’t believe there are still anti TLS weirdos.
I'm kinda mixed on LE.
It's nice that you can now get free TLS certs without having to resort to shady outfits like StartSSL. This allows any website to easily move to HTTPS, which has basically elimated sensitive data (including logins) from being sent over unencrypted connections.
On the otherhand, this reinforces the inherently proken trust model of TLS certificates where any certificate authority (and a lot of them are controlled by outright hostile entities) has the ability to issue certificates for your domain without your involvement. Yes there are tons of kludges to try and mitigate this design flaw (CAA records, certificate transparency) but they don't 100% solve the issue. If not for LE perhaps there would have been more motivation to implement support for a saner trust mechanism by now that limmits certificate issuance to those entities who actually have any authority to decide over domain ownership, like with DNSSEC+DANE.
I'm also concerned with the (intentional) lack of backwards compatibility with moving sites to TLS, which is not just a one time TLS on/off issue but a continual deprecation of protocols and ciphers. This is warranted for things that need to be secure like banking or email but shouldn't really be needed to view a recipe or other similar static and non-critical information. Concerns about network operators inserting ads or other shit are better solved with regulation.
> If not for LE perhaps there would have been more motivation to implement support for a saner trust mechanism by now
I would argue that LE has only highlighted these problems, and now actually causes people with power to worry about them.
There is a chance we would have gotten something better than TLS if the lack of LE kept certificates a pain. But that seems unlikely to me. Because the fundamental problem remains hard.
What I'm most thankful is the ACME protocol.
Does anyone remember how we renewed certificates before LE? Yeah, private keys were being sent via email as zip attachments. That was a security charade. And as far as I know, it was a norm among CAs (I remember working with several).
Thank you Let's Encrypt.
Just handholding a renewal with globalsign
I generate the new key on the server as part of the csr creation process. I run it on the server itself so the key never leaves the server's internal storage.
CSR gets sent off to globalsign (via a third party because #largeCompany), then a couple of days later I get the certificate back and apply to the server
Would love to use ACME instead, and store the key in memory (ramdrive etc), but these are the downsides of working for a company less agile than an oil-tanker
What of Certificate Signing Requests? The whole purpose was that you wouldn’t send private keys around.
(I was only slightly involved with a couple of TLS certificates before then, and certainly they enforced the CSR approach, but maybe such terrible practice was more common in the real world that I knew.)
Regardless of whether you use LE or not, you would not ever send a private key in a zip file rather a public key.
I still have to go through that bs with some of my setups. Load balancers in cloud environments don't tend to integrate easily with external ACME providers like letsencrypt and the internal ones require moving your domain to them which doesn't always work. And not all cloud providers even have this. Most of them seem to treat ACME as an afterthought.
You can sort of do some hacks with scripting this together via things like terraform, cron jobs, or whatever. But it gets ugly and the failure modes are that your site stops working if for whatever reason the certificates fail to renew (I've had this happen), which courtesy of really short life times for certificates is of course often.
So, I paid the wildcard certificate tax a few days ago so I don't have to break my brain over this. A couple of hundred. Makes me feel dirty but it really isn't worth days of my time to dodge this for the cost of effectively < 2 hours of my time in $. Twenty minute job to issue the csr, get the certificate and copy it over to the relevant load balancers.
How many of those CAs are still in everyone's trust stores?
> Yeah, private keys were being sent via email as zip attachments.
Internally, perhaps. And also on a small scale maybe with CA "resellers" who were often shady outfits which were in it for a quick buck and didn't much care about the rules.
But as a formal issuance mechanism I very much doubt it. The public CAs are prohibited from knowing the private key for a certificate they issue. Indeed there's a fun incident some years back where a reseller (who have been squirrelling away such private keys) just sends them all to the issuing CA, apparently thinking this is some sort of trump card - and so the issuing CA just... revokes all those certificates immediately because they're prohibited from knowing these private keys.
The correct thing to do, and indeed the thing ACME is doing, although not the interesting part of the protocol, is to produce a Certificate Signing Request. This data structure goes roughly as follows: Dear Certificate Authority, I am Some Internet Name [and maybe more than one], and here is some other facts you may be entitled to certify about me. You will observe that this document is signed, proving I know a Private Key P. Please issue me a certificate, with my name and other details, showing that you associate those details with this key P which you don't know. Signed, P.
This actually means (with ACME or without) that you can successfully air gap the certificate issuance process, with the machine that knows the private key actually never talking to a Certificate Authority at all and the private key never leaving that machine. That's not how most people do it because they aren't paranoid, but it's been eminently possible for decades.
I really wish something like this comes up for the desktop certification world as well. Microsoft just went full insane mode with their current requirements, and their certificate plugs are making more money than ever without lifting a finger.
So funny that all of their security, vetting and endless verifications are standing on a single passport photo sent over an email to this day.
Peter Eckersley (1978-2022) was posthumously inducted into the Internet Hall of Fame for his founding work on Let’s Encrypt. The Internet is a better place because of Peter (and his many collaborators and colleagues).
https://www.internethalloffame.org/inductees/
None of them I have ever heard of. Whatever that may mean.
Edit: On the whole list https://www.internethalloffame.org/inductees/all/ I spotted maybe seven names. Still a single digit percentage.
Coincidentally I just got an email from a potential client, Dutch governmental institution, that they don’t want me to use Letsencrypt. They prefer paying for a certificate themselves. Not sure why, apparently they don’t trust it.
A lot of people are not aware that HTTPS certificates do not necessarily guard you from certain types of attacks like DNS injection. You can see <https://www.youtube.com/watch?v=exy5JwAU8qk> for one example where an attack campaign called DNSPionage obtained valid certificates for their attacks.
To explain the issue with HTTPS certificates simply, issuance is automated and rests on the security of DNS, which is achieved via DNSSEC and most do not implement.
Technically it's an attack against the certificate issuing authority, bypassing their authorisation checks (is this person really authorised to issue a certificate for the domain).
Trouble is even CAA entries won't help here (if you're spoofing A records, you can spoof CAA records too). DNSSEC might help against this, I don't know enough about DNS though.
Another type of attack is an IP hijack, which allows you to pass things like http authentication (the normal ACME method), but won't bypass CAA records. Can't use letsencrypt to issue a cert - even if you own the IP address my A or AAAA records point to - if my CAA doesn't have letsenctypt as an approved issuer.
Let's Encrypt is a massive achievement, and is now essential infrastructure.
Basing it on an open protocol, so it doesn't become a single point of failure, was a clever idea that allows the idea to survive the demise of any single organization.
May there be many more such anniversaries.
Config management took me many years to adopt, containers took me about 6 years to warm up to. But LE was something I jumped on immediately. I had worked in web hosting for 10 years already when it came out so I remember faxing your driver's license in order to validate a TLS cert. It just felt like such a scam for so long that these CAs were over charging for something that is just a key signing.
But I guess automation and standards had to catch up in order for LE to securely setup their CA.
Let's Encrypt helped reduce our OUTRAGEOUS Entrust bill(legacy vendor, I didn't pick them, they had insane security protocols for a small company who just needed SSL certs). We had a 4 yr/$14k contract for about 11 certs. Now our SSL is near 0, except for a cert for SSRS that is hard to automate with LE.
Let's encrypt saved me :) I love to use it with certbot in docker-compose :) deploying really can be simple
Here’s to 10 more years! With web servers like Caddy, software like certbot and even something like Apache2 getting mod_md, I’d say we’re in a pretty good spot!
That said, I’m wondering why there aren’t 10 or so popular alternatives to LE, since that seems to be the landscape for domain registrars, for example.
Are there any areas today similar to the SSL of 10 years ago that a service like Let's Encrypt could remedy? I see a lot of subscription apps that could pretty easily be replaced by free, non-subscription, ones, but I don't know of anything that widespread.
I really wish they would finally branch out and offer S/MIME certificates. Good email clients support them out of the box, it's just a PITA to get them if you don't want to order 100 at a time or something equally ridiculous for SME/individuals.
Would frequent rotation be reasonable for S/MIME certs though?
thank you Edward Snowden
I wanted to post that exact comment.
People talk about paying for certificates but one major pain point solved by PaaS companies over the last 5 years is automatically adding certificates and renewing them for your app deployments. It saves a huge amount of headache.
In 2024, if your PaaS does not have automated encryption for deploys, I will never use it.
Time flies when you're having fun.
Congratulations
Such an awesome service (and protocol!)
Reminder that they donation dependent
Nothing makes me trust a site with my payment info more than seeing a LE or domain-validated certificate with no ownership details in the DN.
HTTPS does not validate the trustworthiness of a site. Never has and never will. It only validates that the site has not been tampered with during transfer. Phishing sites can also have HTTPS, that doesn't make them trustworthy.
Google.com (and my bank) use a DN certificate, if it's good enough for them it's good enough for anyone.
The rate of misissuance of EV and OV is much higher than DV.