The Padlock on Onion Sites: What HTTPS Certificates Really Mean for .onion
A padlock in the address bar has long been shorthand for safety on the regular web. On Tor, that little icon tells a far more complicated story. Onion services encrypt and authenticate traffic by design, so what a certificate actually adds is genuinely contested.
What the padlock proves, and what it does not
On the clearnet, HTTPS delivers two guarantees: the connection is encrypted against interception, and the server you reached really controls the domain in your address bar. The padlock says nothing about who runs the site or whether its content is honest. A polished phishing page can carry a perfectly valid certificate. Tor Browser shows a dedicated onion icon instead of relying on the padlock, a deliberate signal that .onion addresses are a different category. The browser treats them as secure by default even when the site serves plain HTTP. That design choice has shaped the debate ever since.Why onion services argue they need no CA at all
The core of the argument is cryptographic. A version 3 onion address is not a name registered with an authority; it is the ed25519 public key of the service itself, encoded into 56 characters. Impersonating the address would require breaking the key, not tricking a registrar. The Tor Project states this plainly in its documentation: No certificate authority is required for this proof, because the name of the service is the actual public key used to authenticate the underlying connection. In other words, an onion address is self-authenticating in a way no DNS domain can be.Onion services do the same thing as HTTPS, so why would an onion site bother with a certificate? The answer has less to do with cryptography than with browser behavior and user expectations.
DigiCert and the Facebook precedent
The first real-world test came in late 2014, when Facebook launched facebookcorewwwi.onion and DigiCert issued a certificate covering the address. SecurityWeek reported at the time that it was, per researcher Runa Sandvik, the first legitimate SSL certificate ever issued for a .onion address, and that it removed the certificate warning in Tor Browser. That early certificate existed in a regulatory gray zone, because .onion was still treated as an internal server name. The situation stabilized in 2015 when RFC 7686 formally reserved .onion as a special-use top-level domain (RFC 7686). The CA/Browser Forum followed with ballot 144, which permitted certificates for onion names but demanded Extended Validation only. EV validation meant corporate paperwork, legal-entity vetting and a considerable price tag. As DigiCert documented in its own ordering guide, EV was for years the sole option, aimed at organizations rather than individuals running a service from a laptop.Ballot SC27 opens the door to DV and OV
Everything changed with v3 onion addresses, which replaced the weak RSA-1024 and SHA-1 foundations of older onions with modern elliptic-curve crypto. The old EV-only rule existed largely because those earlier addresses were cryptographically fragile. Once they were gone, the justification collapsed. In February 2020, the CA/Browser Forum passed ballot SC27v3, proposed by Wayne Thayer of Mozilla and endorsed by Let's Encrypt and HARICA, allowing Domain Validation and Organization Validation certificates for version 3 onions. The vote was unanimous: nine certificate issuers in favor, zero opposed, plus yes votes from Apple, Google, Microsoft and Mozilla (CA/Browser Forum). The separate Tor Service Descriptor Hash extension requirement was dropped, since the hash is now baked into the address itself.Who issues certificates today, and why operators still buy them
Adoption has been slower than the policy win suggested. The Tor Project welcomed the change but noted in 2021 that few CAs had acted on it; today its documentation lists DigiCert for EV certificates and the Greek consortium HARICA for affordable DV certificates as the main public options (Tor Community docs). Let's Encrypt, the free CA many hoped would step in, still does not issue onion certificates. So why pay at all? Operators cite a handful of practical reasons:- Browser features such as secure cookies and service workers expect HTTPS.
- Mixed HTTP and HTTPS infrastructure can leak secure cookies without TLS.
- A familiar padlock reassures mainstream users and helps fight phishing clones.
- Certificate Transparency logs give users an independent way to spot impostor onions.