In the previous article on security I wrote that the little padlock in the address bar is not enough. But one question was left unanswered, and several people asked it: fine, so how do I know whether mine is set up properly?
There is an answer, and it is a grade from A+ down to F. The problem is that almost nobody knows what that grade measures, so people either panic for no reason or relax for no reason. Let us look at how it is produced, what it hides, and which two or three things actually make the difference. I am not going to give you a configuration guide, that is not a job for an article. I am going to give you the vocabulary to understand what the report is telling you.
How the grade is produced
The SSL Labs rating guide is public and its logic is worth knowing. Three weighted categories: protocol support 30%, key exchange 30%, cipher strength 40%. That produces a number from 0 to 100, which becomes a letter: 80 and above an A, 65 and above a B, 50 and above a C, and so on.
Two things, though, overturn the simple arithmetic.
First: a zero in any category pushes the whole score to zero. There is no average to save you. It is an exam with a pass mark in every subject separately.
Second, and the most misunderstood: above the number sits a second layer of rules that lowers or raises the grade regardless of how well you scored. That is where most cases are decided.
The B you should not be settling for
If your site gets a B, there is one very likely cause and it is infuriatingly simple: the server still accepts TLS 1.0 or TLS 1.1. The guide says so outright, capped at B.
Which means you can have a perfect certificate, modern algorithms, everything right, and sit at a B because somebody left open a door nobody walks through any more. And when I say nobody, I mean it literally: browsers closed them years ago.
The history here is interesting, because for once the vendors moved ahead of the standard. On 15 October 2018 Apple, Google, Microsoft and Mozilla jointly announced the removal. Firefox disabled them in version 78, in June 2020. Chrome completed the removal in version 98, in February 2022. The formal standard, RFC 8996, arrived in March 2021, in between, and states without hedging that TLS 1.0 must not be used and that negotiating it must not be permitted.
Why? The RFC explains: the integrity of both versions depends on SHA-1, which permits a downgrade attack by an attacker able to perform 2 to the 77th operations. And it adds something far more human, which I find wise: supporting four TLS versions increases the likelihood of misconfiguration. Complexity is itself a risk.
Other things that cap you at B, from the same guide: support for SSL 3, support for RC4, an incomplete certificate chain, no forward secrecy, no AEAD ciphers. The incomplete chain is perhaps the most insidious, because it usually works perfectly on your own computer and falls over on other devices.
When you drop to F, and why it is usually not the cryptography
An F is not a fine distinction, it is something broken. And if you read the list, you will see that the large category is not about algorithms but about the certificate itself: a name that does not match the domain, expired, self-signed, from an untrusted or revoked authority, signed with MD2 or MD5, with an insecure key.
The rest of the list is known vulnerabilities with names that sound like a pub quiz: Heartbleed, DROWN, ROBOT, Ticketbleed, Zombie POODLE, GOLDENDOODLE. If one of those shows up, we are not discussing grades, we are discussing an urgent update.
The practical conclusion is reassuring, and I say it to clients constantly: an F is usually an administrative mistake, not a technological one. Somebody forgot to renew, or installed a certificate for www and not for the bare domain. It is an hour’s work.
The A+ and the great HSTS misunderstanding
This is the part I wish more people knew.
HSTS does not count towards the numeric grade at all. It enters only at the top: A+ is awarded to servers with a good configuration, no warnings, and HSTS with a max-age of at least six months.
Do you see what that means? A site with an A may perfectly well have no HSTS. And HSTS is not decorative: it is what tells the browser “in this place you always go by https”, and it stops the user clicking past a certificate error with “proceed anyway”. In other words it protects at exactly the moment the user is in a hurry.
So next time somebody shows you an A and looks pleased, the right question is: “lovely, do we have HSTS?”
Preload, and the door that locks from the inside
There is a further step, preload: you get onto a list that ships inside the browsers themselves, so you are protected even on a user’s very first visit.
The requirements are four: a valid certificate, a redirect from http to https on the same host, all your subdomains over https, and an HSTS header with a max-age of at least one year, plus includeSubDomains and preload.
And now the warning, written by the service itself, which I would like you to read twice: inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for the change to reach users through a browser update, and no guarantees are given for other browsers.
Translation: if tomorrow you need a subdomain on http for some machine, an old system, a device in the office, you will not be able to. Preload is excellent and I recommend it, but only after we are sure the whole house, basement included, is on https. Not because it is difficult, but because it is close to irreversible.
Certificates are living shorter lives, and it concerns you
This is the change that will knock on doors this year, and very few have noticed it.
The CA/Browser Forum, in ballot SC-081v3 adopted in April 2025, set a schedule for reducing maximum certificate validity:
| From | Maximum validity |
|---|---|
| Previously | 398 days |
| 15 March 2026 | 200 days |
| 15 March 2027 | 100 days |
| 15 March 2029 | 47 days |
The first row is already in force. And the practical conclusion is singular: manual renewal is over. Anyone who set a calendar reminder once a year will be setting it twice this year, three times next year and eight times in 2029. It cannot be done by hand, and it should not be.
Let’s Encrypt moves in the same direction, having always issued 90 days anyway. Since January 2025 it also offers six-day certificates as an additional option, and has stated it intends to bring its own maximum down to 45 days by February 2028. A six-day certificate without automation does not even exist as a thought.
A correction, for a tool that moved house
Since I have recommended it myself in the past, I will correct it publicly: Mozilla’s SSL configuration generator is no longer hosted by Mozilla. The repository is archived and the code continues as a community project, at configurator.tlsref.org.
And there is a substantive change: there are no longer three levels. There are two, Modern and Intermediate. Modern targets clients that support TLS 1.3 and only TLS 1.3. Intermediate, which is the recommended default for almost all systems, gives TLS 1.2 and 1.3.
Notice what that means: neither option includes TLS 1.0 or 1.1. Not even the compatible one. So if your provider keeps them open “for compatibility”, they are not being conservative, they are out of date.
Mixed content, as it stands today
We used to learn about “active” and “passive” mixed content. MDN has now changed the language, and the new one is more useful: there is upgradable and blockable content.
Upgradable, meaning images, audio and video, the browser lifts from http to https by itself. Blockable, meaning scripts, stylesheets, iframes, fetch calls and fonts, is rejected outright.
And a detail that costs anyone who does not know it: an image with srcset or inside a <picture> is not upgradable, it is blockable. Which is to say, exactly the modern responsive images we recommend everywhere, if they point at http, do not get upgraded, they disappear.
And the sentence we should finally stop saying
“Put SSL on so you rank higher in Google.” I still hear it, and it was once correct. Google did announce HTTPS as a ranking signal in 2014.
Today, though, its page experience documentation says something different: that Core Web Vitals are used by its ranking systems, but that beyond those, the other page experience aspects do not directly help your website rank higher. It adds that Google always seeks to show the most relevant content, even where the page experience is sub-par.
That does not mean “skip HTTPS”, obviously. It means you put it in for the right reason: because without it the browser writes “not secure” next to your name and your forms travel in the open. Not to gain positions.
What we actually do
The same thing we did on mswriter.eu, where the security headers went from 1 out of 7 to 7 out of 7, grade A+. It is not heroic, it is methodical: close the old protocols, fix the chain, set HSTS with a sensible duration, set up automatic renewal so that the 100-day and later 47-day schedule stops being our problem, and check again.
Which brings us back to the question that opened the article: how do you know whether yours is set up properly. Now you know what to look at, and above all you know that an A without HSTS is not what you thought it was. If you would like to go through it together, with measurement instead of impressions, get in touch.