How to Read an SSL Inspector Report, Field by Field

Run a domain through our SSL Inspector and you get a grade, a validity line, a list of hostnames, an issuer, a long hexadecimal fingerprint, an HSTS block and some recommendations. Most of it makes sense at a glance, but a few fields answer a narrower question than their labels suggest, and the grade in particular rewards different things than people expect.

This guide walks through the report in the order it appears. If you want background on certificates themselves first, how SSL certificates work covers the basics.

Where the data comes from#

Every value on the report comes from one of two places, and knowing which is the key to reading it correctly.

• Certificate Transparency logs. Publicly trusted certificates are recorded in public, append-only logs, and Chrome will not accept a public certificate that was never logged. The inspector asks SSLMate's certspotter service for unexpired certificates issued to the exact hostname you typed, and picks the newest. Everything in the certificate, SAN and chain sections comes from that log entry.
• A live HTTPS request. At the same time, the inspector sends a request to https://yourdomain/, follows up to five redirects, and records the status code and the Strict-Transport-Security header of the response it lands on.

Notice what is missing: a TLS handshake. The inspector runs on Cloudflare Workers and does not perform a handshake of its own, so the report cannot show the negotiated TLS version, the cipher suite, the key type and size, or the chain your server actually sends. For those, use a handshake scanner; our roundup of free SSL test tools explains which one fits.

The log-based approach has one consequence worth carrying through the rest of the report. It shows the newest valid certificate issued for the name, which is usually, but not always, the one being served. If you renewed yesterday and never reloaded the web server, or several servers behind one hostname each hold their own certificate, the two can differ. The fingerprint section below shows how to check.

The validity line and days remaining#

The first card gives the plain answer: valid, expiring, expired or invalid. It is computed from the certificate's Valid from and Valid to dates, which also appear in the certificate grid next to Days remaining.

Days remaining is counted in whole days, rounded down. Once it falls to 30, the line turns into a warning and the grade starts losing points. Let's Encrypt certificates last 90 days and Let's Encrypt suggests renewing about every 60, so a healthy automated setup rarely gets within a month of expiry. If you see the warning, ask why renewal did not run. A broken scheduled job, a DNS provider change that stopped DNS-based validation, or a firewall blocking the HTTP challenge on port 80 are the usual answers.

Subject, SANs and hostname coverage#

The Subject Alternative Names list is the most important part of the certificate. It holds every hostname the certificate is valid for, and it is what clients actually check. RFC 9525, the current standard for matching a server's name against its certificate, says the older Common Name field must not be used to identify a service.

That is why the report's Subject CN row is derived from the SAN list rather than read from the certificate. If the hostname you queried is in the list, or covered by a wildcard, it shows that name; otherwise it shows the first non-wildcard entry. Treat it as a label, not as evidence.

A wildcard entry, highlighted in the list, covers exactly one label. *.example.com matches www.example.com and shop.example.com, but not api.eu.example.com, and it does not cover the bare example.com either. A certificate issued for the wildcard alone and deployed on the bare domain is one of the most common hostname mismatches. The fix is a certificate whose SAN list includes both names.

One quirk follows from the log lookup. The inspector asks for certificates that name your hostname exactly, so a host covered only by a wildcard can come back as "no certificates found" even though browsers accept it. The same message appears when every certificate for the name has expired, or when the certificate comes from a private CA that never logs to CT. If you get it for a site that loads fine, open the certificate viewer from your browser's address bar and read the SAN list there.

Issuer and the chain of trust#

The issuer rows tell you which certificate authority signed the certificate. Issuer CN is the name of the specific intermediate certificate, Issuer org is the company behind it, and Issuer country is its two-letter country code. For a Let's Encrypt certificate, expect the organization Let's Encrypt, the country US, and a common name that is a short code of letters and digits rather than anything descriptive. CAs rotate their intermediates, so a different code from last year's certificate is normal.

What deserves attention is an issuer you do not recognise. If your team uses one CA and the report shows another, something requested a certificate you did not plan for: a CDN, a hosting control panel, a forgotten automation. It is not necessarily an attack, but it needs an explanation. Our guide to controlling who can issue certificates for your domain covers how to find every issuer in the logs and restrict the list with CAA.

The chain card shows two boxes: your certificate, and the issuer that signed it. Be clear about what the second box is. It is rebuilt from the issuer name recorded in the log; the inspector does not download the intermediate or the root, and it cannot see which intermediates your server sends. A missing intermediate on the server, a classic cause of a site that works in one browser and fails in command-line tools, will not show up here. To see the chain as served, run this and count the certificates in the output:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

SSL certificate chains explained covers what a correct chain looks like and how to fix an incomplete one.

The SHA-256 fingerprint#

The long colon-separated hex string is a SHA-256 hash of the whole certificate. It is unique to that certificate, which makes it the most reliable way to tell whether two certificates are the same one. A renewal produces a new certificate and a new fingerprint, even when every other field looks identical.

This is how you close the gap between the newest certificate issued and the certificate actually served. Fetch the live certificate's fingerprint and compare the two:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256

If they match, the report describes your live certificate. If they don't, your server is still presenting an older certificate (common right after a renewal when the web server was never reloaded), or you reached a different server than the one holding the new certificate. Either way, trust the server's expiry date over the report's.

HSTS and transport#

This card comes from the live request. HTTPS status is the status code of the page the request ended on. Any response below 500, a 403 or 404 included, counts as reachable, because it proves a TLS connection succeeded; what the page says is irrelevant. If the request failed outright or timed out, the card says unreachable instead.

The rest of the card parses the Strict-Transport-Security header, which tells browsers to use only HTTPS for your site for a set period:

• max-age is how long, in seconds, browsers remember the rule. The report converts it to days or weeks and marks it green at 31,536,000 seconds (one year) or more.
• includeSubDomains extends the rule to every subdomain.
• preload signals that you want to be on the list built into browsers. The directive alone does nothing; you still have to submit the domain at hstspreload.org.

Because the request follows redirects, the header shown belongs to the final page. If example.com redirects to www.example.com, you are reading the www header. That matters for preloading, which checks the header on the base domain and expects it on any redirect the HTTPS site serves as well. Our HSTS checker adds the domain's current status on the preload list, and HSTS preload explained is worth reading before you add includeSubDomains to a domain whose internal subdomains lack HTTPS.

How the grade adds up#

The letter grade is where readers most often draw the wrong conclusion, so here is the arithmetic.

First, the hard failures. A certificate that is revoked, expired, not yet valid, or does not cover the hostname gets an F. A revocation counts only when the log service knows about it; an unknown status is not held against you. If the certificate is fine but HTTPS did not respond, the grade stops at D, because a certificate in a log proves nothing about a running server.

Everything else starts at 70 points for a valid certificate on a reachable server, and that alone is a C. From there:

• An HSTS header adds 10 points, a max-age of at least a year adds 5, includeSubDomains 3 and preload 7.
• Expiry within 30 days removes 10 points, and within 7 days it removes 25.

The thresholds are 85 for an A, 75 for a B, 60 for a C and 40 for a D. An A+ needs 95 points, all three HSTS directives and no expiry warning, which in practice means the full preload-ready header on a certificate with more than a month left.

Two readings follow. A C usually means no HSTS, not a weak certificate: a flawless certificate on a server without the header lands exactly there. And an A+ says nothing about protocols or ciphers, since the inspector cannot see them. A server still offering TLS 1.0 can score A+ here and fail a handshake scanner. The grade measures certificate health plus HSTS and nothing more. The rationale list under it spells out each point awarded or taken away.

Recommendations and a routine that works#

The recommendations list turns the same findings into actions, most urgent first: replace a revoked certificate, renew an expired or expiring one, check hostname coverage, confirm the certificate is deployed if HTTPS did not answer. For HSTS it suggests only the next rung of the ladder (add the header, raise max-age to a year, add includeSubDomains, then add preload and submit), so expect a new suggestion each time you fix the current one. An empty list means every check the report can make passed.

For a site you run, a short routine works well: check the grade and days remaining now and then, compare the fingerprint with the live server after every renewal, glance at the issuer for surprises, and run a handshake scanner occasionally for the protocol and cipher side this report cannot see.