TLS Configuration, Read Properly: Protocols, Ciphers and Negotiation
Every secure connection begins with a negotiation that most users never see. The browser and the server agree on a protocol version, a cipher suite, and a set of extensions, and the security of everything that follows depends on that agreement. A TLS configuration checker exists to make that agreement visible, because a server's configuration is a list of options, and the options a server offers determine the worst connection it will accept, not just the best. The SSL/TLS Configuration Checker examines a configuration summary you paste in, together with the pasted certificate, and reports which options are current, which are outdated, and which should be removed, so tightening becomes a planned change rather than a guess.
TLS, Transport Layer Security, is the successor to SSL, and although people still say SSL out of habit, every modern secure connection uses TLS. The current versions are TLS 1.3, published in 2018, and TLS 1.2, published in 2008 and still widely used. Earlier versions, TLS 1.1, TLS 1.0, and the SSL versions before them, contain known flaws and are considered obsolete. A cipher suite is the package of algorithms for a session: a key exchange method that establishes shared secrets, an encryption algorithm that protects the data, and a message authentication method that detects tampering. TLS 1.3 simplified this picture by removing many older options and defining a small set of strong suites, which is one reason it is preferred wherever both sides support it.
How it works
Checking a pasted configuration summary means reading the offered options as an attacker or an old client would see them. The checker lists the enabled protocol versions and flags any below TLS 1.2. It lists the cipher suites and groups them: strong suites with forward secrecy and modern encryption, acceptable suites that are safe but not ideal, and weak suites that use obsolete encryption, short keys, or no authentication. Forward secrecy deserves emphasis, because it is the property that protects past sessions if a server's long-term key is later compromised: with forward-secret key exchange, each session uses fresh keys that cannot be reconstructed from the long-term key, so a later compromise does not expose earlier traffic. Suites without forward secrecy lack that protection, and their continued presence is a finding even if no attack is currently known against them.
The checker also examines the configuration details that surround negotiation. Certificate details, such as key size and signature algorithm, are checked, because a modern protocol cannot compensate for a weak certificate key. Session resumption settings, compression settings, and renegotiation behaviour are noted where the summary includes them, because each has a history of flaws when misconfigured: compression of encrypted data can leak information, and insecure renegotiation can allow an attacker to inject data into a session. The output is a prioritised list, with obsolete protocols and unauthenticated suites first, weak ciphers next, and hardening opportunities, such as preferring server cipher order so the server's choice prevails over a client's weak preference, listed last.
Worked example
Consider a sample configuration summary with sample values for illustration. The server enables TLS 1.2 and TLS 1.3, prefers its own cipher order, and offers six cipher suites: four with forward secrecy and modern encryption, one without forward secrecy, and one using an obsolete encryption algorithm. The certificate uses a 2048-bit key and a modern signature algorithm, and the server disables compression. A checker would report two findings: the non-forward-secret suite should be removed when clients allow, and the obsolete-encryption suite should be removed promptly, because it offers an attacker a weak option to target.
The remediation order shows the checker's practical value. Removing the obsolete suite first is low risk, because no modern client will choose it when stronger suites are available, and it immediately removes the weakest option. Removing the non-forward-secret suite second requires a check of the client base, because some older clients may rely on it, but once those clients are upgraded or moved, removal is safe. Enabling server cipher order, already present in this example, ensures the server's preference for strong suites wins even when a client lists weak suites first, which is why that setting is recommended wherever it is available. These are sample values for illustration, and the pattern they show, remove the weakest option first, verify the client impact, then remove the next, is the safe way to tighten any configuration.
Mistakes to avoid
The most common mistake is tightening everything at once without testing, which produces an outage whose cause is unclear because several changes landed together. Change one thing at a time, test against the real client base, and keep a rollback note. A second mistake is the opposite: never tightening at all, because an old client might break. Old clients should be inventoried and upgraded or isolated, not allowed to hold the whole configuration hostage indefinitely, because every month of delay is a month in which the weak option remains available to attackers too. A third mistake is checking only the main domain. Staging servers, APIs, and legacy subdomains often run older configurations with weaker options, and attackers will find them, so check every endpoint that shares credentials or cookies with the main site.
A fourth mistake is confusing the certificate with the configuration. A new certificate does not fix a weak cipher list, and a strong cipher list does not fix an expired certificate, so both must be checked, and a renewal is a good moment to check both together. Finally, the handling rule: a configuration checker works from pasted summaries and certificate text, which are not secret, but it never needs private keys, passwords, or internal addresses. Never paste those into a checker, and treat any exposed private key as compromised, replacing the certificate and key.
Putting it into practice
Add configuration checking to server setup, software upgrades, and certificate renewals, and re-check at least annually, because the definition of current practice moves as flaws are found and versions age. Keep a short record of the enabled protocols and suites after each change, so the next check can be compared and a regression, such as an upgrade resetting defaults, becomes visible immediately. For neighbouring checks, the HTTP Headers Checker covers the headers that complement TLS, and the DNSSEC Checker covers the DNS-side integrity that protects the first step of reaching the server. For background reading, the related guide explains DNS integrity, which pairs with TLS configuration to protect both the lookup and the connection.
Key points
- TLS negotiation picks the strongest option both sides support, so the weakest offered option matters
- TLS 1.2 and TLS 1.3 are current, and earlier versions should be disabled
- Prefer forward-secret suites and server cipher order, and remove obsolete suites one at a time
- Check every endpoint and re-check after upgrades, never pasting private keys into a checker