A TLS scan report is a compressed view of two things: a TLS handshake against your endpoint, and an inspection of the certificate chain it presents. The letter grade is convenient, but if you own the server you want the layer underneath it - what each check actually tests, why it is graded the way it is, and how to reproduce and fix it locally. This walks every check in the report.
How the grade is computed
The grade (A+ to F) is not an average. It is a weighted roll-up with hard caps: most checks contribute points, but a single critical failure caps the maximum grade regardless of everything else. This is the same model SSL Labs popularised - an expired certificate or a negotiable TLS 1.0 is disqualifying, so a server that is perfect everywhere else still lands at F. Practically: read the severity of the worst issue, not the letter. Issues are tagged critical, high, warning, or info, and you should clear them in that order.
Certificate validity and expiry
The report parses notBefore and notAfter and reports remaining lifetime. A not-yet-valid certificate (clock skew on issuance, or a misconfigured staging cert promoted to prod) fails the same way an expired one does. Reproduce locally:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -datesExpiry is the loud failure mode and the easiest to monitor, which is exactly why teams over-index on it and miss everything below.
Hostname match (CN / SAN)
The report checks the requested hostname against the certificate's Subject Alternative Names (the CN is legacy and ignored by modern clients). Common failures: a SAN list that dropped an entry on renewal, an apex cert that omits www, or a wildcard *.example.com being used one label too deep (a.b.example.com is not covered). Inspect the SANs:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -ext subjectAltNameChain completeness and trusted issuer
This is the check that produces "works on desktop, fails on mobile" tickets. If the server sends the leaf but omits an intermediate, some clients reconstruct it via the AIA caIssuers URL and some do not - desktop browsers are forgiving, many mobile and API clients are not. The report flags a chain that does not terminate in a trusted root. Verify the chain the server actually sends (note -showcerts and the verify return code):
echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
| grep -E "s:|i:|Verify return code"The fix is almost always to install the full fullchain.pem (leaf + intermediates) rather than just the leaf. More on the misconfigurations behind this.
Trust stores: validated against all six, not just one
"Trusted" is not a single boolean - it is per-store, and the stores disagree. The full report validates the received chain against every bundled root store independently and lists them side by side: Apple, Android, Windows, Mozilla, Java (Oracle), and Java (OpenJDK). A chain can pass Mozilla and fail an older Android store over a missing cross-sign - exactly the "works for me, broken for some users" class of bug.
The method matters, because it changes what the output can be trusted to mean. Rather than reading SSLyze's enum-locked path_validation_results (which only ever exposed a single Java store), the scanner enumerates SSLyze's on-disk pem_files directory and validates the received chain against each store via the public TrustStore.verify_certificate_chain. Two consequences: every store SSLyze bundles is checked (currently six, including both Oracle and OpenJDK Java), and any store a future SSLyze release adds appears automatically with no code change. Stores are built once per process and cached.
Certificate fields and deployment signals
Beyond validity and hostname, the full report surfaces the leaf certificate's own declarations alongside deployment-level signals (the latter computed by SSLyze):
- Key Usage / Extended Key Usage. What the certificate is permitted to do. EKU renders as friendly names with an OID fallback (for example
serverAuth,clientAuth), read through the public cryptography extension API so it does not depend on a particular SSLyze version. A leaf missingserverAuth, or carrying a surprising EKU, is worth a second look. - Basic Constraints. Whether the certificate is a CA or an end-entity. A leaf asserting
CA:TRUEis a red flag. - Signature algorithm and public key size. The algorithm that signed the cert and the key strength (for example
2048-bit RSA,P-256 ECDSA). Undersized keys and weak signature algorithms grade down. - SHA-1 in chain. Any SHA-1 signature anywhere in the chain is a hard fail - deprecated for issuance for years, and rejected by modern clients.
- Legacy (distrusted) Symantec anchor. Chains rooted in the distrusted Symantec hierarchy are flagged; browsers removed trust for these.
- Chain received in valid order. Whether the server sent the chain leaf-first in the correct order. Out-of-order chains pass lenient clients and break strict ones.
- OCSP stapling. Whether the server staples a revocation response and whether that staple is trusted - reported as enabled, untrusted, or absent.
- Must-Staple and EV. Whether the certificate carries the must-staple flag, and whether it is Extended Validation.
- SCT count. The number of embedded Signed Certificate Timestamps - evidence the certificate was logged to Certificate Transparency, which clients like Chrome require.
Protocol versions
The report enumerates which TLS versions the endpoint will negotiate. TLS 1.0 and 1.1 are deprecated (RFC 8996) and graded as serious weaknesses; 1.2 is the floor, 1.3 is preferred. SSLv3 negotiating at all is critical. Anything still offering 1.0/1.1 is usually a load balancer or origin server with a stale security policy. Probe a specific version:
openssl s_client -connect example.com:443 -tls1_1 2>/dev/null | grep -E "Protocol|Cipher"Cipher strength
Beyond protocol version, the report looks at the negotiated cipher suites: presence of forward secrecy (ECDHE), and absence of known-weak primitives - RC4, 3DES (SWEET32), export-grade suites, anything with NULL or anonymous key exchange. A valid certificate over a weak cipher still grades down, because the certificate is not the thing being attacked - the transport is. Enumerate what the server accepts:
nmap --script ssl-enum-ciphers -p 443 example.comKnown vulnerabilities
The report tests for named protocol- and implementation-level flaws - Heartbleed (CVE-2014-0160), POODLE, ROBOT, BEAST, and relatives. Most are a function of the protocol/cipher findings above (POODLE follows SSLv3; SWEET32 follows 3DES), but some, like Heartbleed, are an OpenSSL version issue independent of configuration. A breakdown of these vulnerabilities and what each requires to fix.
What the free report does not cover
The free scan is a point-in-time check of the handshake and chain. It does not track revocation state (OCSP/CRL) over time, it does not watch Certificate Transparency logs for misissuance against your domains, and - by design - it is one snapshot, not a trend. Those are continuous-monitoring concerns: the value of a single scan decays the moment a config or certificate changes.
From a scan to a signal
Everything above reproduces what the report computed, which is useful for fixing the current state. The harder problem is the next state. A green report is true until an intermediate rotates, a renewal installs to the wrong path, or a CA distrust reshuffles your chain. Re-scan to confirm a fix, then put the endpoint under monitoring that re-runs these checks on a schedule and alerts on regressions - external validation that does not trust your own deploy pipeline.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.
Keep reading
What Is SSL/TLS Certificate Monitoring and Why Does It Matter?
Valid SSL Certificate, but Chrome Says 'Not Secure'? Here's Why
I don't want to learn what PKI, CA, ACME, EKU stand for, I only want a working certificate for my website
Related guides
-
SSL/TLS Scan Report Fields Explained
A field-by-field reference for reading an SSL/TLS scan report - what each value means, how to read it, and how it affects your website's security.
-
Common SSL Configuration Errors and How to Fix Them
The SSL configuration mistakes that bite teams in production, in plain English.
-
SSL/TLS Vulnerabilities - A Quick Guide for Non-Experts
A non-expert tour of well-known SSL/TLS vulnerabilities and how to check yours.
-
What Is SSL/TLS Certificate Monitoring? A Complete Guide
A plain-English definition of SSL/TLS certificate monitoring, what it catches beyond expiry, and why shorter certificate lifespans are making it essential.