A certificate that renews correctly is not the same as a TLS setup that works. This site's certificate renews fine — and yet, until recently, no externally-run test had ever checked what a real visitor's browser actually gets.
So when services go public around here, one of the first checklist items is an external scan: SSL Labs' SSL Server Test. We run it, we read it, and we treat the result as the baseline for the service, not as a one-time favour to the certificate.
I ran it against this site while writing this post. The result is A+, but the interesting part is what the report says about that result — and what a test like this does that a curl from inside the lab can't.
A certificate is not a configuration
Renewal tells you one thing: the certificate authority still issues you a signed certificate on schedule. It does not tell you:
- whether the served chain is complete and trusted by every major client,
- whether a browser and a generic script arrive at the same endpoint,
- which protocol versions and cipher suites are actually negotiated,
- whether HSTS is present and set to a sane value,
- whether the hostname the visitor typed resolves to the same TLS endpoint the certificate names,
- or whether an old, weak endpoint is quietly left enabled alongside the good one.
Those are configuration questions, and renewal software does not answer them. A certificate can renew forever on a host where the configuration behind it is broken, partial, or serving yesterday's defaults.
Why an external test, from a third party
The temptation is to test from inside: you know the certificate name, you can reach the host, you can even script a handshake. The problem is that inside-looking checks tend to test what you already believe.
An external scanner like SSL Labs sits outside your network, in roughly the position a real visitor does. It resolves the public name, connects over the public path, and grades what it finds — without any shortcut you get for being on the same LAN, in the same DNS zone, or already holding the private key. If your setup only works "from here", an external test is where that shows up.
It also tests the way clients actually test: through the browser's trust store, through the intermediate chain shipped by every major CA, through the HTTP stack that applies HSTS. It tests every IP address the name resolves to, and simulates handshakes from dozens of real clients, so your TLS answer has to be consistent across endpoints — not just correct on the machine next to the server.
What the report grades
SSL Labs walks through everything a real deployment must get right, in five sections:
- Certificate: chain, validity dates, signature algorithm, key size, revocation coverage (OCSP/CRL).
- Protocol support: which TLS versions are enabled and which are disabled. TLS 1.0/1.1 have no business being enabled on a public service in 2026.
- Key exchange: whether forward secrecy is actually in force — not just advertised.
- Cipher strength: per-protocol cipher selection, with the weak ones that should be disabled.
- Configuration notes and HSTS: whether clients are instructed to skip plain HTTP, and whether that instruction is durable (
includeSubDomains, a sanemax-age).
For this site, the report found: a full and trusted chain, TLS 1.3 negotiated with a modern AEAD cipher (TLS_AES_256_GCM_SHA384), no protocol downgrades, strong key exchange, and HSTS set to max-age=31536000; includeSubDomains. That last line is what pushes an otherwise-good deployment from A to A+ on the report's scale.
Why it is on the launch checklist
We learned the hard way that "the page loads" and "the user connection is sound" are different claims. Every service we run publicly gets the same short list before it counts as live:
- TLS 1.3 enabled, TLS 1.0 and 1.1 disabled.
- HSTS set with subdomains, so a visitor never silently falls back to plain HTTP.
- A complete, trusted chain — no missing intermediates concatenated by hand.
- An external scan against the final public hostname, with the grade and its notes read — not just screenshot.
- The certificate's renewal path is automated and monitored, so the setup that passed today is still the setup that serves tomorrow.
The tie between 4 and 5 is deliberate. A scan is a point-in-time photograph; renewal automation is what keeps the photograph true. Neither replaces the other, and a checklist that has one without the other is a checklist with a hole in it.
The honest caveat
A grade is a snapshot, not a promise. An A+ today means every client positioned like the tester is well served right now. It does not guarantee the configuration survives the next deploy, the next certificate rotation, or the next server rebuild — which is exactly why the scan is on the checklist when evaluating services, and the automation is what runs between evaluations.
If you run a public service, the same URL pattern works for yours:
Run it, read the notes under the grade, and fix what it flags — that's the point of the exercise. A certificate is table stakes. A configuration that earns its grade is the actual service.