How to fix the hostname mismatch advisory

The hostname_mismatch advisory fires when the hostname being monitored is not listed in the certificate's Common Name (CN) or Subject Alternative Name (SAN) extension. This is one of the most common advisories on first-time onboarding, often caused by a typo or a SAN list that was assembled before all the affected services were known.

What triggers the advisory

CertTracker pulls the leaf certificate during the TLS handshake, reads the SAN extension, and matches the monitored hostname against every entry using strict RFC 6125 matching:

Exact match — api.example.com matches api.example.com
Wildcard at the leftmost label only — *.example.com matches api.example.com but not example.com (the apex) and not deep.api.example.com (multi-level)

If no entry matches, the advisory fires. The legacy CN field is no longer considered by modern browsers; CertTracker still checks it as a courtesy, but for any cert issued in the last few years, what matters is the SAN list.

Why it matters

Browsers refuse to connect to a host whose certificate doesn't include that host in its SAN. The user sees NET::ERR_CERT_COMMON_NAME_INVALID (Chrome) or SSL_ERROR_BAD_CERT_DOMAIN (Firefox). It's not a warning, it's a connection failure.

The error is also worse than a simple expiration — users tend to assume "the cert is broken" rather than "the cert is fine but for the wrong site," which makes troubleshooting harder.

Common causes

Typo in the monitor hostname — you added api.example.cmo or similar. Fix it in the CertTracker monitor; no cert change needed.
New service launched without updating the cert — api.example.com was added but the cert still lists only example.com and www.example.com. Common when a new microservice is added and someone forgets to extend the cert request.
Wrong vhost cert being served — your web server has multiple SNI mappings; the default one is responding when SNI matching fails. Often the certificate served is for a totally different site (the load balancer's own management cert, for example).
Wildcard scope mismatch — your wildcard is *.example.com but you're monitoring example.com (the apex). Wildcards do not match the apex.

Triage decision

Step 1: Confirm whether the monitor hostname is correct.

# What's actually in the cert's SAN list?
echo | openssl s_client -connect your-host.example.com:443 -servername your-host.example.com 2>/dev/null   | openssl x509 -noout -ext subjectAltName

Compare the listed SANs against what you typed into the CertTracker monitor. If they don't match for a reason that makes sense (typo, intentional rename), fix the monitor:

CertTracker → Monitors → click the monitor → Edit → update the hostname → Save. Use the Re-scan button in the monitor detail modal's Active Advisories section to retest immediately; the advisory clears on the next successful poll.

If the monitor hostname is correct but the cert's SAN list is genuinely missing it, the fix is on the certificate, not the monitor.

Fix: extend the certificate's SAN list

This is a reissuance. The procedure is the same as any other cert reissue — request a new cert that includes every hostname you serve from this endpoint in its SAN list, then install the new cert.

Building the CSR with all the SANs you need:

With OpenSSL, use a -config file rather than the interactive prompt — the prompt cannot accept multiple SANs:

# csr.cnf
[req]
distinguished_name = req_distinguished_name
req_extensions     = v3_req
prompt             = no

[req_distinguished_name]
CN = api.example.com

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = api.example.com
DNS.2 = www.api.example.com
DNS.3 = api-eu.example.com
DNS.4 = api-us.example.com

Then:

openssl req -new -key server.key -out server.csr -config csr.cnf -sha256

# Verify the CSR has the SANs you expect before submitting it:
openssl req -in server.csr -noout -text | grep -A2 'Subject Alternative Name'

Submit the CSR to your CA. For Let's Encrypt with certbot:

sudo certbot certonly --webroot -w /var/www/html   -d api.example.com   -d www.api.example.com   -d api-eu.example.com   -d api-us.example.com

Every -d flag adds a hostname to the SAN list.

Fix: correct the vhost mapping

If the cert is fine but the wrong cert is being served, the issue is on your web server's SNI/vhost configuration. Three quick checks:

Apache: apachectl -S lists every configured vhost and which cert is bound. Look for the entry whose ServerName/ServerAlias matches the monitored hostname.

Nginx: nginx -T dumps the entire resolved config. Search for the server { ... server_name your-host; ... } block.

IIS: open IIS Manager → site → Bindings. Each binding lists hostname, port, certificate. Make sure the monitored hostname is bound to the correct cert.

If the right vhost exists but isn't being matched, the default cert is winning the negotiation — check that the client and server are both speaking SNI (some older clients aren't; the cert served on a non-SNI connection is whatever vhost is configured as the default).

Verify the fix

1. From a client that wasn't involved in the fix:

echo | openssl s_client -connect your-host.example.com:443 -servername your-host.example.com 2>/dev/null   | openssl x509 -noout -ext subjectAltName

Confirm the monitored hostname is listed.

2. Open the URL in a real browser in a private/incognito window. No security warnings means the SAN matches.

3. Re-scan in CertTracker. Trigger a re-scan from the CertTracker UI. The fastest path: open the monitor's detail modal (click the monitor row on the Monitors page), scroll to the Active Advisories section, and click the orange ⟳ Re-scan button on the right side of the section header. The status line below the header will confirm the cert re-poll and TLS audit are queued; the next 5-minute poller tick (within ~5 minutes) runs both, and the advisory clears if your fix took. See Where to find these buttons in the UI for visual landmarks.

Common pitfalls

Pinning to the leftmost wildcard label — *.example.com does not match example.com or deep.sub.example.com. Add explicit SANs if you need either.
Internationalized domain names (IDN) — punycode-encoded SANs must match the punycode form, not the unicode display form.
Port matters for matching — but only on the monitor side. Certificate SANs don't include ports.

Related advisories

Modern clients cannot connect — sometimes paired with this when the wrong vhost is also misconfigured for protocols.

Back to the TLS hardening hub.