Hi Let's Encrypt Team and Community,
I've read previous PRs and FRs on this, on these forums and GitHub, and I know that this will probably seem like the dumbest idea you've seen in 2024. So I kind of feel bad to be most probably wasting your time with this fringe request (plus this is too verbose, major apologies!). But I don't know who else to ask - so, here goes nothing!
First, I want to thank you for securing the Internet! When I first got my cert in early 2016 it completely change my life. No more relying on GitHub pages. I could run my own secure services on my own VPS and it completely blew me away how easy it was. Install the python client, do a few commands, and I had a real cert trusted just like the big sites. It was mind blowingly cool. And that is still true today, so thank you!
Also, I want to support you in that I completely understand that issuing HTTPS certificates for .onion domains might seem like a complex challenge. Let's be honest as a community, I've read the repeated FRs for this, but there are legitimate reasons why it hasn’t been prioritized.
Verifying ownership of .onion domains isn’t straightforward like it is for public DNS, and implementing .onion support would require significant design, engineering, and compliance efforts on your part.
The issue of maintaining rate limits for services tied to cryptographic key pairs rather than DNS could also add complexity. And also, there’s the massive elephant in the room: Tor has historically been associated with the darker corners of the internet, the evils of the Dark Web, and aligning Let’s Encrypt too closely with a network used for privacy and anonymity may raise concerns.
But it's not just that: even more understandably, Let’s Encrypt may not want to be seen as enabling a direct competitor. Tor and Let’s Encrypt both share a common mission to encrypt and secure the web—but in some ways, they’re approaching similar goals from different directions. Supporting .onion certificates might feel like bolstering a competitor in the “encrypt everything” movement, as well as a betrayal of the values of freedom Let's Encrypt stands for. Plus! -- you have Tor’s somewhat controversial funding sources, including the U.S. Department of Defense, and it’s not hard to see why some people, LE included, will absolutely not pursue this.
I see all these concerns as totally valid, and I get it: Let’s Encrypt has to balance massive priorities. It has a incredibly global responsibility. And trust is a key part of the business, in which reputation is unavoidable. Even associating with Tor could harm that, effectively impacting the millions of users that depend upon your team and organization. I totally get why Let's Encrypt may never pursue Tor support, and that's fine and understandable.
You are all likely super busy improving core infrastructure, scaling to meet growing global demand, and handling major features like short-lived certificates or IP-based certificates. Even all the business risk aside, .onion support may just not be the highest priority right now.
I may not fully understand all the complexities, but I believe this could be a conversation worth revisiting. An opportunity for innovation, even.
On our end, at CloudTabs, we’ve recently added Tor support to allow users to run their browser sessions as Tor hidden services, making them accessible via the Tor Browser. We use HTTPS not only to enable certain browser features but also to ensure end-to-end encryption (E2EE). While Tor encrypts traffic between nodes, the final hop isn’t fully protected unless HTTPS is in place. In short, HTTPS protects the “final mile”—a critical aspect that’s often overlooked.
In our case, each browser session dynamically generates a new Tor service ID, and we currently rely on mkcert to provision local HTTPS certificates. While functional, this approach has major drawbacks. Users are forced to click through an invalid certificate warning in the Tor Browser, which hurts the experience and erodes trust. Unfortunately, even adding mkcert's root certificate to local keychains no longer bypasses this, leaving users stuck with these warnings.
The obvious, ideal solution here would be to issue certificates from a globally trusted authority like Let’s Encrypt, but it's understandable why not. Since the CA/B Forum allowed CAs to issue certificates to .onion addresses in 2020, it’s clear that this is not an impossible task. Some authorities have done so but their offerings leave much to be desired, reeking of the kind of legacy stagnant bureaucratic process that Let's Encrypt completely myth busted!
As of September 2024, Let’s Encrypt has not yet implemented these changes. While some larger platforms (like DuckDuckGo and the NYT) use these other CAs for their .onion HTTPS certificates, they do pay for this service (even for the vanity of special names) making it prohibitive for most privacy-conscious developers, and a hard no for our "on the fly" use case.
Why Let’s Encrypt Should Never Do This
-
Verifying Ownership Complexity: Verifying ownership of .onion domains is not as simple as public DNS. DNS has well-established mechanisms for domain ownership validation, whereas .onion domains derive from cryptographic key pairs, necessitating entirely different validation methods, adding technical and compliance challenges.
-
Rate Limiting for Onion Domains: Traditional domains can be rate-limited by IP address or DNS entries. However, .onion domains can be generated dynamically on the fly, raising concerns about abuse. Proper rate-limiting for these cryptographic key-based domains might necessitate significant infrastructure updates to prevent overuse.
-
Tor’s Reputation & Risks: Tor has often been associated with the darker parts of the internet, like the dark web, which could raise reputational concerns for Let’s Encrypt. Supporting Tor’s hidden services might align Let's Encrypt with potentially controversial uses of encryption and anonymity, leading to scrutiny by regulators, governments, and Let's Encrypt’s broader user base.
-
Tor as a Competitor: Both Let’s Encrypt and Tor share the mission to secure the web, but they operate in different spaces. Issuing .onion certificates might feel like supporting a competitor in the "encrypt everything" movement. Tor’s focus on privacy and anonymity may not align with the transparency principles that drive Let’s Encrypt’s global trust initiatives.
-
Insignificange: Fundamentally, Tor traffic is infinitesimal compared to the Internet as a whole, and this issue probably simply does not have the weight to really move the needle, so why should it deserve your attention? It's a fringe and a minor issue, basically, even despite Tor's importance in certain domains. It may be too minor in impact to justify Let's Encrypt doing it.
Yet, I think there's also other aspects to consider:
Why Let’s Encrypt Should Consider This
-
Securing the Final Hop: As the Tor Project notes, the final connection between the Tor exit node and the destination server is not protected unless HTTPS is in place. By providing .onion certificates, Let’s Encrypt would ensure that this crucial step is secure, protecting sensitive communications across the entire pathway.
-
Enhancing User Experience & Trust: Self-signed certificates trigger browser warnings, eroding user trust. Let’s Encrypt’s trusted certificates would eliminate this friction, allowing users to trust .onion sites in the same way they do public domains, providing a seamless browsing experience for privacy-focused users.
-
Rate Limiting is Manageable: Although .onion domains are tied to cryptographic keys, they can still be rate-limited using mechanisms akin to those applied to traditional domains. Public keys, for instance, could serve as unique identifiers to track and enforce rate limits, addressing concerns about abuse without requiring major infrastructure changes.
-
Proof of Ownership is Stronger: The ownership of an .onion address is directly tied to its private key, making it even stronger than DNS-based ownership verification. A CSR signed by the private key offers undeniable proof of ownership, and mechanisms like onion-csr-01 streamline this process, proving .onion validation is secure and feasible.
-
Aligning with Let’s Encrypt’s Mission: Tor’s mission to protect privacy aligns directly with Let’s Encrypt’s broader goal of securing the internet. Supporting .onion certificates would allow Let’s Encrypt to extend its influence to privacy-conscious communities, furthering its vision of universal encryption, especially for users who need it the most.
-
Empowering Activists & Journalists: Many .onion services are run by activists, journalists, and whistleblowers in hostile environments. Offering certificates for these services would amplify Let’s Encrypt’s global impact, playing a crucial role in securing communications for those most in need of protection from surveillance and censorship.
-
Existing Methods Simplify Implementation: While implementing .onion support requires engineering effort, much of the groundwork is already in place. Challenges like http-01 and tls-alpn-01 from the Baseline Requirements are compatible with .onion services. Moreover, the draft specification for the onion-csr-01 challenge could simplify this further, making .onion validation relatively straightforward.
How This Aligns With Let’s Encrypt’s Mission:
I think Let’s Encrypt has always been about making encryption accessible and universal. Supporting .onion services would enhance trust for privacy-conscious users who rely on the Tor network to protect their identity and data. By providing trusted HTTPS certificates for .onion domains, LE can improve the user experience across the Tor network, eliminating certificate warnings that erode user confidence and strengthening privacy protections.
Also, securing activists, journalists, and whistleblowers in hostile environments aligns directly with Let’s Encrypt’s broader mission of securing the internet for those who need it most. Offering .onion certificates would amplify Let’s Encrypt’s global impact by empowering vulnerable communities, playing a critical role in protecting their communications from surveillance and censorship.
Last, the growing adoption of privacy-focused platforms moving toward Tor means this isn’t just an edge case but a shift in how users and services interact online. Enabling trusted certificates for these services positions Let’s Encrypt as the forward-thinking leader in extending encryption to every corner of the web, ensuring it reaches communities who have historically faced barriers to access.
So... I know you've said no to this many times before, and I think many people are totally okay with that, I totally accept that and think that's valid. But I am just wondering: would it be the worst idea in the world to revisit the priorities around .onion certificates over the coming weeks? I get you probably don't have much room to budge on this. But if take an expanded look, is it impossible you find you have more room on this than you previously thought?
Anyway, whatever you do, thank you for simply existing and I get you're probably too busy to reply, so thanks for simply reading this far!
I think you’ve already done enough to make the internet safer, and Let’s Encrypt has always been about pushing boundaries, democratizing HTTPS, and making encryption accessible to everyone. This is why I believe you’re uniquely equipped to innovate here, even tho I'm sure it must feel like a long shot. And also why I have hope that you probably will do this, eventually. Anyway, whether you innovate around this or not, I’m super appreciative of everything Let’s Encrypt has done for the web.
Thank you!
Cris from CloudTabs
We're all excited to see this come to life and hope it’s on the horizon sooner rather than later! 
Keep up the awesome work!
Maybe just a minimum amount of time where you're certain it doesn't get implemented, but by no means an actual number you can count on.