TLS & Certificates
Most important commands to remember
openssl s_client— inspect a TLS connection and verification.curl -I https://…— test HTTPS metadata with normal certificate checking.
Commands and flags
| Option or syntax | Meaning |
|---|---|
timeout 10 |
Bound the diagnostic process to ten seconds. |
-connect example.com:443 |
Choose the network host and TCP port. |
-servername example.com |
Send the intended name using TLS SNI. |
-verify_hostname example.com / -verify_return_error |
Check the certificate name / fail the handshake on verification errors. |
-brief |
Print a compact connection summary. |
< /dev/null |
Supply end-of-input instead of interactive application data. |
curl -I --max-time 10 |
Request HTTP HEAD with a ten-second limit. |
SNI selects a server identity; it is not itself a certificate verification step.
The concepts that matter
1. TLS protects a connection
Transport Layer Security (TLS) establishes keys and protects application data against eavesdropping and undetected modification on that connection. Modern HTTPS uses TLS around HTTP traffic.
The handshake negotiates parameters and authenticates the server when verification is performed. Data is then protected with symmetric cryptography. TLS does not mean the server is honest, the application is bug-free, or the requesting user is authorized.
2. A certificate binds an identity to a public key
A server certificate associates a public key with names and other constraints. The server demonstrates possession of the corresponding private key during authentication. The certificate itself is public; the private key must remain private.
Name checking asks whether the certificate covers the hostname the client intended to reach. Connecting to an IP address while sending a different SNI name does not automatically make any returned certificate valid for your request.
3. Trust requires more than reading the subject
The client builds and validates a chain to a trusted certificate authority according to its trust configuration. Validity dates, names, signatures, and applicable constraints all matter. A certificate displayed by a diagnostic tool has not necessarily passed these checks.
A self-signed certificate can be appropriate in a controlled trust setup, but merely trusting anything that answers defeats authentication. Clock errors and missing intermediate certificates can also cause failures even when traffic reaches the server.
4. Each TLS leg has its own boundary
A reverse proxy can terminate one TLS connection and create another toward a backend. Verification and encryption on the first leg do not automatically protect the second. Certificates also expire and rotate independently of application deployments.
Separate DNS resolution, TCP connection, TLS verification, and HTTP response when diagnosing a failure. A completed handshake proves a narrower property than a successful request, while an HTTP error can arrive over a perfectly valid TLS connection.
One small example
Optional: run the commands from a Linux terminal. They contact the public example domain without disabling certificate verification.
timeout 10 openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -brief < /dev/null
curl -I --max-time 10 https://example.com/In the OpenSSL summary, inspect protocol version, negotiated cipher, peer identity, and verification result. The command explicitly enables hostname checking and makes verification errors fatal; SNI alone would not do that.
The curl request goes one layer further and asks for HTTP headers. Status and TLS details vary with the endpoint and local trust store. An EOF-related message after successful negotiation can reflect closing this diagnostic connection, so distinguish it from a certificate verification error.
The timeout bounds a stalled diagnostic. No keys or trust entries are created, and no cleanup is needed.
Keep this idea: TLS protects a connection only when you authenticate the intended peer; a valid handshake is not application authorization.