highSeverity: highRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical −40, high −20, medium −10, low −4, info −1. Higher severity means fix it sooner.TLS certificateWhere it livesImplementationThis fix is applied in: TLS certificate. That's the surface you'll edit, DNS, response headers, or a static file.~15 minTime to fixEffortRoughly 15 minutes of hands-on work, propagation aside. Most of these are copy-paste.+20 posture+20 postureScore impactPoints this fix recovers in the ApeCyber posture score (0–100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

TLS hostname mismatch: one certificate that covers your apex and your www

Reissuing the certificate so its SAN lists every hostname you serve restores the secure connection

The threat

The certificate your site presents is valid, trusted, and unexpired, all good so far, but the name on it does not match the address in the browser’s bar. A certificate lists the exact hostnames it is valid for in its Subject Alternative Name (SAN) field, and the scanner found that the hostname it connected to is not in that list. Browsers treat this as a trust failure (SSL_ERROR_BAD_CERT_DOMAIN), because they can no longer be sure they are talking to the right server rather than an impostor.

By far the most common cause is a certificate that covers www.yourdomain.com being served on the bare apex yourdomain.com, or the reverse. Both addresses reach your site, but the certificate names only one of them, so a share of your visitors hit a warning depending on which URL they typed. The fix is a single certificate whose SAN lists every hostname you actually answer on.

The exact fix

Self-managed with certbot. Reissue the certificate with a -d flag for each hostname you serve, apex and www together (add any other live subdomains too):

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

The first -d becomes the primary name and the rest are added to the SAN, so one certificate now validly covers both. Reload the server if certbot did not, and keep auto-renewal on so the combined certificate renews as a unit.

Managed host. On Netlify, Vercel, or Cloudflare Pages, add both the apex and the www hostname to the site in the dashboard before the certificate is issued; the platform then provisions a managed certificate whose SAN covers both. If only one was added, add the missing one and let the certificate reissue.

Then pick a canonical host. A mismatch is often a sign that apex and www are served side by side. Once the certificate covers both, 301-redirect one to the other (choose www or apex and stick with it) so visitors and search engines settle on a single address.

Tip: a wildcard certificate (*.yourdomain.com) covers www and other single-level subdomains but does not cover the bare apex yourdomain.com, and it does not cover deeper names like a.b.yourdomain.com. If you use a wildcard, list the apex explicitly as well.

Verify it

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

The printed DNS: entries must include the exact host you visit, both yourdomain.com and www.yourdomain.com. If the host you use is missing from that list, the certificate does not yet cover it.

Proof

apecyber.com serves a managed certificate whose names cover the host it answers on, so the mismatch this check looks for never appears there. The ApeCyber scanner compares the certificate’s SAN list against the hostname it connected to, passively, on every scan, from the outside and touching nothing, exactly the comparison a browser makes before it shows the padlock.