Certificate uses an unusually broad wildcard
Updated
2% of the 923 domains we could check get a warning for this. Sample: the first 1,000 domains by rank in the Majestic Million, checked on 2026-10-12. How we measured
What this check looks for
The certificate covers a very wide range of names. If its private key ever leaks, the damage extends far beyond this one site.
Why it matters
A wildcard's blast radius is every name it covers. One compromised server means every host under that wildcard can be impersonated, and re-issuing means touching all of them at once.
When the check passes, your report says: “Any wildcard in the certificate is narrow in scope”.
What it costs your score
When this check fails it removes 4 points from your TLS score, before the status, confidence and repeat multipliers are applied. TLS carries a weight of 15 in the overall score.
It shares the tls.certificate family ceiling of 60 points: however many findings that family produces, together they cannot remove more than that from TLS. One underlying problem showing up in several places is still one problem.
- Severity
- low
- Default confidence
- high
- Status when triggered
- warn
- Deduction
- 4 points
- Family cap
- tls.certificate · 60
- Category
- TLS
- Module
- Tls certificate
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Narrow the certificate to the hostnames this server actually serves.
A leaked key for a broad wildcard compromises every name under it at once.
List the hostnames served by this host and issue a certificate naming them.
Keep a wildcard only where names are genuinely created dynamically.
How to confirm it worked
openssl s_client -connect ‹host›:443 -servername ‹host› </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Remediation by platform
certbot --nginx -d ‹host› --cert-name ‹host›Technical detail
The certificate for ‹host› presents ‹wildcard›, which sits at or above the registrable-domain boundary. RFC 6125 §6.4.3 permits a wildcard only in the leftmost label and warns about exactly this scope problem. Prefer a certificate per hostname — ACME makes issuing many of them free and automatic, which removes the operational reason wildcards existed.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.