LEARN. PRACTICE. GROW.Concept and mechanism
A tool can have different objectives from a production client. OpenSSL s_client is a diagnostic tool that can continue after verification errors to make them visible. A completed handshake does not erase those errors. Configure the test with appropriate trust and reference name, using failure behavior such as -verify_return_error when that is the criterion. -showcerts shows sent certificates without guaranteeing they form a validated chain. For offline verification, an approved root can provide the anchor while -untrusted supplies supporting intermediate material. The option name does not mean the certificate is malicious; it means supplying it does not grant trust.
Guided application
Reproduce the affected client context: TLS library, trust store, name, version, and configuration can differ from the operator laptop. Compare certificates and results without collecting private keys for reports. In an exercise, a report declares success despite unknown CA and no hostname check. Correct the criterion and repeat the defined observation before accepting change. After restoring TLS, validate authorization and business operation on relevant instances. Course examples are illustrative and use OpenSSL 3.5 documentation; no TLS commands, key generation, issuance, or labs were executed. Real application requires checking options and behavior of the installed version.
A connection with s_client verification errors needs analysis even when the tool continues.
Common pitfalls
showcerts as a validated chain; diagnostic output as acceptance; laptop trust store as universal; handshake as completed operation.
Related topics: Keys, certificates, and trust · Identity, name, and time · Negotiation, mTLS, and the application
Define what the test proves, establish context, and validate the business outcome.
Reference: OpenSSL diagnostic TLS client · DR TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics