Let's Encrypt was _huge_ in making it's absurd to not have TLS and now we (I, at least) take it for granted because it's just the baseline for any website I build. Incredible, free service that helped make the web a more secure place. What a wonderful service - thank you to the entire team.<p>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...<p>So my question: has anyone actually commented to you in a negative way about using Let's Encrypt? I couldn't imagine, but curious on others' experiences.
To be fair, for a CEO in 2022, EV certificates had only lost their special visualizations since September/October 2019 with Chrome 77 and Firefox 70 - and with all that would happen in the following months, one could be forgiven for not adapting to new browser best practices!<p><a href="https://www.troyhunt.com/extended-validation-certificates-are-really-really-dead/" rel="nofollow">https://www.troyhunt.com/extended-validation-certificates-ar...</a>
It was a red herring the entire time. At Shopify we made experiment regarding conversion between regular certs and EV before they stop being displayed and there was no significant difference. The users don't notice the absence of the fancier green lock.
I think the rebuttal to the CEO today is really very simple.<p>a) How many of the sites you visit everyday have DV and how many have EV certificates?<p>b) Name any site at all, that you have visited, where your behavior or opinion has changed because of the certificate?<p>In truth the green-bar thing disappeared on mobile long before desktop (and in some cases it was <i>never</i> present.)<p>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.<p>EV could have an inspector literally visit your place of business, and it would still have <i>no value</i> because EVs are invisible to site visitors.
Call me old-school, but I <i>really</i> liked how EV certs looked in the browser. Same with the big green lock icon Firefox used to have. I know it's all theatrics at best and a scam at worst, but I really feel like it's a bit of a downgrade.
"it's all theatrics at best"<p>Only IT understand any of this SSL/TLS stuff and we screwed up the messaging. The message has always been somewhat muddled and that will never work efficiently.
> Call me old-school, but I really liked how EV certs looked in the browser.<p>I agree, making EV Certs visually more important makes sense to people who know what it means and what it doesn't. Too bad they never made it an optional setting.
When you request an EV. They call you by the phone number that you give to ask if you requested a certificate. That was the complete extend of the validation.
I could be a scammer with a specificity designed domain name and they would just accept it, no questions asked.
Depends on the registrar. Globalsign required the phone number to be one publicly listed for the company in some business registry (I forget exactly which one), so it had to be someone in our main corporate office who'd deal with them on the phone.
For an online business in a dubious (but legal) domain, my co-owner spent a few hundred bucks registering a business in New Mexico with a registered agent to get an EV cert.<p>So, a barrier to entry, but not much of one.
Dun and Bradstreet (?). I believe I'm remembering this correctly. I still deal with a few financial institutions that insist on using an EV SSL certificate on their websites. I may be wrong, but I believe that having an EV SSL gives a larger insurance dollar amount should the security be compromised from the EV certificate (although I imagine it would be nearly impossible to prove).<p>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.
> In addition to all of the authentication steps CAs take for DV and OV certificates, EV certificates require vetting of the business organization’s operational existence, physical address and a telephone call to verify the employment status of the requestor. [1]<p>[1] <a href="https://www.digicert.com/difference-between-dv-ov-and-ev-ssl-certificates" rel="nofollow">https://www.digicert.com/difference-between-dv-ov-and-ev-ssl...</a><p>Tying a phone number to a physical address and company is a lot more useful than just proof of control over a domain. Of course its not 100% fool proof and depends on the quality of the CA but still very useful.
> Tying a phone number to a physical address and company is a lot more useful than just proof of control over a domain.<p>It might be useful in some cases, but it is never any more secure than domain validation. Which is why browsers don't treat it in a special way anymore, but if you want you can still get EV certificates.
It was easy to provide the information for an existing business you're completely unrelated to. Reliably verifying that a person actually represents a company isn't possible in most of the world.
I'd love a referral to your certificate authority and rep - we go through a big kerfluffle each renewal period, only eventually receiving the certificate after a long exchange of government docs and CPA letters. For us, only the last step is the phonecall like you say.
Having run an EV issuing practice… they were required to contact you at a D&B listed number or address.
EV certs also showed the legal name of the company that requested the certificate - that was an advantage.
Which would have made sense if company names were unique - which they aren't. See e.g. <a href="https://groups.google.com/g/mozilla.dev.security.policy/c/NjMmyA6MxN0" rel="nofollow">https://groups.google.com/g/mozilla.dev.security.policy/c/Nj...</a> for an example of how this was abused.
The problem is that people wrongly believe that company names are unique. In reality you're just some paperwork and a token registration fee away from a name clash.<p>If anything, it's a <i>disadvantage</i>. 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 <i>surely</i> you're on the right website and it is <i>totally</i> safe to enter your credentials...
In many countries, company names are unique to <i>that</i> country. And combined with country TLDs controlled by the nation-state itself, it'd be possible for at least barclays.co.uk to be provably owned by the UK bank itself when a EV cert is presented by the domain.<p>In the US though, every state has it's own registry, and names overlap without the power of trademark protection applying to markets your company is not in.
i think the point was that EV didn't actually mean anything because the checks were too loose. it's a feel good false sense of security
it’s okay, the scam continues with BIMI
I loved the visualization of EV certs in browsers, but in 2014 vendors like GoDaddy charged $100/yr for them. <a href="https://web.archive.org/web/20131023033903/http://www.godaddy.com/ssl/ssl-certificates.aspx?ci=9039" rel="nofollow">https://web.archive.org/web/20131023033903/http://www.godadd...</a><p>I'm glad LE, browsers, and others like Cloudflare brought this cost to $0. Eliminating this unnecessary cost is good for the internet.
EV validated not only that a domain was under control of the server requesting the cert, but that the domain was under control of the entity claiming it.<p>I kind of wish they still had it, and I kind of wish browsers indicated that a cert was signed by a global CA (real cert store trusted by the browsers) or an aftermarket CA, so people can see that their stuff is being decrypted by their company.
Problem is, I can easily set up a company and get an EV cert for "FooBar Technologies, LLC" and phish customers looking for "FooBar Incorporated" or "International FooBar Corp.". Approximately zero users know the actual entity name of the real FooBar.
BIMI, as misguided as it is, does aim to solve this by tying registration to insanely high prices and government-registered trademark verification. You would have a hard time registering the Stripe trademark nowadays in a way that would get you a BIMI certificate for that name/logo.<p><a href="https://www.thesslstore.com/resources/bimi-certificate-cost-for-cmcs-and-vmcs/" rel="nofollow">https://www.thesslstore.com/resources/bimi-certificate-cost-...</a><p>But I'm glad that it hasn't caught on as strongly-expected by the public (or even commonly used). Big brands shouldn't be able to buy their way into inbox placement in ways that smaller companies can't replicate.
Even if the users knew exactly what the name of the entity whose website they wanted to visit was: that name is not unique, as is shown by the "Stripe, Inc" example in the parents linked blog post.
you can find quite of few examples online that the entity check wasn't all that strict...
I have also heard a negative about it being somehow "cheap" and we can "afford" a proper wildcard for our website from managers back in the day, like, few years ago. Never mind the hours wasted every year changing that certificate in every system out there and always forgetting a few.<p>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.<p>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.
I once notified Porsche that one of their websites had an expired certificate, they fixed it within a couple of hours by using Let's Encrypt. It surprised me.<p>Let's Encrypt is to the internet what SSDs are to the PC. A level up.
There was a time when EV certificates were considered more trustworthy than DV certs. Browsers used to show an indication for EV certs.<p>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.
There are extended certificates that did matter in our sales process for some hosted solutions back about 15 years ago if I recall right… no one has ever cared since…
No! Let's encrypt is easily the best thing that's happened for a secure internet the last 10 years.
The only pain point I had using letsencrypt, and it wasn 100% not their fault, was I tried using it to generate the certificate to use with FTPS authentication with a vendor. Since LE expires every 90 days and the vendor emails you every week when you’re 2 months from expiring, that became a pain point and it wasn’t easier to just by a 1 or 2 year cert from godaddy. Thank goodness that vendor moved to sftp with key authentication so none of that is needed anymore
Many host providers (Those acquired by companies like Web.Com, allegedly) disable all ability to use outside certs since Google made encryption a requirement in Chrome Browser...<p>They do things like blocking containers & SSH to make installing free certs impossible.<p>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...<p>It would be a huge price-fixing scandal if Congress had any idea of how technology works.
There are literally thousands of web hosts out there. If your web host is doing something shitty like that, it's trivial to find a new one.
> It would be a huge price-fixing scandal if Congress had any idea of how technology works.<p>It's shady, but technically not price-fixing unless they are a monopoly. You are free to take your business to somewhere else.
If you read into Web.Com, yes, they are quickly becoming a monopoly on host companies. They do not disclose many of the hosting companies they now own.<p>If you can find a company that allows clients to install Let's Encrypt Certs on shared hosting, please let me know.
Yeah, fair point. I have not used shared hosting for a long time now (static sites are easy/free to host, and dynamic ones don't play well with shared hosting), so I didn't know the Web.com story.<p>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.<p>[1] <a href="https://help.dreamhost.com/hc/en-us/articles/216539548-Adding-a-free-Let-s-Encrypt-certificate" rel="nofollow">https://help.dreamhost.com/hc/en-us/articles/216539548-Addin...</a>
I've seen people complain that Let's Encrypt is so easy that it's enabling the forced phaseout of long-lived certificates and unencrypted HTTP.<p>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 <i>supposed</i> to work.
Yeah, I hate how it made housing things locally without a proper domain name very difficult. My router _shouldn't_ have a globally recognized certificate, because it's not on a publicly visible host.<p>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.
Random anecdote: I have a device in which the http client can't handle https. Runs out of memory and crashes. Wasn't able to find a free host with a public http to host a proxy.
> Like, yeah, once the secure way is sufficiently easy to use, we can then push everyone off the insecure way; that's how it's supposed to work.<p>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.<p>That is why people are so pissed, there is absolutely zero control over what the large browser manufacturers decide on a whim. It's one thing if banks or Facebook or other truly large entities get to do work... but personal blogs and the likes?
We've reached a point where securing your hobby projects essentially means setting the "use_letsencrypt = true" config option in your web server. I bet configuring it takes less time than you spent reading this HN thread.<p>And with regards to the beancounters: that is <i>exactly</i> 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 <i>forcing</i> 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.
> 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?<p>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.
> but personal blogs and the likes?<p>Yep, the result of the current security hysteria/theater is it makes it increasingly difficult to maintain an independent web presence.<p>Yes, I know, you can just use Cloudflare and depend on it...
TLS only takes a few minutes to add to a self hosted solution, just plop caddy in front of your server
Cloudflare uses HTTP to connect to your website before caching the content. I’ve always found it highly insecure. You could have HTTPS with Letsencrypt, but you need to deactivate Cloudflare when you want to renew (or use the other validation that is complex enough that I didn’t succeed to do it).
Don't pick on this particular SSL requirement, pick on the deluge of requirements that only make sense for a site that sells something or handles personal data (i.e. has accounts). They get extended to $RANDOM_SITE that only serves static text and the occasional cat photo for no good reason except "your cats will be more secure!".
GP: At least on business plans this is incorrect, it defaults to (last time I checked) accepting any SSL certificate including self signed from edge to origin and it’s a low friction option to enforce either valid or provided CA/PubKey certs for the same path.<p>Parent: those innocuous cat photos are fine in the current political climate… “First they came for the cat pic viewers, but I did not speak up…”
Wrong metaphor though?<p>How does SSL on a -ing public site protect you from being arrested by miniluv?<p>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 <i>prove</i> or are supposed to prove identity not hide it.
The statement that Cloudflare uses HTTP to connect to your website can be false depending on how you configure it. For years, I have had personal websites with Cloudflare as the CDN and with Let’s Encrypt providing certificates on the web server. All I do is choose Full (Strict) in the TLS settings on Cloudflare. So the connection between the end user to Cloudflare and from Cloudflare to my web server are on HTTPS. No deactivation of Cloudflare required on my end during renewal (my web host, like many others, has the certificate generation automated and getting a TLS certificate just a toggle on my admin dashboard).
I can understand this in in certain contexts, such as a site that exists solely to post public information of no value to an attacker.<p>A local volunteer group that posts their event schedule to the web were compelled to take on the burden of https just to keep their site from being labeled as a potential threat. They don't have an IT department. They aren't tech people. The change multiplied the hassles of maintaining their site. To them, it is all additional cost with no practical benefit over what they had before.
The work and technical expertise to setup let's encrypt is less than the work to register a domain, set up a web server, and configure DNS to point to it.
You seem to have missed what I wrote in the first place: They aren't tech people.<p>It is additional work, and requires additional knowledge.<p>It was also not available from most of the free web hosts that sites like these used before the https push. So investigating alternatives and migrating were required. In other words, still more work.
This is why more and more organizations get away with only having social media pages where they don't have to worry about security or other technical issues.
Unfortunately, placing the information on a social media page burdens the people seeking it with either submitting to the social media site's policies and practices, or else not having access to it. This is not a good substitute.<p>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.
I have heard, but do not aggree, that Let‘s Encrypt is risky, because phishing sites use it. It’s implied that other CAs do checks against it.
An SSL provider once refused to sell me a certificate because the domain name had the word "Windows" in it.
I will say, I have never before this season seen so many seemingly-legit fake web stores. All with their little lock icons in the address bar. I assume LLMs helped kick it into overdrive too
Old browsers on old hardware without its CA baked in.
Seconding the effect of Let's Encrypt on the world of TLS. I remember getting into web applications in the late 2000s and rolling my own certificates/CA and it was a huge, brittle pain. Now it's just another deployment checkbox thanks to LE.
I have worked at companies that refused to use LetsEncrypt for the same reason.
> It coming from GoDaddy is not a selling point...<p>I just people who use GoDaddy. They were the one company supporting SOPA when the entire rest of the internet was opposed to SOPA. It's very obvious GoDaddy is run by "business-bros" and not hackers or tech bros.
> has anyone actually commented to you in a negative way about using Let's Encrypt?<p>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.<p>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".<p>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.<p>In a business environment getting a donation approved is almost always an entirely different process, involving completely different people in the company, than getting a product or service purchase approved. Even more so if, like Let's Encrypt, you are turning up on the doorstep asking for $50k a pop.
“They sent a few emails soliciting donations” isn’t exactly a horror story in my experience. Seems hardly worth mentioning!
It's not something to stop using them over, but unsolicited solicitation emails are annoying at the least. It's definitely worth mentioning letting other people know they have warts too
To be clear, I was merely answering the question posed <i>"has anyone actually commented to you in a negative way about using Let's Encrypt?"</i><p>Well, yes, someone actually commented to me in a negative way about using Let's Encrypt ....<p>Don't shoot the messenger, as they say.
><i>one day they started getting hounded by Let's Encrypt multiple times</i><p>><i>trying to get a small company to shell out $50k as a "donation".</i><p>><i>Even more so if, like Let's Encrypt, you are turning up on the doorstep asking for $50k a pop.</i><p>Does your friend have anything to corroborate this claim? Perhaps the email with identifying details censored?<p>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 "<i>hounding</i>" and requests for $50,000.
All the usual phishing checks were done if that's what you're thinking.<p>In terms of the actual mail with identifying details removed, I'd have to go back and ask.<p>I did look before posting here as I thought they had already forwarded it to me, but it was last year, so I have almost certainly cleaned up my Inbox since. I'm not an Inbox hoarder.
It’s easy to forget how awful TLS was before Let’s Encrypt: you’d pay per-hostname, file tickets, manually validate domains, and then babysit a 1-year cert renewal calendar. Today it’s basically “install an ACME client once and forget it” and the web quietly shifted from <30% HTTPS to ~80% globally and ~95% in the US in a few years.<p>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.<p>The next 10 years feel harder: shrinking lifetimes (45-day certs are coming) means “click to install cert” can’t exist anymore, and there’s still a huge long tail of internal dashboards, random appliances, and IoT gear that don’t have good automation hooks. We’ve solved “public websites on Linux boxes,” but not “everything else on the network.”
Just a few months ago my company was going through some transitions and wanted to get some certs to cover us while we migrated to a different stack with let's encrypt and automated cert renewals.<p>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.<p>The company we were using wanted to charge us $30,000 for a one year cert with that many wildcards.<p>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.<p>I can't believe there is a market for $30,000 certs anymore. We were just shocked that that was deemed a reasonable price to charge us.
I think the best analogy for this are scams. Once a scammer finds a mark they'll pay, there's a desire to soak them for as much as they'll bear.<p>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%.<p>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".<p>So yeah, there's still a market for people wanting to throw money at CAs, even in these comments you'll see some. And management types are especially prone to "sounds expensive, must be good" logic when spending other people's money.
I think you've left out the ecosystem of semi-scam, without that the decisions look less logical.. If you go and add a private rootCA to all your servers there are risks. You can convince yourself the risks are covered, you can convince a highly qualified security analyst. Can you convince a business intern with a checklist hired by a certification firm that underbid the one with specialists? 30K to engage with no one on the topic starts to look ideal.
Both Let's Encrypt and 3-year certificates were introduced in 2015. We had 5+ year certificates before that. At the time you'd buy the longest certificate possible and forget about it--that's what I did. In 2013 I bought a 5-year certificate (self-service, no tickets) and didn't think about it again until 2018.
For IoT myself i'm wondering if it's something that could be thrown into the Matter side of things, make the hub/border router act as an ACME server with it's own CA that gives out mTLS certs so the devices can validate the hub and the hub can validate the devices. It'd never be implemented properly by the swarms of cheap hardware out there but I can dream...
But why?<p>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.<p>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.<p>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: <a href="https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-persist" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-pe...</a>
My experience was: get 3-year certificate for free, install it and forget about it. With LetsEncrypt, it's always pain, expired websites everywhere. Too bad that american IT mafia put these good CA out of business.
I was about to say that I never encounter TLS errors while browsing, but that's not strictly true. There is one such website, and it's only because the webmaster had a stroke and can't maintain it currently. But apart from that rather sad story I can't relate to your issues at all.
American IT Mafia? That provides free certificates? You'd think setting up renewal would be less of a hassle than dealing and paying CAs even if it's once every 3 years, so that would be a rather benevolent mafia. Which of those CAs went out of business by the way?<p>Do you think Let's encrypt is less popular outside the US?
StartSSL, WoSign were the ones I've used. Very convenient services, much more convenient, compared to this certbot insanity.<p>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.<p>Hopefully, over time, China and Russia will destroy this superiority and will provide viable alternatives.
What else is kept behind paperwork and fees that could be freed?
As a sysadmin in the 2007-2011 timeframe I literally used openssl to generate csrs, went to godaddy to purchase SSL certificates and then manually deployed them to servers. Man what a world of change. Let's encrypt is one the best services we've had on the internet. I wish we had more things like this.
It's been a long time so this is my fading memory, but CAs used to generate a private key on their end and let you download both private key and the certificate containing the public key. The non-technical person who paid big money for the certificate then emails the zip file to the developer. That's when StartTLS wasn't that big back then either.<p>Just comically bad way to obtain certs.
As a sysadmin in 2020 - 2024 time frame I used to do that all the time at my previous job, got a strong openlssl cli game going whenever needed to generate a new csr for existing key or new key and shovel an exact amount of SANs into the CSR too. Lot of time wasted. There were also a certain set of customers for which we managed systems and they insisted for it to be done this way as something free on the internet is not to be trusted. Oh well, strange times.
Would be cool to have it for S/MIME too.
Ah man, I remember those days. So tedious!
i was doing this until a couple years back when a friend told me about LetsEncrypt! It's like <i>magic</i>!!
Snowden was the other big reason that TLS became the de facto standard for every site.<p>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.<p>I remember listening to a talk given by an IRS investigator in around 2008 about how they were able to do a sting and shutdown illegal internet casinos. They collected a good bulk of that evidence from clear-text packet captures of gambling sessions and messages. He preemptively answered the question of whether encryption was a hurdle, by saying no one used it.
This is a retcon. Facebook rolled out TLS in 2011, 2 years before Snowden, and went TLS-by-default within a month of the Snowden disclosures. Google Mail was TLS-by-default in 2010. TLS was a universal best practice long before 2013 --- by 2010, you'd have gotten a sev:hi vulnerability flagged on your site if you hadn't implemented TLS. SSLLabs was 2009; BEAST was 2011, and was a huge global news story because of how widely deployed TLS was.
I think you're right that this consensus was clearly emerging then (I remember Firesheep in 2010 as another big identifiable contributing factor), but I remember actively asking <i>smaller</i> sites to enable HTTPS in that era, and they would often refuse. So I think Snowden also contributed to the spread of the norm.<p>It is possible that there's a retcon element, because it's not always clear in my memory exactly what year various sites became more favorably disposed towards the request to use HTTPS. So I could be misremembering some of them as agreeing post-Snowden when they'd actually agreed one year before, or something.
I'm not sure that refutes the idea that encryption was uncommon. A couple tech giants with challenging threat models will be ahead of the curve.<p>Google started tracking adoption of TLS in 2015, with adoption below 50% and some regions below 30%.<p><a href="https://transparencyreport.google.com/https/overview?hl=en" rel="nofollow">https://transparencyreport.google.com/https/overview?hl=en</a>
Yes. And I remember sniffing Facebook traffic in clear text in 2011. The fact remains that it was considered a significant engineering problem for them to deploy it. It was a "best practice" that most people rolled their eyes at.<p>Most users and system owners didn't care unless money was being transacted.<p>Between Snowden and ISPs injecting content into pages, the consensus changed.
I think it was a lot earlier than 2013 - SSL was inevitable by the late 2000's, as soon as major ISPs decided they could make more money by injecting ads into http connections (e.g., [1]). It obviously took a while for the infrastructure to scale up ... but I'd imagine that concerns about stolen ad impressions drove a lot more HTTPS adoption than concerns about the NSA.
One domain parking actor is responsible for nearly 10% of all issued ssl certificates. 185.53.178.99. This is just one of many bad actors.
Lets hope they stay independent and <i>never</i> get acquired by Google or any other large tech company. You can imagine a web where SSL issuance is used as a tool to censor websites. I think most browsers have been made to make standard http sites look malicious to normal users.
They're a nonprofit - so they can't be acquired like a typical for-profit company. They could in theory sell some assets but it'd be very convoluted if they were the core assets -- per US tax law, nonprofit assets must remain in the nonprofit world, so there's no risk of any tech company ruining them.
Look at OpenAI - where there’s a will (and an army of lawyers), there’s a way. That said, I don’t think any of the big tech orgs would be interested in acquiring them. Google and Amazon even already have their own public CAs that are in the major trust stores.
I heard similar things about another American nonprofit and now I'm not so sure about it. When money and will comes along, loopholes come as well.<p>So, I wouldn't be so sure, unfortunately.
If Google wants to censor your website, they have a variety of other, more effective methods, like by adding it to their safe browsing blacklist, which is also used in many Firefox installs.
As someone else mentioned, it's a non-profit, so I guess it's not technically possible to get acquired.<p>But I personally believe that the people behind LetsEncrypt genuinely care about the mission and will never sell out for their personal benefit.<p>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.
I still remember the original announcement around LE and thought "Great idea, no idea if they'll be able to get buy-in from browsers/etc", now I use it on all my self-hosted sites and will probably be transitioning my employer over to it when we switch to automated renewal sometime next year.<p>LE has been an amazing resource and every time I setup a new website and get a LE cert I smile. Especially after having lived/experienced the pain that was SSL/TLS before LE.
LetsEncrypt is on my end of year Donate list for the past 5 years. With all modern browsers requiring HTTPS everywhere, a world without Let's Encrypt would be really difficult for indie developers.<p>Thank You for an amazing product!
New baseline expectation that web traffic will be encrypted on the wire: very good!<p>New de-facto requirement that you need to receive the blessing of a CA to make use of basic web platform features... not so good.
Can you elaborate a bit about what you mean by "the blessing of a CA"?<p>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: <a href="https://letsencrypt.org/2015/10/29/phishing-and-malware.html" rel="nofollow">https://letsencrypt.org/2015/10/29/phishing-and-malware.html</a>
Their policy today is to grant certificates liberally. There is no technical guarantee that this remains the case indefinitely, only a political one. I don't doubt the sincerity of this guarantee, but I wish I didn't have to rely on it.
A big factor is that they are serving <i>so many certs</i>, with only a tiny amount of funding. Anything beyond the most basic pre-written list of blocked domain names is infeasible. Analyzing the content of every single domain would increase their resource needs by several orders of magnitude. That's reasonably close to a technical guarantee, if you ask me.
I agree that technical guarantees are better than policy guarantees.
That's not new, LetsEncrypt just didn't solve it. And if you think this is the only single point of failure in the stack, I have news for you.
Kinda hear you, but DNS is a defacto requirement as well. Neither DNS (common TLDs) nor any of the major cert vendors I'm aware of ask you your site's business before issuing.
Let’s Encrypt is something so amazingly valuable that I was certain it’d be killed dead within a year to prop up the existing SSL cert business.<p>Congrats on a decade, ya’ll, here’s to many, many more in securing the free internet.
I use Let’s Encrypt. It is an amazing service and I am forever grateful.<p>However, it is time for a second source of free certificates. It is not good that we rely on one supplier.
I am glad to be one of the users using that for around 7 years. I can't think of how much better is life of people just doing blogs or some silly websites with free https certs. Would I pay 50$ bucks a year for ability to self host nextcloud? Probably not. But security enhancement is so enormous with that service.
Thanks to everyone involved for making world a little bit better.
I am so grateful for this. Bummer that they stopped with the email reminder, anyways I was wondering how this would work without active payments. Still amazing.
only downside to LE is the attack surface presented by CTLs (Certificate Transparency Logs). as soon as you request a cert, you will get attacks on the endpoint/subdomain you have registered by countless IPs trying to login etc.
Wow. Feels like Let’s encrypt been around for longer.
Agreed! What were we using before Let's Encrypt again? Maybe just plain HTTP
Mostly Verisign, which required faxing forms and eye-watering amounts of money. Then Thawte, which brought down prices to a more manageable US$500 per host or so. Which might seem excessive, but was really peanuts compared to the price of the 'SSL accelerator' SBus card that you also needed to serve more than, like, 2 concurrent HTTPS connections.<p>And you try telling young people that ACME is a walk in the park, and they won't believe you...
And then sketchy resellers for Verisign/Thawte, which were cheap but invariably had websites that ironically did not inspire confidence in typing in your credit card number.
As GP posited, because of this headache, lots of web traffic was plain ol' HTTP. Let's Encrypt is owed a lot of credit for drastically reducing plain ol' HTTP.
I was using StartCom StartSSL which was offering free 1 year certificates at least for my personal sites.
They were great in the beginning, and then when you issued a few more certs than they liked you were asked to pony up some $$$, and then when you did that and actually "verified" who you were on a personal international phone call, you got a grace, and then issued a few more, they decided they didn't like you so they would randomly reject your renewals close to the expiration date, and then they got bought out by some scummy foreign outfit which apparently caused the entire CA to be de-listed as untrustworthy in all major browsers. Quite the ride.<p>Also, the only website I've ever encountered that actually used the HTML <keygen> tag.
Self signed certs. I wasn't paying.
SSL/TLS via expensive and hard to work with providers and tooling. Let's Encrypt made it free and easy to maintain.
either you used http, self signed if you did not mind the warning, and i remember there being one company that did offer free certificates that validated, but cant remember the name of it
> i remember there being one company that did offer free certificates that validated, but cant remember the name of it<p>You're probably thinking of StartSSL, and it was a bit of a pain to get it done.
I believe it was StartSSL and/or WoSign back then
The pros were using client-side encryption :D
I was going to say the opposite. LE still feels like the "new" way, to me. :)
Thank you Let's Encrypt, together with the acme.sh , caddy and the whole ecosystem for TLS.<p>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.
10 great years.<p>For the next years I'm hoping for more resilience/global distribution in the issuance process. Since I live on an island for about half the year I do have experience with internet outages, and we do appear to live in turbulent times. That could be an issue with the ever decreasing certificate lifetime. I'd love to see LE exploring options like working with ccTLD registrars to work on local issuance.
Another amazing success born at Mozilla:<p>"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."<p><a href="https://en.wikipedia.org/wiki/Let%27s_Encrypt" rel="nofollow">https://en.wikipedia.org/wiki/Let%27s_Encrypt</a><p>What was Mozilla's role, beyond conception? Parenting? Care and feeding? A roof?
A lot of this is covered in the Let's Encrypt retrospective paper from 2019: <a href="https://www.abetterinternet.org/documents/letsencryptCCS2019.pdf" rel="nofollow">https://www.abetterinternet.org/documents/letsencryptCCS2019...</a>.<p>From Section 3.1.<p>"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.<p>...<p>Initially, ISRG had no full-time staff. Richard Barnes of Mozilla, Jacob Hoffman-Andrews of EFF, and Jeff Hodges (under contract with ISRG) began developing Let’s Encrypt’s CA software stack. Josh Aas and J.C. Jones, both with Mozilla at the time, led infrastructure development with assistance from Cisco and IdenTrust engineers. ISRG’s first full-time employee, Dan Jeffery, joined in April 2015 to help prepare the CA’s infrastructure for launch. Simultaneously, James Kasten, Peter Eckersley, and Seth Schoen worked on the initial ACME client (which would eventually become Certbot) while at the University of Michigan and EFF. Kevin Dick of Right Side Capital Management, John Hou of Hou & Villery, and Josh Aas constituted the team responsible for completing a trusted root partnership deal and signing initial sponsors."
You can ask them; both Josh and Eric are HN people, and Erik is already on this thread. :)
This is something that legitimately made the world a better place.
Getting yourself an IP address certificate still seems like an idea that's too crazy to work. I'm actually looking forward to seeing all the things breaking by becoming more secure.
10 years and still no S/MIME.
Is there a notion of tier 1 and tier 2 certificates? Like if I setup paid and backed by contract agreements with a cert provider, does this give users more confidence that their lock icon in the browser actually means they are talking to who they think they are?<p>It's one thing to provide a cert to provide secure encrypted TLS, it's another thing to establish identity with the user. Though, most users would never notice either way.
There are Extended Validation (EV) certificates, and for a couple of years browsers gave them special treatment (typically, a green lock indicator instead of gray, sometimes accompanied by the validated business name). However, they were eventually demoted to the same appearance as ordinary Domain Validation (DV) certificates for a couple reasons:<p>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.<p>2) Validation gets dicier as the world gets opened up and as laws and customs change. The higher tier confers greater prestige and legitimacy, but the only discriminator really backing it is money.
Yea, this was what I thought I'd dealt with before but I couldn't remember.<p>It's too bad the same hasn't happened to software notarization and signing systems.<p>People will argue that having payments enforced some accountability, but I'm not really convinced.
Still not convinced it's not a honeypot. Would like to see concrete evidence.
Incredibly grateful for this project
I'm not sure that I'm more surprised that it's only been 10 years or that it's been that long. I mean, that's a relatively quick turn around to pretty much dominate TLS certs to the point that it's the default for so many platforms... that HTTPS has become such a norm over the exception.<p>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.<p>I mean, by comparison, it feels like IE6 took longer to die than Let's Encrypt has been around.
my friends work here!
and it was founded by an alum from my school Macalester College
A couple of years ago, I went through the process of signing a kenel minifiter that I wrote for our endpoint-security product. It was complicated, to put it mildly.<p>Imagine if we had a similar process for websites! Thanks Let's Encrypt.
Yes let's. But that doesn't answer my question.
The thing that has made me feel the oldest this week is that someone I used to mentor posted a holiday pictures with visible wrinkles. If people you think are young look old, then buddy, check the mirror.<p>But this is a close second. 10 years? That can't be right. Even accounting for Covid Time Dialation.
Just 10, it feels like more.
it is hard to believe it's been ten years.
That is awesome i love how you change the TLS Scene for ever! Keep pushing it!
Next step: Let's Tor?
LE has been really great, particularly in running hobby web sites on the public internet. Getting certbot up and running wasn't hard, automating renewal wasn't hard, and because they have DNS-based pathways to verification you can use LE certificates for sites not exposed to the public internet as well. Combine it with something like Caddy and getting SSL for an app becomes the default without ever having to manage certificates by hand.<p>I find it pretty amazing how far its come, and how big a change it has made to the internet in the decade it's been operating.
The next steps:<p>1. Add support for DNS-based persistent authentication: <a href="https://datatracker.ietf.org/doc/draft-ietf-acme-dns-persist/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-acme-dns-persist...</a><p>2. Allow the user to just publish their public key into that TXT record.<p>3. Cut out the middleman and do the authentication directly in the browser.<p>4. DANE
For someone who runs a small personal website and uses LE to secure this + some web exposed services, could you explain how this is different/better than acme-dns-certbot?
DANE isn't going to happen, and if you want to tilt at that windmill, it's Chrome and Mozilla you need to pressure, not LetsEncrypt.
Would be interesting to hear what database they are using and how they are doing replication? Is it simple master / slave or multi-master?
Let’s Encrypt currently has a single primary with a handful of replicas, split across a primary and backup DC.<p>We’re in progress of adopting Vitess to shard into a handful of smaller instances, as our single big database is getting unwieldy.
<a href="https://github.com/letsencrypt/boulder" rel="nofollow">https://github.com/letsencrypt/boulder</a><p>You can find a docker-compose.yml file to get some idea.<p>Appears to be using MariaDB.<p>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.<p>For Certificate Transparency, they are submitted to Google and CloudFlare run trees but I don't think LetsEncrypt run their own logs.
Let’s Encrypt does operate CT logs. I wrote a blog post about our current-generation logs at <a href="https://letsencrypt.org/2024/03/14/introducing-sunlight" rel="nofollow">https://letsencrypt.org/2024/03/14/introducing-sunlight</a>
I assume they want to store metadata instead of having to pull from the certificates itself, but maybe that’s actually easier and more performant.
They helped change the security game, hats off to Let's Encrypt making it accessible. I remember when people would get upset about having to pay 400$ for a cert from go daddy nearly 2 decades ago. Google pushing the HTTPs requirement was also a good thing and Let's Encrypt made it possible for many that otherwise wouldn't have bought a cert in the first place.
thank you for your service
> 10 Years of Let's Encrypt<p>Aren't they only 45 days [1] old ?<p>[1] <a href="https://letsencrypt.org/2025/12/02/from-90-to-45" rel="nofollow">https://letsencrypt.org/2025/12/02/from-90-to-45</a>
Not sure if you're joking or not, but I have to deal with this upcoming change at some point and still haven't read in detail why they decided to do this.<p>Could anyone clarify?
Hi there, ISRG co-founder and current board member here. In brief, shorter lifetimes force people to automate (which, e.g., avoids outages from manual processes) and mitigates the broken state of revocation in the Web PKI. That latter point especially is what I understand to be driving the Web PKI toward ever-shorter lifetimes.<p>I actually remember the discussion we had in ~2014 about what the default certificate lifetime should be. My opening bid was two weeks -- roughly the lifetime of an OCSP response. The choice to issue certificates with 90 day lifetimes was still quite aggressive in 2015, but it was a compromise with an even more aggressive position.
With the move to ever shorter certs the risk to letsencrypt having an outage is higher.<p>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.<p>Do you publish any of this? DR plans? Etc.<p>I don't mean for this to be a negative - really impressed by LE - but we've had a lot of Cloudflare outages recently and my mind is on vendor reliability & risk at the moment.
Considering how many ACME clients are available today with all sorts of convenient features, and that many web servers nowadays have ACME support built in (Caddy, Apache mod_md, and recent Nginx), I believe that people who don't automate ACME certificates are the people who get paid hourly and want to keep doing the same boring tasks to get paid.
Because big companies have a habit of growing layers of bureaucracy. If a cert is valid for three years, a decent bunch of them will invent a three-month process around cert renewal, involving two dozen stakeholders, several meetings, and sign-off from the CTO.<p>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 <i>too</i> much damage before that. CAs in turn have large (=profitable) customers which such processes who they <i>really</i> 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.<p>The only way to solve this is to <i>force</i> 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 <i>every CA</i> is doing it, companies don't gain anything by switching to more lenient CAs, so the individual CAs have no incentive to violate the industry rules by delaying revocation.
Lets Encrypt are doing is because of the decision that CAs and browser makers made that it needs to be reduced (browsers have been reducing the length of certs that they trust).<p>The why is because it's safer: it reduces the validity period of private keys that could be used in a MITM attack if they're leaked. It also encourages automation of cert renewal which is also more secure. It also makes responding to incidents at certificate authorities more practical.
> it reduces the validity period of private keys that could be used in a MITM attack if they're leaked<p>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.<p>If cert compromise is really common enough to require a response then the cert lifetime should be measured in minutes.
Wow, this might be the push I needed to automate certificate renewal on my personal website [0].<p>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.<p>[0]: <a href="https://danverbraganza.com" rel="nofollow">https://danverbraganza.com</a>
And that is the very point of the short life span. One year certs had the potential of the person responsible for the cert no longer being the same person at time of renewal. Making it easy to automate so that it was just a cron task meant it didn't matter how often the person responsible changed.<p>Your pain and intolerance to that button push proves their intent.
Heh, as I was saying about shorter lifetimes encouraging automation...<p><a href="https://news.ycombinator.com/item?id=46210786">https://news.ycombinator.com/item?id=46210786</a>
Reminder that it’s a non profit
[dead]
[flagged]
You might want to be more specific about the meaning of "between" here. It's not a cryptographic MITM attack, and if it ever facilitated someone else in performing one, that should be detectable.<p><a href="https://en.wikipedia.org/wiki/Certificate_Transparency" rel="nofollow">https://en.wikipedia.org/wiki/Certificate_Transparency</a><p>(It's also true that the level of active monitoring of CT logs has never gotten very high.)
It's not like Let's Encrypt is the only game in town, Actalis in Italy provides free ACME certs too if you'd prefer to keep things in Europe.
Not sure if there is a point to "keep things in Europe" when it come to certificate authority.<p>- LetsEncrypt don't have the private key tied to your certificate
- Any of the Certificate Authorities could potentially emit unauthorized certificate<p>Your only protection for all of these problems is HPKP. If you prefer to keep things in Europe, keep that pinned private key in Europe, but the rest doesn't matter.<p>That said, it's pretty nice that LetsEncrypt forced the ACME protocol on this industry. Not only it create redundancy with mostly interchangeable alternatives but before ACME, there was no way to fully automate certificate provisioning cleanly.
Just to clear up one point -- Let's Encrypt did not at all force ACME on the industry. We deliberately took it to the IETF so that we could get input from more parts of the industry (including some major refactors!). Instead of pressure from Let's Encrypt, I would attribute its success to the open process of the IETF, the awesome open-source community that made great ACME software (shoutout to Matt and Caddy!), and the resulting pressure on CAs for a better user experience from users and customers.
I didn't express myself well but what I meant by force is that by building a standardized to automate way manage certificate, ACME imposed itself and became mandatory.<p>Previously, most CA had no programmatic way to order certificate, it was all done manually.<p>As far as I know, the only providers with that would let you automate certificate provisioning at the time where Comodo, GlobalSign and Digicert.<p>They all had their own quirky API. Just to give you an idea, we ended up selecting GlobalSign at Shopify a few years before LetsEncrypt, and it was this SOAP nightmare: <a href="https://www.globalsign.com/en/repository/GlobalSign_Client_API_User_Guide.pdf" rel="nofollow">https://www.globalsign.com/en/repository/GlobalSign_Client_A...</a><p>At first none of them were warm at the idea of providing an ACME endpoint. I'm assuming part of it is the cost of implementing it but they probably liked the stickiness of their custom APIs too tied to million dollars contracts.<p>Nowadays they all implement ACME. At some point, they where effectively forced to implement it to acquire new customers and keep their existing base around because nobody would accept poorly designed custom made protocol anymore.
Their website seems to suggest the renewal isn't free?
They are definitively not the most shady organization in the CA/Browser Forum.
Let's Encrypt allows anyone to have secure https communication, sure, but it doesn't address the question of website authenticity. I groan when I'm on an e-commerce site and I click on the browser URL lock icon and see a Let's Encrypt certificate because frankly anyone can create one for no cost and I don't know if it's the real website or if I made a URL typo. Say what you will about the expensive cert providers, but it's reassuring when you see DigiCert or Sectigo - with a company name and the address of the head office.
It was never a reasonable goal of the WebPKI to authenticate entities; only to help establish end-to-end encryption between unrelated parties on the Internet. The WebPKI can ensure you're talking to whoever controls `ycombinator.com`, but it has to be up to some other layer of the security stack to decide whether you <i>want</i> to be talking to `ycombinator.com`. (This is in fact part of the logic behind FIDO2 and phishing-proof authentication).
> It was never a reasonable goal of the WebPKI to authenticate entities<p>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).<p>I agree with you that the goal of authenticating entities was impractical, but the mental association and expectation around it still hasn't been completely dispelled. (I think I saw some form of this when doing support on the Let's Encrypt Community Forum, as people would sometimes complain that a site shouldn't have been allowed to have a certificate, either because it wasn't the organization they expected, or because it was malicious somehow.)
Right, and when people who haven't paid that much attention to the machinations of the WebPKI (who could blame them) talk about how weird it is that the browsers killed EV, this is an important part of the backstory: EV was mostly a failed attempt to make the WebPKI do this kind of "do-what-I-mean" entity authentication.<p>The problem as I see it is: there simply isn't one coherent global notion of what entity authentication means. It's situational.
FIDO2 doesn't solve the first website contact trust problem - only the HTTPS certificate does that.
To prove a very important point, that EV certificates are broken, someone obtained a "Stripe Inc." EV certificate by registering a company in a different state.<p><a href="https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/" rel="nofollow">https://arstechnica.com/information-technology/2017/12/nope-...</a><p>(The original site is no more, but this Arstechnica article has screenshots and a good summary)
Not really the point of ssl certs though. And I'm pretty sure those limitations are the smallest hurdle, most people wouldn't even care checking.