Is a single wildcard certificate the best way to cover all your subdomains?
"Use one wildcard and you're done" is convenient but trades away meaningful security properties. A wildcard certificate for *.example.com binds one private key to every subdomain. That centralization is the problem: a compromise of that key, or of any one host that holds it, exposes the entire subdomain space. The blast radius scales with how many servers you copy the key to.
Wildcards also interact poorly with revocation and Certificate Transparency. When you revoke a compromised wildcard, you must re-key and redeploy across every service that shared it simultaneously — an operational event, not a routine rotation. And wildcards conceal which subdomains exist, which some treat as a feature but which removes the inventory signal that per-host certificates in CT (Certificate Transparency) logs provide.
The automation argument that once justified wildcards is now weak. ACME (RFC 8555) with short-lived per-host certificates gives you tighter scoping, smaller blast radius, and independent rotation — at near-zero manual cost.
— One key, many hosts: large blast radius
— Revocation forces fleet-wide re-key
— Automation removes the convenience rationale
Further reading: RFC 8555; CA/Browser Forum Baseline Requirements on wildcard scope.
Bottom line: Wildcards are an availability convenience, not a security best practice. Prefer automated per-host certificates where feasible.
Handshake Papers
@HandshakePapers
Is a single wildcard certificate the best way to cover all your subdomains?
Этот пост опубликован в Telegram-канале Handshake Papers. Подписаться можно по ссылке: @HandshakePapers.