Your site shows the padlock in the browser, so "it is already secure". It is the sentence we hear most and the most misleading. The padlock only says a valid certificate exists for that domain: it says nothing about which protocol versions you accept, which ciphers you negotiate, whether the chain is complete or when it expires. That is why analysis tools give a grade, from A+ to F, and why two sites with a padlock can sit at opposite ends. This guide explains what each part of that grade measures, what a reasonable configuration looks like in 2026 and how to check yours with two commands.
What a TLS grade evaluates
Serious tools combine seven checks. The first two are eliminatory: if they fail, the grade drops to F without looking at the rest.
- Valid certificate: issued by a recognized authority, for the right domain, within its validity period.
- Complete chain: the intermediate certificate linking yours to the root authority is sent along with it.
- Protocol versions: which TLS versions you accept and which you reject.
- Ciphers: which algorithms you offer and in what order.
- Redirect: whether HTTP leads to HTTPS across the whole site.
- HSTS: whether you tell the browser never to use HTTP again.
- Known vulnerabilities: insecure renegotiation, compression, the named attacks of the last decade.
Versions: only 1.2 and 1.3
TLS 1.0 and 1.1 have been deprecated since 2020 and browsers reject them. If your server still accepts them, the grade drops because an attacker can force an old client to use them. TLS 1.2 is the acceptable minimum; TLS 1.3 is the current standard: fewer round trips when connecting, modern ciphers mandatory and none of the insecure options of earlier versions. The right configuration today is to accept 1.2 and 1.3 and nothing else. If you use Vercel, Netlify, Cloudflare or managed hosting, this is already the case; if you run your own nginx or a load balancer, check it.
Ciphers: what really matters
The cipher defines how the key is exchanged and how the traffic is protected. Two things make the difference. The first is perfect forward secrecy (the ciphers starting with ECDHE): if someone steals your private key in the future, they cannot decrypt the traffic they recorded before. The second is avoiding broken or weak algorithms: RC4, 3DES, the old CBC modes and plain RSA key exchange. A reasonable list for TLS 1.2 comes down to ECDHE with AES-GCM or ChaCha20; in TLS 1.3 the protocol only allows modern ciphers anyway, another reason to enable it.
The certificate chain: the invisible failure
Your certificate is signed by an intermediate, and the intermediate is signed by a root that devices already know. The server has to send your certificate and the intermediate. If you forget the intermediate, desktop Chrome downloads it on its own and you will see no error; but many phones, curl, AI bots and payment integrations fail with an "untrusted certificate". It is the most common failure on hand-configured servers and the hardest to notice because "it works for me". Check it like this:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | grep -E "s:|i:|Verify return"At least two certificates must appear in the chain and verification must end with Verify return code: 0 (ok).
Domain and alternative names
The certificate has to cover exactly the names you use: yourdomain.com and www.yourdomain.com are two different names. A certificate for the root only makes www error out, and vice versa. Current certificates list several names in the SAN field, and wildcards (*.yourdomain.com) cover one level of subdomains. Also review the forgotten subdomains: api, app, staging with expired certificates are a classic.
Expiry: shorter and shorter
Let's Encrypt certificates last 90 days, the maximum browsers allow today is 398 and the industry has agreed to lower it progressively to 47 days by 2029. The message is clear: renewal has to be automatic. Managed platforms do it on their own; if you have your own server, use an ACME client with scheduled renewal and, above all, an external alert that warns you when fewer than 14 days remain. The outage from an expired certificate is the silliest and the most frequent.
Redirect and HSTS
All HTTP traffic has to redirect to HTTPS with a 301, on every route, not just the home page. And once everything works over HTTPS, the Strict-Transport-Security header tells the browser not to try HTTP again for the time you specify, which removes the small gap of the first request. With includeSubDomains and preload you can include your domain in the list browsers ship with. It is the usual difference between an A and an A+. How to configure it, in HTTP security headers.
Mixed content
A detail that does not affect the certificate grade but does affect the padlock: if your HTTPS page loads an image, a script or a font over HTTP, the browser blocks it or marks the page as not secure. It usually comes from URLs copied from an old template. Search the source for http:// and change it to relative paths or HTTPS.
If you are on a managed platform
Vercel, Netlify, Cloudflare Pages, Railway or Render issue and renew the certificate, enforce modern versions and pick secure ciphers. You do not have to touch any of that. What is still yours: adding HSTS, removing mixed content, redirecting alternative domains and watching the subdomains that point to other places.
Why it matters beyond the grade
Weak TLS allows session interception on public networks, and a misconfigured certificate makes your site fail on devices you do not see. Payment processors require TLS 1.2 at minimum to comply with PCI DSS. Google uses HTTPS as a ranking signal and browsers mark anything without it as "not secure". And, more mundanely, a certificate that expires on a Saturday morning is a site that is down until someone notices.
Check it in thirty seconds
curl -sIL http://yourdomain.com | grep -iE "^(HTTP|location|strict-transport)"
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_1 </dev/null 2>&1 | grep -iE "alert|error" | head -1The first should show a 301 to https:// and then the HSTS header. The second tries to connect with TLS 1.1 and must fail: if it connects, you accept a deprecated version.
Scanaris reviews your TLS on every scan
Scanaris checks protocol versions, ciphers, complete chain, certificate names, days until expiry, redirect and HSTS, and emails you before the certificate expires. Every finding comes with a fix prompt with the exact configuration for your server or platform. These are read-only checks: it connects to your site the same way a browser would. To see everything it reviews in thirty seconds, read how to know if your site is secure in 5 minutes.
Frequently asked questions
What is the difference between SSL and TLS?
SSL is the old name of the protocol, retired years ago as insecure. What is used today is TLS, but people still say "SSL certificate". For practical purposes, when you read SSL think TLS.
Do I need a paid certificate?
No. Free certificates from Let's Encrypt or the ones your platform issues encrypt exactly the same. Paid ones add organization validation or warranties, not more security in the connection.
Why do I get a B if my certificate is valid?
Usually for accepting TLS 1.0 or 1.1, offering weak ciphers or not sending the HSTS header. The certificate is only one of the seven things that are looked at.