how to check TLS cipher suites on your server

how to check TLS cipher suites on your server

TL;DR

Run nmap's ssl-enum-ciphers script against your server to list every cipher suite it offers per protocol version. Flag anything weak (RC4, DES, 3DES, NULL, export ciphers), disable those in your server config, and re-scan to confirm. The scan takes seconds and tells you exactly what to change.

how to check TLS cipher suites on your server

Use this when

• A scanner or audit flags weak TLS ciphers on your server
• You hardened the TLS config and want to verify the change took effect
• You are doing a periodic TLS review or pre-compliance check
• You need to know which protocol versions (1.0, 1.1, 1.2, 1.3) are still negotiable

Not for this skill when

• You need a certificate issued or renewed (different task entirely)
• The problem is certificate trust or expiry, not cipher strength
• You want a hosted scan with a graded report (use an online TLS tester for that)

Steps

1. Enumerate cipher suites with nmap

The ssl-enum-ciphers script lists every cipher your server will negotiate, grouped by protocol version.

nmap --script ssl-enum-ciphers -p 443 YOUR_HOST

Expected: a per-protocol listing of cipher suites with strength grades. Anything graded C or worse, or any finding under TLS 1.0 or 1.1, is your fix list.

2. Spot-check protocol versions with openssl

Confirm which protocol versions actually negotiate, independent of the nmap result.

echo | openssl s_client -connect YOUR_HOST:443 -tls1_2

Expected: a successful handshake summary for TLS 1.2. Repeat with the flags for 1.0, 1.1, and 1.3 to map exactly what is on; versions you thought were disabled have a habit of lingering.

3. Identify the weak ciphers to remove

Flag for removal: RC4, single DES, 3DES, NULL and export ciphers, and anything without forward secrecy if your policy requires it. TLS 1.3-only servers sidestep most of this since 1.3 removed the weak primitives.

Expected: a concrete removal list, not a vague "harden TLS" ticket. Write it as cipher names your server config understands.

4. Apply the hardened config and re-scan

Update the cipher list in your web server or load balancer config, reload, and re-run the nmap scan from step 1.

Expected: the weak ciphers gone from the scan output and no client breakage in your logs. Check the logs for handshake failures after the change; an overly aggressive cipher list breaks old but legitimate clients.

5. Recheck on a schedule

Cipher advice rots as primitives age. Re-run the scan quarterly or fold it into your hardening checklist.

Expected: a recurring check, not a one-time event. The next "considered weak" cipher is always coming.

Variant: quick check with testssl.sh

For a deeper audit including historic vulnerability issues and misordered preferences, run testssl.sh against the host. It is slower but more thorough than the nmap script.

Variant: checking a non-standard port

Point both tools at the right port; mail, database, and internal services often run TLS on non-443 ports with ancient configs nobody reviewed.

Why this happens

Servers ship with permissive cipher lists for compatibility, and nobody narrows them until an audit complains. The defaults prioritize "connects everywhere" over "connects securely," so the secure configuration is always an explicit, verified choice.

Edge cases and pitfalls

• Load balancers terminating TLS in front of your server: scan the public endpoint, that is what attackers see.
• SNI-dependent configs: scan with the right hostname, not just the IP, or you test the default vhost.
• Old clients you still support: document which clients need the weaker ciphers before removing them.
• TLS 1.3 cipher suites are configured separately on some servers; check both knobs.
• Scan caching: some CDNs cache aggressively; verify you are testing the live config.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_r3mLAxRAvJwKdxx2HRpHTA