Verifiedapp Blog
TLS/SSL

Is my SSL/TLS actually secure? A plain-English checklist

· 2 min read
#certificates#ciphers#https#tls-ssl

The padlock is not the answer

The padlock means traffic is encrypted. It does not tell you whether the encryption is modern or ancient, whether your certificate is healthy, or whether an attacker could force a weak connection. A site can show a perfect padlock and still accept protocols and ciphers that were broken years ago. Real TLS security has three layers — here is how to check each in plain English.

1. Protocols: what versions do you accept?

TLS has versions, and the old ones are broken. You want to accept only the current ones and refuse the rest:

  • Disable SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1. These have known, practical attacks and are formally deprecated.
  • Keep TLS 1.2 and TLS 1.3. TLS 1.3 is the newest — faster and with the weak options removed by design.

Accepting an old protocol matters even if modern browsers prefer a new one, because an attacker can try to force the connection down to the weakest version you allow.

2. Ciphers: how strong is the encryption?

Within a protocol, the cipher suite is the actual algorithm doing the work. Several are weak and should not be offered:

  • Avoid RC4, DES, 3DES, NULL, anonymous and export-grade ciphers — all have practical weaknesses.
  • Prefer forward secrecy (cipher suites using ECDHE). Forward secrecy means that even if your private key is compromised later, past recorded traffic stays unreadable. Without it, one stolen key can retroactively decrypt everything.

3. Certificate: is it healthy?

The certificate is what proves you are you. Check that it is:

  • Valid and not expiring soon — an expired certificate breaks the site and erodes trust; automate renewal so it never lapses.
  • Matching the hostname — the name on the certificate must cover the domain serving it.
  • Backed by a complete chain — missing intermediate certificates cause failures for some clients even when it works in your browser.
  • Using a strong key and signature — no 1024-bit RSA, no SHA-1 or MD5 signatures.

Why you cannot eyeball this

Every one of these lives in the TLS handshake, not the page. Your browser negotiates the best option you offer and shows a padlock — it never tells you about the weak options you also accept, or that your chain is incomplete for other clients. That is exactly the blind spot a scan fills.

Check your TLS

An automated scan performs the handshake the way different clients would, enumerates the protocols and ciphers you actually accept, and inspects your certificate and chain — then flags anything weak, expiring or misconfigured. Scan your site and find out whether your padlock is hiding a soft interior.

Related reading

FAQ

Does a valid certificate mean my TLS is secure?
Not necessarily. A valid certificate proves identity, but your server can still accept outdated protocols like TLS 1.0 or weak ciphers like RC4 alongside it. Security depends on the protocols and ciphers you accept, not just the certificate.
Why does it matter if I accept an old protocol that browsers do not use?
Because an attacker can attempt a downgrade, forcing the connection to the weakest version you still allow. If you accept TLS 1.0, that becomes a target — so the fix is to refuse the old versions entirely, not just prefer the new ones.
What is forward secrecy and why should I care?
Forward secrecy (from ECDHE cipher suites) means each session uses a unique key, so even if your private key is stolen later, previously recorded traffic cannot be decrypted. Without it, one compromised key can unlock all your past sessions.

Keep reading