Wildcard Prevalence

A wildcard certificate (*.yourdomain.tld) covers every subdomain at one level under the parent in a single cert. Operationally convenient: one renewal, one set of DNS validation records, one private key to manage. The trade is blast radius: compromise of that single private key allows impersonation of every subdomain it covers. Per-host certs limit the damage from a key leak to one host. This check measures the share of wildcards in your CT-logged certificates over the last 12 months.

How the check works

Per scan, RedScore queries Certificate Transparency for every cert issued for the domain over the last 12 months. For each cert, if any SAN starts with *., it counts as a wildcard. Wildcard percentage = wildcards / total. Score bands:

• Under 40%: 1.0 (pass). Per-host issuance dominates; wildcards used selectively.
• 40-45%: 0.9 (slight deduction). Reason: moderate_wildcard_usage.
• 45-75%: 0.75 (deduction). Reason: high_wildcard_usage.
• Over 75%: 0.58 (floor). Reason: excessive_wildcard_usage. Floor instead of zero because heavy wildcard usage is a rational pattern at SaaS or CDN scale; the check still penalizes it but does not wipe the entire weight.

Score is multiplied by a sample-confidence factor that scales down for small sample sizes (fewer than 5 certs). With fewer than 3 certs in the window, the check defers entirely (no score) because the percentage is unreliable.

How the verdict maps to evidence

• Pass: under 40% wildcard share, OR sample confidence pulls the score back to passing.
• Warn: 40-75% wildcard share.
• Fail (with floor): over 75% wildcard share. The floor at 0.58 stops the check from being score-killing for SaaS-scale operations.
• Deferred: fewer than 3 certs in 12 months. Sample too small to evaluate.

Evidence shows certificates_in_window, wildcard_count, wildcard_pct, the confidence_multiplier, and a sample of CT entries.

Special states

• Deferred: 0 or 1-2 certs in the window. The check returns no score with an evidence note explaining the sample size limit.

Fix: shift toward per-host certs where feasible

Per-host certs limit blast radius and are easy to manage at scale once you automate. The fix is automation, not manual issuance per host.

Migrate to per-host ACME

• Stand up an ACME pipeline (cert-manager on Kubernetes, certbot on traditional servers, Caddy or Traefik for built-in ACME). Each host gets its own cert, renewed automatically.
• For each existing wildcard, identify the subdomains it covers. Issue per-host certs at the next renewal cycle.
• Retire the wildcard once every covered host has its own cert.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-yourdomain-tld
  namespace: production
spec:
  secretName: api-yourdomain-tld-tls
  dnsNames:
    - api.yourdomain.tld
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

# One Certificate resource per hostname. cert-manager handles
# issuance, renewal, and rotation automatically.

Reduce wildcard reuse, not necessarily eliminate

If you cannot fully migrate to per-host (multi-tenant SaaS provisioning new subdomains daily, CDN serving infinite-cardinality hostnames), reduce the wildcard footprint instead:

• Scope wildcards narrowly. *.tenant.yourdomain.tld instead of *.yourdomain.tld limits the blast radius to one zone.
• Rotate wildcard private keys frequently. With ACME-issued wildcards on 90-day cycles, the key naturally rotates every renewal. Avoid long-lived wildcard keys.
• Do not share wildcard keys across regions or providers. Each environment gets its own wildcard issuance, not a copied private key.
• Pair with a CT-monitoring alert. If your wildcard key ever appears on certs you did not issue, you will see it in CT logs immediately.

When wildcards are appropriate

• Multi-tenant SaaS: customer.app.yourdomain.tld for unbounded customer count. Per-host issuance impractical at provisioning time; wildcards under app.yourdomain.tld are the operational reality.
• CDN: per-host certs at edge for arbitrary customer hostnames are infeasible; CDN-managed wildcards or SAN certs are standard.
• Internal infrastructure where every host shares a key already (single-purpose dev or staging environments).
• When ACME automation is genuinely not available for per-host issuance and the operational cost of manual per-host renewal would dwarf the marginal blast-radius benefit.

Verify the fix

• Search crt.sh for your domain (https://crt.sh/?q=yourdomain.tld) and count how many certs in the last 12 months have * in the name field.
• After per-host migration: when an old wildcard expires, do not renew it. Confirm new per-host certs cover everything the wildcard covered.
• Re-run the RedScore lookup. The percentage updates as new certs hit CT logs (typically within minutes of issuance).

Common pitfalls

• Migration breaks subdomains the wildcard was silently covering. Before retiring a wildcard, enumerate every subdomain that resolves under it (some may be using the wildcard for content not for cert issuance). Audit DNS, then issue per-host certs for each before pulling the wildcard.
• Wildcard reissued by an automated pipeline you forgot. Some IaC modules issue wildcards as a convenience default. Audit your Terraform / Pulumi / CDK templates for wildcard-by-default settings.
• Wildcard private key checked into version control. Easy to do; catastrophic if discovered. CT-log monitoring catches the issuance side; secret-scanning (GitGuardian, TruffleHog, GitHub secret scanning) catches the leak side. Pair both.
• Sample-size confidence pulls a real problem out of scoring. If you have only 2 certs in 12 months and one is a wildcard, the check defers, but you still have a high-blast-radius wildcard. Investigate independent of the score.
• CDN-managed wildcards counted in your CT history. Cloudflare, Fastly, and CloudFront issue wildcards under their own org but they appear in CT for your domain. Counted in your wildcard percentage.
• Per-host migration without backing infrastructure. Issuing per-host certs without a renewal pipeline means you trade blast-radius risk for expiry risk. Automate first, then migrate.