Notifications
Clear all
Topic starter
25/06/2026 10:38 pm
TL;DR: Publicly trusted TLS certificates can authenticate organisations on .onion sites, with EV-only issuance, wildcard support, and a 15-month validity cap under CA/B Forum guidance, according to DigiCert. The practical issue is not anonymity itself, but whether identity proofing and certificate lifecycle controls can keep pace with Tor-facing trust decisions.
NHIMG editorial — based on content published by DigiCert: Ordering a .Onion Certificate from DigiCert
Questions worth separating out
Q: How should teams govern TLS certificates for .onion services?
A: Treat .onion certificates as identity assets with ownership, validation, and renewal controls.
Q: Why do .onion sites still need certificate lifecycle management?
A: Because privacy and trust are different problems.
Q: What breaks when wildcard .onion certificates are used too broadly?
A: A single wildcard certificate can extend the same trust signal across many hostnames, so one issuance decision can affect more services than intended.
Practitioner guidance
- Map .onion certificates into your asset inventory Record each onion certificate, its business owner, issuing CA, expiry date, and the service or environment it protects.
- Separate EV proofing from routine certificate requests Route .onion certificate requests through an explicit validation step that confirms organisational identity, service purpose, and naming authority before issuance.
- Review wildcard use against service segmentation Allow wildcard .onion naming only where the certificate owner can explain why multiple hostnames must share one trust boundary.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- The exact ordering path for EV TLS and EV Multi-Domain TLS certificates for .onion services
- The CA/B Forum guidance DigiCert applies when validating onion names and wildcard use
- The built-in validity adjustment logic that sets onion certificates to a 15-month maximum
- The specific form fields and certificate selection choices involved in submitting an onion certificate request
👉 Read DigiCert's guidance on ordering TLS certificates for .onion addresses →
.onion certificates and Tor identity proofing: what changes for teams?
Explore further
25/06/2026 11:15 pm
.onion certificates turn Tor services into an identity governance problem, not just a privacy problem. The article makes clear that anonymity and identity proofing are separate control objectives. Once an organisation asks users to trust a Tor endpoint, the relevant question becomes who is authorised to bind that onion name to the organisation, and on what evidence. For IAM and PKI teams, this means service trust cannot be treated as outside the identity programme.
A few things that frame the scale:
- From our research: 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
- 59% of companies face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility.
A question worth separating out:
Q: Who is accountable when a .onion certificate is misissued or misused?
A: Accountability sits with the service owner, the certificate governance team, and the issuing authority under its policy rules. If the organisation cannot show who approved the identity proofing, who owns renewal, and who can revoke the certificate, the trust model is incomplete.
👉 Read our full editorial: Onion certificates show how identity proofs work on Tor sites
