Why a Valid Certificate Can Still Score F

The padlock is a narrow promise

A browser shows a padlock when three things hold: the certificate chains to a trusted root, it covers the hostname being visited, and it has not expired. That is it. Nothing about which protocol version is offered, which ciphers are accepted, or whether the server is vulnerable to downgrade attacks.

A TLS grade asks a different question: how well is this endpoint configured, not merely whether it can establish an encrypted connection at all.

Six failures that produce a low score

These are the causes we see most often across the twenty thousand sites we track, roughly in order of how much they cost.

• •Certificate expired or not yet valid — an automatic zero, regardless of everything else.
• •Hostname mismatch — the certificate is valid, but for a different name. Common after a domain migration or when a CDN serves a shared certificate without SNI.
• •Incomplete chain — the intermediate is missing, so some clients cannot build a path to the root. Browsers often paper over this; API clients and mobile stacks do not.
• •Legacy protocols still enabled — TLS 1.0 or 1.1 offered alongside modern versions drags the score down even if nobody uses them.
• •Weak ciphers or no forward secrecy — static RSA key exchange means a stolen private key decrypts recorded traffic.
• •Handshake failure — the server refuses the probe entirely, often due to strict SNI requirements or a firewall rule that blocks non-browser clients.

Diagnosing it in order

Start by separating certificate problems from configuration problems. If the certificate is expired or mismatched, nothing else matters until that is fixed. If the certificate is fine, look at the protocol list next: it is the single largest contributor to a low score after certificate validity.

The domain report on CertH shows which of the five scoring areas lost points, with the specific deduction and the fix. That is usually faster than reading a full scan by hand.

# What does the certificate actually cover?
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName -dates

# Which protocols does the server accept?
for v in tls1 tls1_1 tls1_2 tls1_3; do
  printf '%s: ' "$v"
  echo | openssl s_client -connect example.com:443 -$v -servername example.com 2>/dev/null | grep -q "Protocol" && echo yes || echo no
done

The SNI trap

A server hosting many domains needs SNI to pick the right certificate. Some setups require it and reject clients that omit it, which is fine for browsers but breaks monitoring tools, older Java clients and some API libraries. If a scanner reports a handshake failure while browsers work normally, this is the first thing to check.

FAQ