What Your SSL/TLS Grade Means: A+ to F, Explained Factor by Factor

Every developer has seen an SSL grade — the A+ badge people screenshot, the C that shows up in a security review the week before an enterprise deal closes. But ask what the letter actually measures and most answers stop at "certificate stuff."

The letter is a compression of four or five independent properties of your TLS deployment, each with its own failure modes and its own fix. This post decompresses it: what's evaluated, what each deduction means, and why "the padlock shows up in Chrome" and "this deployment is well-configured" are very different statements.

The padlock is table stakes, not a grade

Browsers show the padlock if your certificate is valid and the connection negotiated some acceptable encryption. That's a pass/fail check with a low bar. A grade asks harder questions: which protocol versions will you negotiate, which ciphers will you accept, is your certificate chain complete, will you protect users who type your domain without https://, and does the secure page quietly load insecure resources?

Two sites with identical padlocks can sit at opposite ends of the scale — one negotiating TLS 1.3 with modern ciphers and preloaded HSTS, the other still accepting TLS 1.0 with cipher suites deprecated a decade ago.

Factor 1: Protocol versions — the floor and the ceiling

TLS versions are not increments; they're security eras.

• TLS 1.0 (1999) and 1.1 (2006) are formally deprecated (RFC 8996, 2021). They permit weak hashes and CBC constructions with known attack classes (BEAST, POODLE-adjacent downgrade paths). Every major browser dropped them in 2020. Accepting them — even if modern clients never pick them — caps your grade, because a protocol you accept is an attack surface you own: downgrade attacks work by forcing the negotiation to the worst thing you'll agree to.
• TLS 1.2 (2008) is the secure baseline when configured with modern cipher suites. It's the floor for a passing grade.
• TLS 1.3 (2018) removed the foot-guns rather than patching them: weak ciphers are gone from the spec, forward secrecy is mandatory, the handshake is faster (one round trip, with 0-RTT resumption) and encrypts more of itself. Supporting it is the ceiling-raiser — no TLS 1.3, no A+.

The fix is usually one config block (or one CDN toggle): minimum version 1.2, enable 1.3. If your TLS terminates at Cloudflare, Vercel, or a load balancer, this is the provider's panel, not your code.

Factor 2: Cipher suites — what "weak" actually means

A cipher suite is the bundle of algorithms a connection uses for key exchange, encryption, and integrity. "Weak" isn't an insult; it's a category with specific members:

• RC4 — biases exploitable at scale; prohibited since 2015
• 3DES — 64-bit blocks make it Sweet32-vulnerable on long connections
• CBC-mode suites with SHA-1, export-grade ciphers, and anything with NULL or anonymous key exchange
• Non-ephemeral RSA key exchange — works, but provides no forward secrecy

Forward secrecy (the ECDHE in modern suite names) deserves its own sentence: with ephemeral key exchange, each session gets throwaway keys, so an attacker who records your traffic today and steals your private key next year still can't decrypt the recordings. Without it, your private key is a skeleton key for all past captured traffic. Graders reward forward-secrecy-everywhere; TLS 1.3 makes it mandatory.

Like protocol versions, this is about what you accept: one legacy suite kept "for compatibility" with clients that no longer exist is a standing downgrade target.

Factor 3: Certificate health — where outages live

Most TLS incidents aren't cryptographic; they're operational, and they're certificate-shaped:

• Expiry runway. Certificates now live ≤398 days (and the CA/Browser Forum has voted to shorten lifetimes further, stepping down to 47 days by 2029) — renewal is a treadmill, and an expired certificate is a full outage with a scary browser interstitial. Monitoring the days remaining, not just validity-right-now, is the difference between a calendar entry and a 3 AM incident. Certificate Transparency logs make this externally observable: every publicly-trusted certificate is logged at issuance, so your cert inventory — including ones a teammate issued from a different ACME client — is public record.
• Chain completeness. Your server must send the intermediate certificates, not just the leaf. Browsers often paper over a missing intermediate (cached or fetched on the fly); stricter clients — curl, mobile apps, webhooks, monitoring probes, other people's backends calling your API — fail with trust errors. "Works in Chrome, fails in curl" is almost always an incomplete chain.
• Coverage. The certificate must match the names users actually hit — apex and www both, plus any API subdomains.

Factor 4: HSTS — protecting the first request

Your perfect TLS config doesn't help the user who types yourdomain.com into the address bar: that first request goes out over plain HTTP, and an attacker on the path (public Wi-Fi is the classic venue) can intercept it and keep the victim on HTTP or hand them a different destination entirely — the SSL-stripping attack.

HSTS (Strict-Transport-Security) is the header that closes this: once a browser has seen it, it refuses to speak HTTP to your domain for max-age seconds, upgrading every request to HTTPS before it leaves the machine. Configuration has real gradations: a long max-age (six months minimum for credit), includeSubDomains so staging and API hosts inherit protection, and preload — shipping your domain in the browsers' built-in HSTS list so even the first-ever visit is protected. Preload + TLS 1.3 + clean ciphers is the classic A+ profile.

One honest caveat: preload is close to irreversible (removal takes months to propagate), so turn it on after includeSubDomains has baked without incident — not as day-one resume polish.

Factor 5: Mixed content — the self-inflicted hole

A perfectly configured HTTPS page that loads a script over http:// has reopened the door TLS closed: an attacker who can touch that one insecure request can inject into the secure page. Browsers block active mixed content (scripts, iframes) and increasingly upgrade or block passive content (images), but the result is broken pages, console warnings, and a padlock that downgrades. Mixed content is almost always a hardcoded http:// URL in a template or a database-stored asset link from the pre-HTTPS era — grep-able, fixable, and worth a deduction anywhere it appears because of how cheaply it undermines everything else.

Reading the letter

Putting it together, the grades roughly mean:

• A+ — TLS 1.3, modern ciphers with forward secrecy, healthy certificate with runway, HSTS with strong max-age (typically preloaded), no mixed content
• A — the same deployment minus a refinement (usually HSTS preload or TLS 1.3)
• B — fundamentally sound with a real deduction: a weak cipher still accepted, HSTS missing, short cert runway
• C — multiple deductions, or a deprecated protocol version still negotiable
• D/F — actively dangerous: expired/invalid certificate, broken chain, TLS 1.0/1.1 reachable, or no effective HTTPS enforcement

The encouraging part: almost every deduction is a configuration change, not an engineering project. The discouraging part: they regress silently — a CDN migration resets your TLS posture to the provider's defaults, a new subdomain ships without HSTS, a certificate auto-renewal quietly stops. Which is why grading belongs in continuous scanning, not in an annual audit.

CheckVibe's SSL/TLS check computes the grade on every scan — protocol versions, cipher strength, forward secrecy, certificate validity and expiry runway via Certificate Transparency logs, HSTS policy, and mixed content — with a fix prompt per deduction, and the domain health check keeps watching certificate runway between scans. Run a free scan to see your letter and exactly which factor is capping it.

FAQ

What's the difference between an A and an A+ TLS grade?

An A is a clean, modern deployment. The plus typically requires the refinements: TLS 1.3 support, forward secrecy across all accepted cipher suites, and a strong HSTS policy (long max-age, usually preloaded). None of them change the padlock; all of them change what an attacker on the network path can do.

Is TLS 1.2 still safe in 2026?

Yes — with modern cipher suites (AEAD/GCM, ECDHE key exchange) TLS 1.2 remains the accepted secure baseline. The grade pressure is in two directions: stop accepting 1.0/1.1 (deprecated, downgrade surface) and add 1.3 (mandatory forward secrecy, faster handshake, smaller attack surface).

Why does my site fail in curl but work in browsers?

Almost always an incomplete certificate chain: your server sends only the leaf certificate and browsers silently fetch or cache the missing intermediate, while curl, mobile apps, and server-to-server clients don't. Serve the full chain (leaf + intermediates) and both will agree.

Should I enable HSTS preload?

Eventually, yes — it protects even a user's first-ever visit, and it's part of the classic A+ profile. But it's effectively a one-way door (removal from browser preload lists takes months), so enable includeSubDomains first, run it long enough to confirm every subdomain works over HTTPS, then preload.

How often should TLS configuration be checked?

Continuously — the failure modes are silent and operational, not gradual. Certificates expire on a date, CDN migrations reset cipher and protocol settings to provider defaults, and new subdomains launch without HSTS. A scheduled scan that re-grades TLS and watches certificate expiry runway turns each of these from an outage into an email.