dotvitals

Certificate has no Subject Alternative Name

MediumConfirmedQuick wintls.certificate.no-san

What this check looks for

The certificate lists its hostname only in the old Common Name field, which browsers stopped reading in 2017.

Why it matters

Every modern browser treats a certificate with no Subject Alternative Name as covering no hostname at all, so the site fails with a name-mismatch warning even though the Common Name looks correct.

When the check passes, your report says: “The certificate lists its hostnames in the Subject Alternative Name”.

What it costs your score

When this check fails it removes 10 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
medium
Default confidence
confirmed
Status when triggered
warn
Deduction
10 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

Re-issue with every hostname listed as a subjectAltName.

Browsers do not read the Common Name, so a certificate without SANs covers nothing.

  1. Re-issue listing each hostname with -d (certbot) or a subjectAltName section in the CSR.

  2. Include the Common Name value as a SAN as well; it is not implied.

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

nginx
certbot --nginx -d ‹host› -d www.‹host›
Apache
certbot --apache -d ‹host› -d www.‹host›
Technical detail

No subjectAltName extension was found on the certificate for ‹host›. RFC 6125 §6.4.4 made the Common Name a deprecated fallback; Chrome 58 removed the fallback entirely in 2017 and other browsers followed. RFC 5280 §4.2.1.6 has required the extension for server certificates for far longer than that. A certificate in this state almost always came from an internal CA or an appliance's self-service form.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the tls certificate checkerBuild the fix

Other tls certificate checks