.onion HTTPS: When to Use TLS on Tor Hidden Services in 2026

The short answer: Tor's onion service protocol provides end-to-end encryption and authentication between the client and server. This encryption is stronger than typical HTTPS in one key respect: the .onion address IS the server's public key. There is no need for a third-party Certificate Authority to authenticate the server - the address itself proves cryptographic ownership. However, HTTPS on .onion adds value in specific scenarios: mixed infrastructure (if the same application serves both .onion and clearnet, HTTPS unifies the security model), end-to-end encryption through any reverse proxies (if internal proxies decrypt Tor traffic before reaching the application), and user trust signals (browser padlock - though Tor Browser shows .onion sites as secure by default even without HTTPS). For a pure .onion service (no clearnet counterpart, no intermediate proxies): HTTPS is technically redundant but not harmful.

Let's Encrypt supports issuing DV (Domain Validation) certificates for .onion domains. The ACME challenge for .onion requires the ACME client to prove control of the .onion address. HTTP-01 challenge: the ACME server connects to the .onion address via Tor and verifies the challenge file. This requires the ACME client to be able to respond to HTTPS requests on port 80 from the Let's Encrypt ACME server via Tor. The Let's Encrypt boulder (ACME server) supports Tor connections for .onion validation. Certbot with .onion: use certbot with --agree-tos and the webroot or standalone authenticator pointed at your .onion address. The Let's Encrypt CA issues a 90-day certificate. Configuration: add the certificate path to Nginx's ssl_certificate and ssl_certificate_key. Renewal: certbot renew works for .onion certificates via the same Tor-connected ACME challenge.

Self-signed certificates for .onion: easy to generate (openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365), no CA dependency. Browsers show a certificate warning for self-signed certs. For known-user communities (where all users know to accept the warning), self-signed is acceptable. For public-facing services: browser warnings reduce user trust and may confuse non-technical users. CA-issued certificates (Let's Encrypt): no browser warning, users see the padlock icon. Requires the .onion address to be fixed and publicly registered (Let's Encrypt logs certificates in Certificate Transparency, which publicizes the .onion address). Consider whether CT log exposure is acceptable for your privacy model before using CA-issued certificates.

If using HTTPS for a .onion service: server block with listen 127.0.0.1:443 ssl, ssl_certificate /path/to/fullchain.pem, ssl_certificate_key /path/to/privkey.pem. Modern TLS configuration: ssl_protocols TLSv1.2 TLSv1.3 (disable TLSv1.0 and TLSv1.1), ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...' (use Mozilla's recommended cipher list), ssl_prefer_server_ciphers off (allows client to negotiate preferred cipher), ssl_session_cache shared:SSL:10m, ssl_session_timeout 10m. HSTS header: Strict-Transport-Security: max-age=63072000; includeSubDomains (ensures browsers only connect via HTTPS). Torrc: HiddenServicePort 443 127.0.0.1:443 (expose port 443 as the .onion service port).

Certificate Transparency (CT) logs are public databases of all certificates issued by trusted CAs. Let's Encrypt logs all issued certificates to CT logs. If you get a Let's Encrypt certificate for youraddress.onion, that address appears in public CT logs (searchable at crt.sh). For privacy-sensitive hidden services where the .onion address is not publicly advertised, CT log exposure may be undesirable. Options: use self-signed certificates (not logged to CT), use a private CA (internal CA not submitted to CT logs, certificates not valid in browsers by default), or accept CT exposure (your .onion address being in CT is not necessarily more discoverable than via .onion search engines). For most legitimate hidden services, CT log exposure is not a significant concern - the address is discoverable via other means.