Certificate uses an unusually broad wildcard
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.
Other tls certificate checks
- Certificate chain is missing an intermediate
- Certificate chain is not in the required order
- TLS certificate has expired
- TLS certificate expires in under 30 days
- TLS certificate expires in under 7 days
- Certificate does not cover the hostname
- Certificate has no Subject Alternative Name
- TLS certificate is not valid yet
- Certificate is self-signed
- Certificate could not be parsed
- Certificate does not chain to a trusted root
- Certificate is valid for longer than a public CA may issue