Certificate does not cover the hostname

CriticalConfirmedtls.certificate.hostname-mismatch

What this check looks for

The certificate is for a different name than the one visitors type. Browsers show a security warning and refuse to continue without an explicit override.

Why it matters

A name mismatch looks exactly like an interception attack, because that is what the check is for. Visitors are told your site may be impersonated, and API clients simply refuse to connect.

When the check passes, your report says: “The certificate covers the hostname visitors type”.

What it costs your score

When this check fails it removes 60 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: critical
Default confidence: confirmed
Status when triggered: fail
Deduction: 60 points
Family cap: tls.certificate · 60
Category: TLS
Module: Tls certificate
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Issue a certificate that lists every hostname the site is served on.

A name the certificate does not list is a name no browser will load without a warning.

List every hostname served by this site — apex, www, and any alias that resolves here.
Issue one certificate covering all of them as subjectAltName entries.
Remember the bare domain is not covered by *.example.com; it needs its own entry.
If the wrong certificate is simply being served, check the server block's server_name and the default virtual host.

How to confirm it worked

openssl s_client -connect ‹host›:443 -servername ‹host› </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

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

nginx

certbot --nginx -d ‹host› -d www.‹host› --cert-name ‹host›

Apache

certbot --apache -d ‹host› -d www.‹host› --cert-name ‹host›

Caddy

‹host›, www.‹host› {
	# Caddy requests a certificate covering every name in the site address.
	root * /srv/www
	file_server
}

Cloudflare

SSL/TLS → Edge Certificates → check the Universal SSL certificate lists this hostname. A hostname more than one label deep (a.b.example.com) needs Advanced Certificate Manager or a Total TLS setting.

Cloudflare's certificate covers visitor-to-edge only. If the origin is reachable directly — by IP address, or through a DNS record that is not proxied — its own certificate is unchanged and is what this scan measured. Fix the origin as well, and set SSL/TLS mode to Full (strict) so Cloudflare itself validates it.

Technical detail

‹host› does not match any subjectAltName on the presented certificate. Names found: ‹san list›. ‹reason›

RFC 6125 §6.4 defines the matching rules, and two of them catch people out: browsers have not consulted the Common Name since 2017, so a certificate whose CN matches but whose SAN does not is a mismatch; and a wildcard covers exactly one label, so *.example.com matches www.example.com but neither example.com nor a.b.example.com.