Beyond the Padlock: What an SSL Security Check Actually Examines
A padlock in the browser tells a visitor that the connection is encrypted, but it says very little about how well it is encrypted. Two sites can both show a padlock while differing greatly in security: one may support only modern protocols with strong ciphers and forward secrecy, while the other also accepts obsolete protocols, weak ciphers, and configurations that leak information. An SSL security check looks past the padlock at the choices behind it, and it is worth doing because attackers do not attack the padlock icon; they attack the weakest option a server is willing to accept. The SSL Security Checker examines a pasted certificate and a configuration summary you supply, reporting the weak points in plain terms so they can be fixed deliberately rather than discovered by an incident.
Security configuration is a negotiation. When a browser connects, the server and the browser agree on a protocol version, such as TLS 1.2 or TLS 1.3, and a cipher suite, which is the combination of key exchange, encryption, and integrity algorithms for the session. The server offers a list of options, and the browser picks the strongest it supports from that list. The security of the connection therefore depends on the weakest option the server is willing to offer, because an attacker who can influence the negotiation, or a client that only supports old options, will end up with that weakest option. A server that still offers SSL 3.0 or TLS 1.0 for the sake of very old clients is offering protocols with known flaws, and a server that offers weak ciphers, such as those using short keys or obsolete encryption, is offering sessions that can be attacked with feasible effort.
How it works
A security check works from the material you supply: the pasted certificate text, and a summary of the server's protocol and cipher configuration, such as the list of enabled protocols and cipher suites. It checks each element against current practice. Protocol versions are graded first: TLS 1.3 and TLS 1.2 are current, TLS 1.1 and below are obsolete and should be disabled, and SSL versions should never be enabled. Cipher suites are graded next: suites offering forward secrecy, where the session keys cannot be recovered later even if the server's long-term key is compromised, are preferred, while suites without forward secrecy, suites using weak encryption, and anonymous suites that offer no authentication at all are flagged. Key sizes and signature algorithms from the certificate are graded too, since a strong protocol with a weak certificate key is still weak.
The check also covers the supporting configuration that surrounds the connection. HTTP Strict Transport Security, a header that tells browsers to use HTTPS for the site in future, is checked for presence and duration, because without it a visitor's first visit can be downgraded to plain HTTP. Certificate details such as expiry, name coverage, and chain completeness are included, because a perfectly configured protocol cannot rescue an expired or mismatched certificate. The result is a list of findings ordered by severity, not a single score to chase, because a single score hides which finding matters most, whereas a list lets a team fix the critical items first and schedule the rest.
Worked example
Consider a sample configuration summary with sample values for illustration. The server enables TLS 1.2 and TLS 1.3, which is good, but it also enables TLS 1.0 for compatibility with an old internal system. Its cipher list includes strong forward-secret suites, but it also includes two suites without forward secrecy and one suite using an obsolete encryption algorithm. Its certificate is current and covers the right names, but the site does not send a Strict Transport Security header. A security check would report four findings in rough severity order: the obsolete protocol, the weak cipher suites, the missing header, and, as a note, the presence of non-forward-secret suites that should be removed once the old system is upgraded.
Fixing them in order shows why severity ordering matters. Disabling TLS 1.0 breaks the old internal system immediately, so that fix needs coordination: upgrade the old system first, or move it to a separate endpoint, then disable the protocol. Removing the weak cipher suites is usually safe, because modern browsers will negotiate the strong suites that remain, but it should be tested against the site's real visitor base before deployment. Adding the Strict Transport Security header is low risk and high value, but it should be added with a short duration first and increased gradually, because a long duration header deployed in error can force browsers to HTTPS for a site that is not ready. Each fix has a different risk profile, and the checker's list lets the team sequence them sensibly instead of applying all of them at once and debugging the combined result.
Mistakes to avoid
The most common mistake is chasing a perfect score instead of fixing real findings. A configuration can score well while retaining one critical flaw, or score modestly while being safe in practice, because scoring weights differ between checkers. Fix findings by severity and by exploitability, not by points. A second mistake is disabling old protocols without checking who still uses them. Internal systems, old devices, and partner integrations often depend on the very protocols being removed, and breaking them without warning creates an outage that undoes the security gain. Inventory clients before removing options. A third mistake is configuring security once and never revisiting it. Protocols and ciphers age, new flaws are found, and a configuration that was strong three years ago may be weak today, so re-checking after every server change and at least annually is part of the job.
A fourth mistake is securing the main site and forgetting subdomains, staging servers, and old endpoints, which often run weaker configurations and share cookies or credentials with the main site. Check every public endpoint, not just the homepage. Finally, the handling rule: a security checker works from pasted certificate text and configuration summaries, which are not secret, but it never needs private keys, passwords, or internal network details. Never paste those into a checker, and if a private key has been exposed, replace the certificate and key rather than continuing to rely on them.
Putting it into practice
Run a security check whenever a server is set up, whenever its software is upgraded, and whenever a certificate is renewed, because upgrades can reset configuration to defaults that re-enable weak options. Record the findings and the fixes, so the next check can be compared with the last and regressions become visible. Pair the protocol check with the surrounding checks: the Security Header and DNS Checker for headers and DNS-side protections, and the HTTP Headers Checker for the header set in detail. For background reading, the related guide explains the header protections, including Strict Transport Security, that complement the protocol configuration covered here.
Key points
- The padlock shows encryption exists, not how strong the negotiated options are
- Disable obsolete protocols and weak ciphers, but inventory old clients before removing options
- Forward secrecy and Strict Transport Security are high-value protections, not optional extras
- Re-check after every server change, and never paste private keys into a checker