SSL/TLS Scan Report Fields Explained

A TLS Radar scan report describes the certificate a server presents and how well it is set up. This page explains every field in plain English - what it means, what a good value looks like, and what your visitors actually experience when something is wrong. No prior knowledge needed.

A quick picture to hold in your head: your certificate is like a passport for your website. The scan checks that the passport is real, has not expired, was issued by an authority other computers recognise, and carries the correct name. If any of that fails, browsers stop trusting your site and show a warning to the people trying to visit it.

Free scan vs the in-depth report

You can read most of this report without an account. Signing in adds more detail and turns a one-time check into ongoing monitoring.

• The free scan (no account needed) gives you the grade, the list of issues, the core certificate facts (who the certificate is for, who issued it, when it expires, whether it is trusted, and whether it matches the address), and an Advanced details panel you can open for the public key, signature, Certificate Transparency, OCSP stapling, and the per-platform trust results.
• The in-depth report (after you sign in) shows all of that laid out on one page, and adds a days-until-expiry countdown, the full list of which protocol versions are switched on, the exact cipher suites your server will accept, and the complete trust-store breakdown. It also re-scans on a schedule and alerts you the moment something changes - so you learn about a problem before your customers do.

The fields below are grouped the same way they appear on the report. Where a group is only in the signed-in in-depth report, it is marked (in-depth report).

The grade

Grade (A+ to F). One letter that sums up every check below, like a report card for your website's security. It is not an average: a single serious problem - an expired certificate, a broken chain, or an obsolete protocol like SSLv3 - caps the grade no matter how good everything else is. How to read it: A+ is best-in-class, A is strong, B means minor improvements, C is fair with several issues, D is poor with significant weaknesses, and F means something is critically wrong right now. Always read the issues list underneath to see why you got the grade you did.

Certificate

These fields describe the certificate's own identity and the maths that protects it.

Common Name / covered names. The website address the certificate is meant for, for example example.com. How to read it: it should be the site you scanned (or a wildcard like *.example.com that includes it).

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

Valid from / Valid until. The first and last day the certificate can be used. How to read it: a "valid from" date in the future means the certificate is not usable yet (often a wrong clock on the server); "valid until" is the expiry date. What visitors see: outside this window, browsers reject the certificate and show a full-page warning to everyone who opens your site.

Days remaining. (in-depth report) How many days until the certificate expires. How to read it: under about 30 days deserves attention; a negative number means it has already expired. Why it matters: a forgotten renewal is the single most common cause of website outages - the fix is easy, but only if you notice in time.

Public key. The type and size of the key that protects the connection, for example RSA 2048-bit or EC P-256. How to read it: RSA should be 2048-bit or larger; elliptic-curve keys such as P-256 are strong even at smaller sizes. Why it matters: undersized keys (RSA 1024 and below) are considered weak and lower your grade.

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

Key Usage. (in-depth report) What the key is allowed to do at a low level. The two you will usually see on a website certificate are:

• digitalSignature - the key may sign data to prove your server is really the one the visitor is talking to. This is what stops someone from pretending to be your site in the middle of the connection.
• keyEncipherment - the key may be used to protect (scramble) the secret that the browser and server share to encrypt the rest of the conversation.

How to read it: a normal website certificate carries the usages its connection needs, and you do not need to set these by hand - your CA fills them in. A certificate used outside its declared usage is rejected by strict clients.

Extended Key Usage (EKU). The specific jobs the certificate is allowed to do, shown as friendly names. The two that matter here are:

• serverAuth - lets the certificate prove your server's identity to a visitor's browser. This is the one a website needs; without it, the certificate simply cannot be used for a website.
• clientAuth - the reverse: it lets a certificate prove a client's identity to a server. This is used when a program or device has to identify itself - for example connecting to a partner's API or a company VPN - not for serving a public website.

How to read it: a website certificate must include serverAuth. A certificate that is missing it, or carries only clientAuth or another unexpected usage, will be distrusted for web use.

Basic Constraints. (in-depth report) Whether the certificate is an authority (CA) or an ordinary end certificate (leaf). How to read it: a website certificate should say it is not a CA. A leaf that claims to be a CA is a serious red flag and a sign of misissuance.

Trust & Validation

These signals describe what happens when a real browser tries to check the certificate.

Trusted. The bottom-line verdict: does the certificate chain check out against the common lists of trusted authorities. How to read it: "trusted" is the goal. What visitors see if it says "not trusted": a full-page warning such as "Your connection is not private", and most people leave the site immediately rather than click past it.

Hostname match. Whether the address you scanned is actually listed on the certificate. How to read it: "matches" is required. A mismatch means the certificate is genuine but does not cover this exact name - for example it covers example.com but you visited www.example.com. What visitors see: the browser treats a mismatch as untrusted and shows the same security warning.

Certificate valid / expired. A direct check of the expiry date. What visitors see if expired: the padlock disappears and every single visitor gets a warning until you renew.

Chain order. (in-depth report) Whether the server sent the supporting certificates in the correct order. How to read it: "valid order" is correct; "sent out of order" still works in forgiving browsers but breaks stricter apps. Why it matters: this is a classic cause of "it works in my browser but some customers cannot connect".

SHA-1 in chain. Flags an old, broken SHA-1 signature anywhere in the chain. How to read it: you want this absent. Why it matters: SHA-1 is cryptographically broken and no longer allowed; modern browsers reject any chain that contains it. Treat it as a hard failure and reissue from a current CA.

Distrusted Symantec anchor. Flags certificates that trace back to the old Symantec authorities that browsers removed trust for. Why it matters: these are no longer trusted by major browsers - replace them.

OCSP stapling. Whether the server attaches a fresh "this certificate has not been revoked" note to each connection. How to read it: "enabled" is ideal; "not trusted" means the note failed its check; "none" simply means the speed-up is switched off. Why it matters: stapling makes connections faster and more private. Its absence is not a failure on its own - unless the certificate is marked Must-Staple (below).

EV. Marks an Extended Validation certificate, the most heavily vetted type, where the CA confirms the real-world company behind the site. You may remember a time when browsers rewarded this with a green padlock and the company's name shown in the address bar - the kind of thing you might have seen on a bank's website. How to read it: a badge, not a requirement. Most modern browsers have since removed that special green display, so an EV certificate now looks the same to visitors as a standard one. Most websites run perfectly well on standard certificates.

Must-Staple. Marks a certificate that requires OCSP stapling to work. Why it matters: if a Must-Staple certificate is served without a valid staple, browsers reject it - so this flag and the OCSP stapling status above must agree.

Certificate Transparency (SCT count). The number of public log records proving the certificate was published openly. How to read it: modern browsers (notably Chrome) expect at least two. Why it matters: too few and Chrome will distrust the certificate.

Trust Stores

"Trusted" is not one simple yes-or-no. Each platform keeps its own list of authorities it recognises, and they do not always agree. The in-depth report checks your certificate against every one of them and shows a tick or a cross for each.

• Apple - Safari and apps on iPhone, iPad, and Mac.
• Android - phones and tablets (older devices are slower to learn about new authorities).
• Windows - Edge and most Windows programs.
• Mozilla - Firefox, plus many command-line tools and Linux systems.
• Java (Oracle) and Java (OpenJDK) - server-to-server and business software.

How to read it: the heading shows how many stores trust you, for example "5/6 trusted". All green is the goal. Why it matters: if most stores pass but one fails, that single cross is your "some customers cannot reach us" problem - often an older Android phone or a Java app missing a newer authority. It is completely invisible if you only test in your own browser, which is exactly why the report checks all of them for you.

Protocol Support (in-depth report)

The versions of the security protocol your server will use. Newer is safer; the old versions are like old door locks that thieves already know how to open. How to read it:

• TLS 1.3 - the current best. Keep it on.
• TLS 1.2 - the safe minimum. Fine to keep on.
• TLS 1.1 / TLS 1.0 - retired. Still offering them is a graded weakness and can fail compliance checks such as PCI DSS (the rules for handling card payments).
• SSLv3 / SSLv2 - broken. Offering either is a critical problem - switch them off straight away.

Accepted Cipher Suites (in-depth report)

A cipher suite is the exact recipe your server and the visitor's browser agree on to scramble the connection. The report lists every recipe your server will accept, grouped by protocol version. How to read it: look for forward secrecy (recipes containing ECDHE, which protect past traffic even if a key later leaks) and modern encryption (AES-GCM or ChaCha20). Why it matters: a weak recipe lowers your grade even when the certificate itself is perfect, because attackers target the connection, not the passport. Watch for old, weak names such as RC4, 3DES, "export" suites, or anything with NULL in it - these should not be offered.

Issues Found

The prioritised list of problems, each tagged with a severity so you know what to do first. How to read it - work from the top down:

• Critical (red) - broken or unsafe right now; visitors may already be seeing warnings. Fix today.
• High (orange) - a serious weakness that will cause trouble. Fix this week.
• Warning (yellow) - worth tidying up; not an emergency.
• Info (blue) - a note for your awareness, 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 single photo in time: certificates expire and settings drift, so a green report today tells you nothing about next month. That gap - between one-off checks and knowing the moment something breaks - is what continuous monitoring closes. Sign in to keep an eye on your domains automatically and get an alert before your visitors ever see a warning.