Certificate for onion v3 address

at April 26 CA/B published TLS baseline requirement 1.8.4, which cleared up about handling onion addresses, and removed wired applicantnonce.
RFC-ish acme onion handling draft : GitHub - orangepizza/acme-onion-doc: docs about standardize handling onion address in acme context
client based on acme-tiny : GitHub - orangepizza/acme-tiny at onion
(shoud update readme.md there though), it use -tor-dir cmdline option to read onion config folder
server based on pebble GitHub - orangepizza/pebble at onion

for now I'd say this rfc draft is not LE specific, so some things LE won't do like http-01 and tls-alpn challenge are included in it

not set on concrete part on docs:
should we set how to craft onion challange CSR in it, or we should delegate its construction to CA/B BR?
do you think placeholder identifier type onion-v3 and onion-v3-csr challenge type? can we have better naming for it?
currently token is constructed in same way (as string) and just pasted in CAnonce attribute (which is octetstream byte array type) with ASCII encoding, should we order client to decode token as base64url and put it that way instead of being ASCII?
we can't use different name for old challenges : as allowed method itself is looking at that challenges
currently doc has warning about normal rate-limit won't work on it, but should we recommend some way for rate limit? (like onion addr/account or cert need non-onion name etc)

I probably ask this into more place/ like moz secpolicy and IETF acme task group

P.S. I'm writing this just before sleep :{


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Looks like a draft has been posted: Automated Certificate Management Environment (ACME) Extensions for ".onion" Domain Names


the author of draft made some reference implemetation pair (in rust) https://acmeforonions.org/

and a rust implementation for tor, which LE staff mentioned here that they don't want to bring memory-unsafe daemon to their CA side


Hi, I'm the author of that draft. Feel free to contact me at q@as207960.net with any questions.

There's also a plugin for certbot to support the onion-csr-01 method: certbot-onion.

Finally there's a fork of Tor to implement CAA on GitHub. This goes with the 343-rend-caa proposal to add CAA to mainline Tor.


@TheEnbyperor I noticed HARICA offers an ACME endpoint without EAB at https://acme.harica.gr/directory and as they're able to validate .onion addresses, do you know if they're also able to validate .onion addresses using their ACME API? For regular addresses it fails with a message that the hostname does not match a regex containing harica.gr and some IDN stuff, but that regex doesn't seem to check for .onion addresses.


I've never managed to get HARICA to issue certificates to .onion over ACME. I'd like to talk to them about my draft but can't get a contact there to talk.