TLS certificates, trust, and handshake inspection

Mechanism

TLS negotiates an encrypted connection and authenticates peers according to certificate and verification policy. A certificate chain, hostname match, protocol version, and application trust store are separate checks. Encryption without verifying the intended peer does not establish a trustworthy endpoint. Server name indication can select a different virtual host or certificate.

Practical method

Inspect the handshake with the intended hostname and port. Record negotiated protocol, certificate chain, names, and expiry. Verify against the appropriate trust store rather than simply observing a successful encrypted connection. Compare behavior with and without the intended SNI value.

openssl s_client -connect lab.example:443 -servername lab.example \
  -verify_hostname lab.example -verify_return_error

Interpreting evidence

A handshake transcript shows what was negotiated, not whether the application uses the same verification settings. Preserve the validation outcome and the relevant chain details.

Pitfalls and limits

Self-signed certificates may be deliberate lab configuration. Ignoring validation errors changes the security claim. TLS interception and enterprise roots can produce a valid chain under a different trust policy.