The fix, in one snippet
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -subject -issuer -datesIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
During the TLS handshake Scan.now validates the certificate chain the server sends against a current public root store, the same kind browsers use. It checks that a path can be built from the leaf certificate to a trusted root, that every intermediate in that path was actually sent by the server (a missing intermediate is the most common failure: it works in Chrome, which fetches intermediates on its own, but fails in Firefox, on Android and for curl), that the hostname appears in the Subject Alternative Name extension as RFC 9525 requires (the Common Name alone has not been accepted by Chrome since version 58), and that the current time falls between notBefore and notAfter. Self-signed certificates and private CAs fail because they are not in the public store. The result shows the issuer, the SAN list and the specific error. Expiry timing is examined in certificate-expiry; key size and signature algorithm have their own checks.
Why it matters
Encryption without authentication is worthless: a valid chain is the only thing that ties the encrypted channel to your domain rather than to whoever answered the connection. When validation fails, users see a full-page interstitial and, on a domain with HSTS, cannot click through at all. Sites that live with warnings train their users to bypass them, which is exactly the behaviour a man-in-the-middle attacker needs. A hostname mismatch usually means the certificate covers www.example.com but not the apex, or vice versa. An incomplete chain is especially treacherous because it passes on the developer's laptop where Chrome quietly repairs it, then breaks for API clients and mobile apps in production. The certificate errors guide explains each error message and its cause.
How to fix it
Serve the full chain: leaf plus intermediates, in that order, without the root. Certbot writes this as fullchain.pem. nginx:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;Apache 2.4.8 or later accepts the combined file in SSLCertificateFile; older versions need SSLCertificateChainFile for the intermediates:
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pemRequest the certificate for every name it must serve (-d example.com -d www.example.com). Verify what the server actually sends, and whether validation succeeds, from a machine that is not yours:
openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/nullLook for Verify return code: 0 (ok). With Cloudflare proxying, the edge presents a Cloudflare-managed certificate; set the origin up with a Cloudflare Origin CA certificate and use Full (strict) mode so the origin hop is validated too. Our SSL checker shows the chain the server sends and where it breaks.
Where this fits
Certificate chain and hostname validation is check 1 of 12 that the website vulnerability scanner runs under transport security (https / tls), ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
What fixing this still leaves open
Certificate chain and hostname validation closes one route in. Immediately below it: HTTPS is available, where the site could not be reached over HTTPS on port 443, or the TLS handshake failed; Certificate expiry, where the certificate has expired or will expire within 30 days; Deprecated TLS versions accepted (1.0 / 1.1), where the server still completes handshakes with TLS 1.0 or TLS 1.1.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Exposed .env configuration file, where a .env configuration file is served from the web root, and Exposed .git repository, where the site's .git directory is reachable over HTTP. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Certificate chain and hostname validation (critical severity)
Scanner check id: certificate-validThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
