TLS grades: how they are earned, and how they are lost

What a grade is actually measuring

Most people meet TLS through one symptom: a browser warning, or the absence of one. A grade widens that view to the whole setup. First, the protocols a server offers. A handshake pinned to each version — TLS 1.0, 1.1, 1.2, 1.3 — shows what the server will still speak when asked, which is different from what it negotiates with a modern browser. A server that answers TLS 1.0 is not broken for its current visitors; it is keeping a twenty-five-year-old protocol on offer for anyone who chooses it, and the grade treats that as a fact about the server, not about its visitors. Second, the certificate: who issued it, which names it covers, when it expires, how strong its key is, and what it was signed with. Third, forward secrecy: whether the negotiated cipher protects recorded traffic against a future key compromise. Fourth, HSTS: whether the site tells browsers to refuse plain HTTP for it in future, and for how long.

The SSL grader measures all four from sysosx's server and starts every site at A+, then applies caps: the worst applicable cap wins, and each one is reported as a finding. That structure matters, because it makes the grade actionable. A grade is not a score to admire; it is a list of findings to work through, worst first. An F means browsers reject the site. A C means something is obsolete or untrusted. A B means a real but survivable weakness. An A means one soft issue. The rest of this article walks those caps in that order — the order worth fixing them in.

The F grade: browsers reject the site

Four failures earn an F, and all four are visible to every visitor. An expired certificate is the most common and the most embarrassing, because it has a known date and still surprises people: automated renewals fail silently — a DNS challenge that no longer validates, a renewal script on a decommissioned server, a plugin that stopped running after an update — and one morning every browser shows a full-page warning. The fix is process: automate renewal, monitor the date independently of the automation, and act inside thirty days. A self-signed certificate earns an F for a different reason: no public trust anchor vouches for it, so a browser cannot distinguish your server from an impostor's. Self-signed certificates have a legitimate home — internal tooling, development, services behind a private trust store — but a public site is not it. A hostname mismatch means the certificate's name list does not include the name visitors actually use: the bare domain without www, a forgotten subdomain, a certificate served for the wrong virtual host. Check which name the site is meant to be reached by, and make sure that exact name is on the certificate. And an MD5 signature earns an F because the hash has been broken for over a decade; any certificate still signed with it should be re-issued immediately, whatever else is true about it.

The C grade: obsolete or untrusted

A C means the site loads, but something in the setup belongs to an earlier era or fails a strict check. The most instructive C is the chain that does not validate. A server must present not just its own certificate but the intermediate certificates linking it to a trusted root, in the right order. When an intermediate is missing, regular visitors often see nothing wrong: browsers cache intermediates and fetch missing ones themselves. First-time visitors, fresh API clients and strict checkers see only what the server sends — which is why the grader reports the chain as broken even while your own browser insists everything is fine. The fix is server configuration: send the full chain, leaf plus intermediates, in order, and verify from a clean client rather than your own browser. A weak key earns a C the same way: RSA below 2048 bits, or a small elliptic curve, is below every current floor, and the fix is re-issuing with a modern key. A SHA-1 signature is the same story — deprecated, rejected by browsers, fixed by re-issuing with SHA-256 or better. And a server whose highest supported protocol is TLS 1.1 or older earns a C because modern clients have dropped those versions entirely; such a server is not serving the current web at all, and the fix is enabling TLS 1.2 at minimum, preferably 1.3.

The B grade: real but survivable

A B is the grade of a setup that works and is mostly current, with one genuine weakness. The commonest is a legacy protocol still enabled alongside current ones: TLS 1.0 or 1.1 answering for anyone who asks. Nothing current needs those versions — no modern browser, library or API client negotiates them — so disabling them costs no compatibility and removes the weakest ciphers from offer. It is usually one configuration line, and the grade recovers on the next check. The other B is a cipher without forward secrecy: with a static RSA or ECDH key exchange, anyone who records today's encrypted traffic and later obtains the server's private key can decrypt it. Ephemeral suites (ECDHE) make each session's key disposable, so recorded traffic stays sealed even after a compromise. The fix is preferring ECDHE suites in the server's cipher order — and, on TLS 1.3, the problem disappears by construction, since every TLS 1.3 suite is forward-secret. If you are choosing between the two B fixes, disable the legacy protocols first: it is the smaller change and it removes an entire class of old attacks, not just one cipher property.

The A grade: one soft issue

An A means everything structural is right and one soft issue remains. Usually it is HSTS: either no strict-transport-security header at all, or a max-age below six months. Without HSTS, the first visit to a site is still downgradable to plain HTTP — an attacker on the network path can intercept that first request before the browser ever learns the site prefers HTTPS. The header closes that hole by telling the browser, once it has seen it, to refuse HTTP for the site for the stated period. Set it with a long max-age once you are sure HTTPS works everywhere on the site, including subdomains if you add includeSubDomains, and consider preload only after the setup has been stable for a while — preload is a one-way door that takes months to reverse. The other A-level finding is a certificate inside its 30-day renewal window: not a failure, but the moment to confirm renewal is actually working rather than assuming it.

What a grade does not cover

A grade is a setup audit, not a security proof, and its limits are worth stating. It does not check OCSP stapling — the grader's TLS library does not expose stapled responses, so it reports stapling as not checked rather than guessing. It does not simulate every client: a server can grade well and still fail one particular old device, and it can grade poorly on a protocol no visitor uses. It does not judge the site's application security — headers, cookies, content policy — which is what the website health check and the status chain checker cover from other angles. And it is a snapshot: certificates expire, servers get reconfigured by other people's migrations, defaults drift. Re-grade after every TLS change and once a quarter as routine, and let continuous monitoring carry the dates between grades. Used that way, a letter grade stops being a badge and becomes a short, honest work list.

Start with your own site: run the SSL grader, read the findings worst-first, and fix in the order above. If the certificate itself is the question rather than the setup, the SSL checker gives the quick view — issuer, covered names, validity and countdown — on the same engine.

Frequently asked questions