Given that since 2020 it is allowed for LE to issue certs to .onion addresses (Tor Project | HTTPS for your Onion Service), and the philosophy of wanting everything everywhere encrypted, why 4 years later we still cannot get TLS certificates from LE for .onion sites?
Yes I know that everything to the .onion is encrypted, but the final mile isn't if your webserver sits on a different host. Also from a UX perspective people are having drummed into them to check that the certificate matches a site, which is hard for them to do when a certificate does not exist.
The only thing you really can't do (from a purely technical standpoint) with onion domains is the dns-01 challenge. The others should work fine.
The Baseline Requirements do allow issuance for .onion domains, and there's a working draft for an ACME extension (which also includes a new challenge specifically for onion).
I believe the main "pain point" for CA's is that they don't want to run a full-blown Tor client for everything. For instance @aarongablehas commented on the working draft last year, discussing the possibility of obtaining CAA data without requiring a Tor client (which is now part of the latest draft). Still, there are probably some rough edges left that need to be cleared up, but it does appear that this is somewhere on Let's Encrypt's agenda to do eventually.
Typically Let's Encrypt engineers are not willing to commit to a specific timeline though, but perhaps a LE engineer can tell us more about the current state of affairs?
Not really, according to appendix B of the current BR (2.0.5), CAs can use 3 regular challenges, including the http-01 challenge from RFC 8555 and the tls-alpn-01 challenge from RFC 8737, both being used by LE.
Should be the same, the BR mention "Domain Name" in appendix B and also draft-ietf-acme-onion uses the ACME "dns" identifier. So even though the .onion is a Special-Use TLD and not in the public DNS tree, I'm pretty sure everything just uses the regular "DNS" places, including the SAN.
So given that .onion addresses are just hashed ed25519 pub key (I think IIRC), why don't we provide a CSR signed by private key and then we can get a cert back that is pinned to our .onion because it was signed by the priv key?
It proves ownership because how can we sign with a private key we do not have?
Edit It's not even a hash as of v3, it's a complete public key, so surely we can just supply a CSR signed by the corresponding private key and receive a certificate back? There is no need to run tor to verify anything, just verify the signature on the CSR that it matches the public key (.onion) being requested. As for rate limit, you can rate limit per public key as if it is a domain now, and you can rate limit r4equesting IP as per usual.
What about a Certificate Signing Request? CAs can issue certificates when presented with a CSR yea? Given that the domain being requested is LITERALLY A PUBLIC KEY, surely a CSR signed by the corresponding private key 100% proves ownership, in fact it would not even be possible to prove ownership better than this, a signature from the priv key.
@tortxoFFoxtrot Please see draft-ietf-acme-onion for a new type of challenge specially for .onion hostnames, the "onion-csr-01" challenge. It's just a draft, so it doesn't have any implications on the current ACME servers and would need to be allowed by the CA/Browser Forum first, but you might find it interesting
Edit: Hm, it seems it's not actually a brand new challenge type, but an already current validation method provided by the Baseline Requirements in appendix B 2b. They probably want to formalise it in the RFC and make it compatible with ACME.
Yea I just looked, exactly this, server issues a 64 bit nonce and we sign it with priv key prove ownership by presenting CSR. Why are they taking so long with this we can do it today easy!
FWIW, latest mention of onion I can find in acme list is dated 2024-03-25: draft's author asks for comments, but apparently never receives any… Not sure what's the protocol to advance the draft's progress in such an instance.
Based on everything I've read here, I believe that my original comment still holds (for now). Having a possible way isn't the same as having a usable way in the present tense. Otherwise one would be able to get an LE cert for a .onion domain name presently.
Hi @tortxoFFoxtrot -- I'll second what others have already said: there are multiple methods for validating .onion names outlined in the Baseline Requirements, and the draft-ietf-acme-onion document further specifies the details of such. Let's Encrypt could implement support for these methods.
However, all such engineering projects have to be weighed against our other priorities. Right now, we're spending our engineering effort on improving our internal infrastructure for more robust deploys and more efficient database usage, working towards offering short-lived and ip-address certificates, completely overhauling how our rate limits work, and encouraging adoption of ARI.
Implementing domain control validation (and even more so, implementing CAA checking) for .onion domain names is not something "we can do today easy". It would require significant design, implementation, test, and compliance work. And although I appreciate that it is high priority for you, it is not high priority for the majority of our subscribers and for ourselves. I'm sorry that we haven't provided this feature for you yet, and have no plans to get to it in the near future.
It's not the pure coding that's the issue. Let's Encrypt is a very large publicly trusted CA. They can't simply add some "random" lines of code and push to production. Please appreciate that. All new features need to be scrutinised, as already mentioned by aaron.
Personally I find your post a little bit insulting and does not realise Let's Encrypt is not some random hobby project from an attic, but a professional CA that requires more than just some lines of code.
