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.
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.
https://www.troyhunt.com/extended-validation-certificates-ar...
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.
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 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.
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.
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.
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.
I'm glad LE, browsers, and others like Cloudflare brought this cost to $0. Eliminating this unnecessary cost is good for the internet.
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.
Let's Encrypt is to the internet what SSDs are to the PC. A level up.
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!
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.
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. If you are stuck with Web.com you may consider using a reverse proxy/CDN such as CloudFlare.
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.
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.
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.
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. 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.
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, 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…”
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 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.
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.
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.
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.
Well, yes, someone actually commented to me in a negative way about using Let's Encrypt ....
Don't shoot the messenger, as they say.
>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.
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.”
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.
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...
Do you think Let's encrypt is less popular outside the US?
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.
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.
Google started tracking adoption of TLS in 2015, with adoption below 50% and some regions below 30%.
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.
However, it is time for a second source of free certificates. It is not good that we rely on one supplier.
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!
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.
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
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".
Because they want your money. If they ask you after they get to keep your money.
Congrats on a decade, ya’ll, here’s to many, many more in securing the free internet.
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
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.
You're probably thinking of StartSSL, and it was a bit of a pain to get it done.
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."
Imagine if we had a similar process for websites! Thanks Let's Encrypt.
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.
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.
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.
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).
We’re in progress of adopting Vitess to shard into a handful of smaller instances, as our single big database is getting unwieldy.
You can find a docker-compose.yml file to get some idea.
Appears to be using MariaDB.
They shut down OCSP responders and expiry email reminders, so there really is no need to have a database apart from rate limits, auth data, and caching.
For Certificate Transparency, they are submitted to Google and CloudFlare run trees but I don't think LetsEncrypt run their own logs.
I 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.
But this is a close second. 10 years? That can't be right. Even accounting for Covid Time Dialation.
Aren't they only 45 days [1] old ?
Could anyone clarify?
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.
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.
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.
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.
https://arstechnica.com/information-technology/2017/12/nope-...
(The original site is no more, but this Arstechnica article has screenshots and a good summary)
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.
https://web.archive.org/web/20171211181630/https://stripe.ia...
You can see for yourself that a Let's Encrypt certificate is genuine too.