Inspect TLS
Record the negotiated connection
Capture TLS version, cipher, key exchange, peer identity, ALPN, and verification result as evidence.
10 minute lesson
A TLS policy becomes real only in the negotiated connection. You can configure a server for TLS 1.3 and strong ciphers, but what a given client actually gets depends on both sides’ capabilities, their configuration, and any network intermediaries in between. When someone asks “is this connection secure?”, the honest answer is a recording of one specific handshake.
The full s_client output is too noisy for note-taking. Request a concise summary instead:
openssl s_client -brief -connect example.org:443 -servername example.org </dev/null
-brief reduces the output to the facts worth recording:
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = example.org
Hash used: SHA256
Signature type: ECDSA
Verification: OK
Server Temp Key: X25519, 253 bits
Record the protocol, cipher suite, peer certificate, and verification status. Verification: OK is the line that tells you the chain validated; anything else names the failure.
If the service speaks HTTP/2, you can also check which application protocol gets negotiated by offering choices with ALPN:
openssl s_client -brief -alpn h2,http/1.1 -connect example.org:443 -servername example.org </dev/null
An ALPN protocol: h2 line in the output means the server picked HTTP/2 during the handshake.
Now compare. Run the same command against a second service, or force an older protocol with -tls1_2, and put the two summaries side by side. Differences in protocol version or key exchange jump out immediately, and you have concrete evidence for a ticket instead of “it seems fine”.
This habit pays off during incidents. A recorded baseline from last month tells you whether today’s Protocol version: TLSv1.2 is normal for that service or a regression someone introduced.
Do not judge security from the cipher name alone. A strong-sounding cipher suite over a connection whose certificate failed verification protects you from nothing. Identity verification and current protocol policy matter too, which is why the summary records all of them together.
Lesson completed