SSL/TLS Scan Report Fields Explained

A TLS Radar scan report describes the certificate a server presents and how well it is deployed. Every field falls into one of a few groups: the overall grade, the certificate's identity, its trust and validation status, the per-platform trust stores, supported protocols, accepted cipher suites, and a prioritised list of issues. This page explains each field - what it means, how to read its value, and how it affects your website's security.

The grade

Grade (A+ to F). A single roll-up of every check below. It is not an average: one critical failure (an expired certificate, a broken chain, a negotiable SSLv3) caps the grade no matter how good everything else is. How to read it: A+ "best-in-class", A "strong", B "minor improvements", C "fair - several issues", D "poor - significant weaknesses", F "critical issues". Security impact: the grade is a summary, not a diagnosis - always read the issues list to see why you scored what you did.

Certificate

These fields describe the certificate's own identity and cryptography.

Issuer. The Certificate Authority that signed the certificate (for example Let's Encrypt, DigiCert, Sectigo). How to read it: it should be a CA you or your provider chose. An unfamiliar issuer can mean a misconfiguration, a corporate proxy intercepting traffic, or an internal CA used where a public one was expected.

Valid from / Valid until. The start and end of the certificate's validity window. How to read it: "valid from" in the future means the certificate is not yet usable (often a clock-skew problem); "valid until" is the expiry date. Security impact: outside this window, browsers reject the certificate outright and show a full-page warning.

Days remaining. How long until expiry. How to read it: anything under ~30 days deserves attention; negative means already expired. Security impact: expiry is the single most common cause of certificate outages.

Public key. The key type and size, for example RSA 2048-bit or EC P-256. How to read it: RSA should be 2048-bit or larger; elliptic-curve keys like P-256 are strong at smaller sizes. Security impact: undersized keys (RSA 1024 and below) are considered weak and grade down.

Signature. The algorithm the CA used to sign the certificate, for example sha256WithRSAEncryption or ecdsa-with-SHA256. How to read it: anything based on SHA-256 or stronger is fine. Security impact: SHA-1-based signatures are broken and rejected by modern browsers (see "SHA-1 in chain" below).

Key Usage. What the key is permitted to do, for example digitalSignature, keyEncipherment. How to read it: a normal TLS leaf certificate carries the usages its key exchange needs. Security impact: a certificate used outside its declared usage is rejected by strict clients.

Extended Key Usage (EKU). The specific purposes the certificate is valid for, shown as friendly names with an OID fallback - most importantly serverAuth (TLS server), sometimes clientAuth. How to read it: a web server certificate must include serverAuth. Security impact: a leaf missing serverAuth, or carrying an unexpected EKU, will be distrusted for web use.

Basic Constraints. Whether the certificate is a CA or an end-entity (leaf). How to read it: a server certificate should say it is not a CA. Security impact: a leaf asserting CA:TRUE is a serious red flag and a misissuance signal.

Trust & Validation

These signals describe how the certificate behaves when a real client tries to validate it.

Trusted by major stores. A summary verdict - does the chain validate against the common root stores. How to read it: "trusted" is the goal; "not trusted" means at least one major platform rejects it. See the per-store breakdown below for which ones.

Hostname match. Whether the address you scanned is covered by the certificate's Subject Alternative Names. How to read it: "matches" is required. A mismatch means the certificate is real but does not cover this exact name (for example it covers example.com but not www.example.com). Security impact: a mismatch is treated as untrusted - browsers warn.

Certificate valid / expired. A direct expiry check. Security impact: an expired certificate breaks the site for every visitor.

Chain order. Whether the server sent the certificate chain leaf-first in the correct order. How to read it: "valid order" is correct; "sent out of order" works in lenient clients but breaks strict ones. Security impact: a common cause of "works in my browser, fails for some clients".

SHA-1 in chain. Flags any SHA-1 signature anywhere in the chain. How to read it: you want this absent. Security impact: SHA-1 is cryptographically broken and deprecated for issuance; modern clients reject chains that contain it. Treat it as a hard fail - reissue from a current CA.

Distrusted Symantec anchor. Flags chains that root in the old Symantec hierarchy that browsers removed trust for. Security impact: these certificates are no longer trusted by major browsers; replace them.

OCSP stapling. Whether the server attaches a fresh revocation status to the handshake. How to read it: "enabled" is ideal; "not trusted" means the staple failed validation; "none" simply means the optimisation is off. Security impact: stapling speeds up connections and improves privacy; its absence is not a failure, but enabling it is best practice.

EV. Marks an Extended Validation certificate - the most heavily vetted type. How to read it: a badge, not a requirement. Most sites run perfectly well on standard (DV) certificates.

Must-Staple. Marks a certificate that requires OCSP stapling to be honoured. Security impact: if a must-staple certificate is served without a valid staple, clients reject it - so this flag and the OCSP stapling status need to agree.

SCT count. The number of embedded Signed Certificate Timestamps - proof the certificate was logged to public Certificate Transparency logs. How to read it: modern browsers (notably Chrome) expect at least two. Security impact: too few SCTs and Chrome will distrust the certificate.

Trust Stores

"Trusted" is not one yes-or-no answer - each platform keeps its own list of root authorities, and they do not always agree. The report validates your chain against every bundled store and shows a tick or a cross for each.

• Apple - Safari and apps on macOS and iOS.
• Android - the Android system store (older devices lag behind newer roots).
• Windows - Edge and most Windows applications.
• Mozilla - Firefox, and many command-line tools and Linux distributions that use Mozilla's bundle.
• Java (Oracle) and Java (OpenJDK) - server-to-server and enterprise Java clients.

How to read it: the header shows how many stores trust you (for example "5/6 trusted"). All green is the goal. Security impact: if most stores pass and one fails, that single failure is your "some customers cannot reach us" problem - often older Android or Java clients missing a newer root - and it is invisible if you only test in your own browser.

Protocol Support

The TLS (and historical SSL) versions the server will negotiate. How to read it:

• TLS 1.3 - the current best. Support it.
• TLS 1.2 - the secure minimum. Fine to support.
• TLS 1.1 / TLS 1.0 - deprecated. Security impact: still offering them is a graded weakness and a compliance problem (for example PCI DSS).
• SSLv3 / SSLv2 - broken. Security impact: offering either is critical; disable immediately.

Accepted Cipher Suites

The combinations of key exchange, encryption, and integrity the server will use, listed per protocol version. How to read it: look for forward secrecy (suites with ECDHE) and modern authenticated encryption (AES-GCM, ChaCha20). Security impact: weak primitives drag the grade down even when the certificate is perfect, because the certificate is not what gets attacked - the transport is. Watch for RC4, 3DES (the SWEET32 weakness), export-grade suites, and anything with NULL or anonymous (aNULL) key exchange.

Issues Found

The prioritised list of problems, each tagged with a severity. How to read it - work top down:

• Critical (red) - broken or unsafe right now; visitors may be seeing warnings. Fix today.
• High (orange) - a serious weakness that will bite. Fix this week.
• Warning (yellow) - worth tidying; not an emergency.
• Info (blue) - a note, not a problem.

A clean report with no critical or high issues means everything above is in good shape. The catch is that a scan is a snapshot: certificates expire and configurations drift, so a green report today says nothing about next month. That is the gap continuous monitoring closes.