Summary

  • A v3 .onion name is derived from an Ed25519 service identity key, not from DNS delegation; reachability and an authenticated ACME account are therefore incomplete control evidence.
  • RFC 9799 adds onion-csr-01: a fresh, two-nonce validation CSR signed by the Onion identity key and deliberately distinct from the final certificate CSR.
  • CAA can live inside an encrypted service descriptor or arrive as an expiring Onion-key-signed record set, while Tor routing, redirects and Certificate Transparency create separate privacy decisions.

The response that proves too little

A successful connection is persuasive because it is visible. The CA reached a service, received the expected token, and can attach a time to the observation. In ordinary ACME, that kind of result fits a DNS-shaped world: a name resolves, a challenge is provisioned at the endpoint, and an account key binds the response to an order.

An Onion name has a different root of authority. RFC 7686 removes .onion from ordinary DNS resolution, and the Tor v3 address format embeds the service's Ed25519 public identity key, checksum and version. The string looks like a domain name and RFC 9799 reuses ACME's dns identifier for compatibility, but there is no registrar delegation behind it. A web process can respond without furnishing the private key from which the name was derived. An ACME account can sign protocol requests without being that key. A final CSR can carry the key that should appear in a certificate without proving control of the Onion identity.

RFC 9799 keeps those claims apart. It forbids dns-01, since there is no DNS TXT authority to query. It permits http-01 and tls-alpn-01 with Onion-specific connection handling, while the CA/Browser Forum Baseline Requirements require the CA to make its own Tor connection rather than outsource the observation to Tor2Web. Those reachability methods remain unavailable for wildcard issuance.

For a proof tied to the identity itself, the RFC defines onion-csr-01. The CA sends a nonce with at least 64 bits of entropy. A response using a nonce generated more than 30 days earlier must be rejected. The applicant creates a special PKCS#10 request, puts the raw CA nonce in caSigningNonce, adds a separate raw applicant nonce with at least 64 bits of entropy, and signs the request with the Onion service private key.

The CA does not treat this as the certificate request. It checks that the request is well formed; that its public key corresponds to the Onion name; that the signature validates under that key; that the CA nonce matches; and that the applicant nonce is present and sufficiently unpredictable. The subject has no authority and must not be validated. Most importantly, the public key in this validation CSR must not be the key in the final CSR.

That separation protects two lifecycles. The stable Onion identity key answers the narrow control challenge. The certificate key can rotate on its own schedule. The ACME account key authenticates the channel carrying the proof. None of the three can be substituted silently for another. onion-csr-01 also omits the ordinary ACME key-authorization string: the validation object is sent through an ACME request already signed by the account key, so another layer of account binding is unnecessary.

Visibility is a grant, not a side effect of reachability

Control proof is only one gate. Some Onion Services use restricted discovery, encrypting the descriptor so that only authorized clients can recover its inner contents. A CA might reach an application path and still lack the credential needed to read introduction information or CAA policy.

RFC 9799 lets a challenge advertise authKey, the Ed25519 public key the CA will use for descriptor access. A CA must not reuse one such key across different Onion Services, though it may reuse the key when revalidating the same service. This is a privacy boundary: a service-specific access identity prevents the credential itself from becoming a built-in cross-service correlator.

The server computes its Tor CLIENT-ID and looks for a matching auth-client entry. There is no separate declaration that restricted discovery is enabled. If the entry is absent, the server proceeds on the assumption that client authentication is not required. If the CA key is new, the operator must add it, re-sign and republish the descriptor. Propagation through Onion service directories is deliberately treated as indeterminate. The RFC expects minutes, not an exact service level, and recommends that the CA allow at least 30 minutes before expiring the challenge.

The authorization response becomes a synchronization signal: it tells the CA that the operator has had the opportunity to publish the access key. Only then does a CA checking a restricted service attempt to read CAA. A log saying “challenge acknowledged” is therefore not enough. Operational evidence must connect the advertised CA key, the descriptor revision, the propagation observation, the computed client identifier and the decrypted policy.

CAA moves, but its authority does not become DNS

CAA answers a different question from control: which issuer, and under which method constraints, may issue? RFC 9799 carries the familiar flags tag value form into the second encrypted layer of the Onion service descriptor. The semantics come from RFC 8659, but the lookup does not. There is no DNS tree to climb and no .onion TLD record to consult. Every subdomain below the same base Onion address shares that base service's CAA set.

Encryption creates a problem for unknown CAs. A restricted service may have a policy that an untrusted CA cannot read. The first descriptor layer can therefore contain caa-critical. It reveals that a CAA policy exists without revealing the policy itself, and it tells the issuer to stop until it can decrypt and parse the second-layer records. This is a useful fail-closed signal, not proof that the CA actually obtained or honored the records.

The alternative is in-band Onion CAA. At finalization, the client may send an onionCAA object for each Onion name. It carries the record set or null, a Unix expiry that should be no more than eight hours ahead, and an Ed25519 signature under the Onion identity key. The signed bytes are exact: onion-caa|, the decimal expiry with no leading zeros, a separator, and the CAA text; null becomes an empty string.

A valid signature makes the record set attributable and fresh enough to evaluate. It does not dictate the CA's source choice. The CA may rely on the in-band set, ignore it and fetch the descriptor, or fetch the descriptor in any case. A server unable to fetch descriptor CAA returns onionCAARequired if the client omits the object; its directory can advertise inBandOnionCAARequired in advance. Audit evidence should therefore state which path the server chose, which bytes and expiry it verified, and which policy controlled issuance.

The descriptor route and the in-band route share a cryptographic root. Tor directories are untrusted, so descriptor material is not authoritative merely because a directory served it. Both forms are verified against the Onion identity key. Transport changes; the authority key does not.

A certificate can be correct while the privacy decision is wrong

The final certificate outcome says even less about privacy. A CA must connect to the Onion Service over Tor itself. The client should also use Tor for its ACME session and prefer a CA's Onion endpoint when one exists. A direct connection to a well-known CA address can reveal that the requesting host operates an Onion Service.

http-01 redirects add another branch. A redirect to the public DNS can expose an IP address or an infrastructure relationship the Onion design would otherwise conceal. The CA must not send that public-DNS validation through a Tor exit, because exit hijacking becomes a different validation risk.

Then comes the irreversible disclosure: a publicly trusted WebPKI certificate places the Onion name in Certificate Transparency. Some services may still value browser-recognized public trust; others may be better served by private or self-signed credentials. The RFC does not make that decision for the operator. It asks clients to warn about the consequence, recommends minimizing subscriber information, and requires separate ACME account keys when the operator wants to prevent a CA from correlating different Onion Services.

The disciplined record is therefore not “certificate issued.” It is a chain: the identity key behind the name; the account-authenticated order; a fresh, nonce-bound identity proof; the service-specific descriptor-access grant and observed propagation; the CAA source the CA actually used; the distinct final key; and the exposures accepted on the way. RFC 9799 supplies a common protocol for each transition. It does not permit the last artifact to erase the decisions that preceded it.

Sources