` reads). %> How to Read Your SSL Scan Report (Without Being a Security Expert) | TLS Radar Skip to main content
guides 5 min read By TLS Radar Team

How to Read Your SSL Scan Report (Without Being a Security Expert)

You ran a scan - or someone sent you a shared report - and now you are looking at a big letter grade, a list of issues, and a panel of certificate details. If you are not a security person, it can read like a blood test result: clearly important, not obviously actionable. This is a plain-English walk through every part of the report, what each piece means, and what to do about it.

The big letter grade

The grade is a single summary, A+ down to F, exactly like a school report card. It rolls up every individual check into one score:

  • A+ / A - Strong configuration, nothing critical. You can leave it alone.
  • B - Good, with minor improvements possible.
  • C - Fair. Several things worth addressing.
  • D - Poor. Significant weaknesses.
  • F - Fail. Something is critically wrong - expired, broken, or insecure.

The one rule worth knowing: a single critical problem drops the grade hard. A site can do almost everything right and still score an F because its certificate expired yesterday. So do not panic at the letter itself - scroll to the issues list to see why you got it.

Issues Found - and which ones actually matter

Each issue carries a coloured severity tag. In order of urgency:

  • Critical (red) - your site is broken or unsafe right now. Visitors may be seeing security warnings. Fix today.
  • High (orange) - a serious weakness that is not yet causing an outage, but will bite. Fix this week.
  • Warning (yellow) - worth tidying up; not an emergency.
  • Info (blue) - a note, not a problem.

Work top-down: clear every critical and high item first, then the rest. The most common ones, in plain terms:

  • Certificate expired. The most common critical issue. The fix is to renew and reinstall the certificate. If you need one back up fast, you can issue a free replacement in minutes.
  • Incomplete chain. Your certificate is valid but the supporting documents that vouch for it are not all being sent. The classic symptom: the site works on your desktop but fails on phones. Here is why that happens.
  • Hostname mismatch. The certificate is real, but it does not cover the exact address people typed (for example it covers example.com but not www.example.com). Browsers treat this as untrusted.
  • Weak protocol or cipher. Your server still allows outdated, breakable encryption. Nothing looks wrong to a casual visitor, but it is exactly what an attacker probes for.
  • Known vulnerability. A named flaw like Heartbleed or POODLE. A non-expert guide to what these are.

If the report came back clean with no critical or high issues, you are in good shape - the rest of the report is just confirmation.

Certificate Details - the sanity check

This panel is the certificate's ID card. Three things are worth a glance:

  • Issued by. The certificate authority that vouches for you (Let's Encrypt, DigiCert, and so on). If this is a name you do not recognise, it is worth asking who set it up.
  • Covers. The exact domain names the certificate is valid for. Make sure the address your customers actually use is in this list.
  • Expires. The single most important date in the whole report. The summary shows it as "expires in N days." Anything under a couple of weeks deserves attention now.

Will it be trusted everywhere? The trust-store check

A detailed report - the kind you get for a domain you monitor - does not just say "trusted" or "not." It checks your certificate against the separate trust lists that different platforms keep, and shows a tick or a cross for each: Apple, Android, Windows, Firefox (Mozilla), and Java. This matters because they do not always agree. A certificate can work perfectly in your browser and still be rejected on, say, older Android phones. If most stores are green and one is red, that is your "some customers can't reach us" problem - spotted before they complain.

A few other labels you might see in that report, in plain terms:

  • EV - an Extended Validation certificate, the most heavily vetted kind. Nice to have, not required.
  • OCSP stapling - a speed and privacy optimisation. "Enabled" is good; "none" is not a problem, just a missed nicety.
  • SHA-1 in chain or distrusted Symantec anchor - these are genuine red flags. They mean part of your certificate chain uses something browsers no longer trust, and the fix is a fresh certificate from a current provider.

"Share This Report"

Every report has its own link. This is genuinely useful: instead of describing the problem, you can send the exact report to whoever runs your hosting, your developer, or a vendor whose site is failing. It says, in one click, "here is precisely what is wrong."

What to do after you have read it

A scan is a snapshot - it tells you the state of things right now. The catch is that certificates expire on their own schedule, and the next problem will not announce itself. A clean report today says nothing about three months from now.

So the move after reading a report is to stop relying on remembering to re-scan. Scan the domain again any time to confirm a fix worked, and if it is a site you care about, put it under continuous monitoring so the next expiry or misconfiguration reaches you - with time to act - instead of reaching your customers first.

Get the next post in your inbox

TLS monitoring tips and product updates. No spam, unsubscribe anytime.

Keep reading

guides 4 min

I don't want to learn what PKI, CA, ACME, EKU stand for, I only want a working certificate for my website
guides 3 min

Manage Your SSL Certificates by Just Asking Claude
troubleshooting 4 min

My SSL Certificate Expired - How to Fix It ASAP

Related guides

Comparing tools? See how TLS Radar stacks up against DigiCert and SSL.com.