SSL/TLS Certificates for Tor Hidden Services

Tor's transport encryption already protects .onion connections end-to-end - HTTPS adds no security for the channel itself. The reasons to add HTTPS anyway: (1) Browser features: Service Workers, which enable offline functionality and performance improvements, require HTTPS in most browsers. Some browsers only support these features in 'secure contexts' - Firefox treats .onion as secure context regardless of HTTP/HTTPS, but Chrome does not. (2) Secure cookies: cookies with the Secure flag require HTTPS. Using secure cookies prevents accidental clearnet cookie transmission if the same domain appears on clearnet. (3) HTTP/2: standard HTTP/2 requires TLS. HTTP/2 improves performance via multiplexing. (4) HSTS: HTTP Strict Transport Security prevents protocol downgrade attacks. (5) Third-party scripts and libraries: some JavaScript libraries refuse to load on non-HTTPS origins. For most .onion services targeting Tor Browser (Firefox): plain HTTP is fully secure. For services that also want Chrome/Chromium compatibility or the features listed above: adding HTTPS is beneficial.

DigiCert is the only Certificate Authority (CA) that issues TLS certificates for .onion domains under the CA/Browser Forum's Tor-specific requirements. The CA/B Forum adopted Ballot 144 in 2015 allowing .onion certificates. Requirements: the applicant must prove control of the .onion address by signing a challenge with the hidden service's Ed25519 private key. This is the same key that generates the .onion address - possession of the private key proves control of the domain. Cost: DigiCert charges significant fees for .onion certificates (enterprise pricing, not available to the general public affordably). The certificate issuance process involves submitting proof-of-control documentation to DigiCert. Validity: .onion certificates from DigiCert are browser-trusted (no security warning in browsers). For organizations that need browser-trusted .onion HTTPS: DigiCert is the only option. For individuals and small services: the cost is prohibitive. Self-signed alternatives are more practical.

Self-signed TLS certificates can be generated for any domain including .onion addresses. Generate with openssl: openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes -subj '/CN=youronion.onion'. This creates a certificate valid for 1 year. Nginx configuration: ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; listen 443 ssl;. Client behavior with self-signed certificates: browsers show a security warning ('Your connection is not private'). Users must click through the warning. This is a usability barrier. Mitigation: instruct users to add the certificate fingerprint to their browser's trusted certificates, or add the self-signed CA to a browser extension. For internal tools and developer use cases: self-signed is acceptable. For public-facing .onion services: the certificate warning discourages users. Tor Browser displays a slightly different warning than standard browsers for .onion self-signed certs.

nginx HTTPS configuration for a .onion service: listen 443 ssl; with the ssl_certificate and ssl_certificate_key directives pointing to certificate and private key files. Add listen 80; with a redirect to HTTPS: return 301 https://$host$request_uri;. For HTTP Strict Transport Security (HSTS): add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains;'; in the HTTPS server block. SSL protocols and ciphers: ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256'; ssl_prefer_server_ciphers off;. This configuration enables TLS 1.2 and 1.3 with strong ciphers. OCSP stapling (ssl_stapling on;): not applicable for self-signed certificates (requires CA-issued cert). For DigiCert certificates: enable OCSP stapling but configure the OCSP responder URL to be reached via Tor to prevent the server from making clearnet requests.

Let's Encrypt does not issue certificates for .onion domains. Let's Encrypt's validation methods (HTTP-01 and DNS-01) cannot validate .onion addresses: HTTP-01 requires a public HTTP server accessible from Let's Encrypt's validation servers (which cannot reach .onion), and DNS-01 requires a public DNS zone (.onion is not in the DNS system). Let's Encrypt has explicitly stated it will not issue .onion certificates. ACME-based automation for .onion certificates is not possible via Let's Encrypt. The only CA/B Forum compliant option is DigiCert (at high cost). For practical purposes: use self-signed certificates (with browser warning) for .onion services unless the budget for DigiCert enterprise certificates is available. The security properties of a self-signed .onion certificate are as strong as a CA-signed certificate - the difference is only browser trust indication.