Limit wildcard SSL certificate scope to reduce blast radius

What's happening

A wildcard SSL certificate (*.example.com authenticates every direct subdomain of example.com. The convenience is real — one certificate, one renewal, every service covered. The security tradeoff is that the private key for that wildcard, if stolen from any one server, lets an attacker impersonate every subdomain of the parent domain.

In a microservices architecture where a wildcard is deployed to dozens of hosts, the attack surface for that key becomes the union of all those hosts' attack surfaces. A compromise of an internal staging box leaks the production key. Better practice is a named certificate per service or per host — Let's Encrypt has made this nearly free with automation, so the historical reason for wildcards (cost) no longer applies.

The fix is to inventory where the wildcard key is deployed, replace it with named certificates wherever possible, and confine wildcard usage to ephemeral or dynamic-subdomain workloads where named certs are operationally impractical.

Why it matters

A single private-key compromise impersonates the entire parent domain. Phishing, MITM, and active downgrade attacks against any subdomain become trivial for the attacker.

Compliance frameworks (NIST 800-53, CIS Benchmarks, ISO 27001) discourage broad-scope wildcards on production systems and recommend per-service certificates.

Certificate Transparency logs publish every wildcard issuance; an attacker watching the logs can identify and target organizations relying on a single wildcard.

Common causes

• Pre-2019 era when commercial wildcards were the only affordable option for many subdomains.
• A single shared infrastructure team manages certificates centrally and a wildcard is the path of least resistance.
• Kubernetes ingress controller deployed with a wildcard secret instead of cert-manager-issued per-host certs.
• A frontend CDN edge fronts dozens of subdomains and uses one wildcard for SNI termination.
• The wildcard predates the move to ACME-based automation and nobody migrated.

Detect this on your site

Run a quick scan with the SSL Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Inventory wildcard usage

   Search Certificate Transparency logs for issued wildcards (crt.sh). Compare against the list of hosts where the wildcard private key lives — every box that holds the key is a single point of failure. Decide which subdomains are static and well-known versus dynamic and ephemeral.

2. 2

   Issue per-service certificates with certbot or cert-manager

   For each well-known subdomain, issue a named certificate. With certbot: sudo certbot certonly --nginx -d service.example.com. With cert-manager in Kubernetes, define a Certificate resource per Ingress or per Service.

3. 3

   Migrate services off the wildcard

   Update each service's listener to use the named certificate instead of the wildcard. Reload the relevant web server or proxy. Confirm the wire serves the named cert via openssl s_client -servername service.example.com -connect service.example.com:443.

4. 4

   Confine the wildcard to ephemeral subdomains

   Reserve the wildcard for use cases where named certs are impractical — per-tenant subdomains, per-PR preview domains, dynamic vanity URLs. Put the wildcard behind a single termination point (load balancer, edge proxy) so the private key lives in one place.

5. 5

   Add CAA records to limit issuance authority

   Set CAA records on example.com to allow only specific CAs and to limit who can issue wildcards. Example: example.com. CAA 0 issuewild "letsencrypt.org". This narrows the attacker's path even if they take over part of the issuance pipeline.

6. 6

   Rotate the wildcard key on a schedule

   After confining usage, rotate the wildcard private key at least quarterly. With ACME automation this is one command. Treat the wildcard as a secret with a short shelf life rather than a permanent fixture.

Example

; CAA records that constrain issuance scope
example.com.    IN  CAA  0 issue "letsencrypt.org"
example.com.    IN  CAA  0 issuewild "letsencrypt.org"
example.com.    IN  CAA  0 iodef "mailto:security@example.com"

CAA records limit which CAs may issue (and especially which may issue wildcards)

Related fixes