Wiunix
Talk to an Engineer
← Start of tutorial

WIUNIX ACADEMY

TLS works in one client but fails in another: chain and SNI diagnosis

Page 2 of 2. Review the earlier steps and prerequisites before continuing.

YOUR SYSTEM. YOUR STEPS.

Where are you working?

Choose your OS and version. The prerequisites, commands and troubleshooting follow your environment.

Red Hat Enterprise Linux 9Reviewed against official documentation ·

USE YOUR OWN VALUES

Configure this tutorial

Set the example values for your environment; related explanations and copy panels update together. Never enter passwords, private keys or tokens. Values stay in this tab and are not sent to the server or share links. Check actual DNS, certificates and network policy before running commands.

Different IP addresses, domains or ports? Open the settings below, change the values and select “Apply to tutorial”, then copy the updated commands.

Set values for my environment4 editable values
06

LET’S BUILD

Read the selected leaf identity and lifetime

This pipeline extracts public leaf metadata for the selected SNI. Pipefail prevents a failed producer from being hidden by a successful consumer. Compare SANs, issuer, validity and SHA256 fingerprint with the intended deployment. A matching common name alone is not a substitute for hostname verification.

bash

Authorized Linux terminal

set -o pipefail
timeout 15 openssl s_client -connect '203.0.113.10:443' -servername 'app.example.com' -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName -fingerprint -sha256
How do I know it worked?

The actual served leaf has the expected SAN and valid dates; fingerprint differences across nodes trigger per-node comparison.

07

LET’S BUILD

Use a no-SNI comparison only to identify virtual-host selection

If the strict named probe succeeds but a legacy client fails, compare the no-SNI leaf. This intentionally omits SNI and does not verify a hostname, so it is diagnostic output only. A different default certificate can explain an older client’s failure; the repair is correct client SNI or a deliberate supported endpoint, not accepting the wrong certificate.

bash

Authorized Linux terminal

set -o pipefail
timeout 15 openssl s_client -connect '203.0.113.10:443' -noservername -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -fingerprint -sha256
How do I know it worked?

A different default leaf explains selection behavior; it does not authorize disabling verification.

08

LET’S BUILD

Interpret stapling in the context of the issuing CA

Request a stapled OCSP response, but do not fail every deployment merely because none is supplied. Let’s Encrypt ended OCSP service in2025 and removed OCSP URLs from newly issued certificates; older blanket advice to enable stapling for every certificate is stale. Stapling status alone does not prove revocation freshness, full chain validity or every browser’s policy. Inspect the leaf extensions and actual CA documentation, including CRLs and any TLS Feature requirement.

bash

Authorized Linux terminal

timeout 15 openssl s_client -connect '203.0.113.10:443' -servername 'app.example.com' -status -verify_hostname 'app.example.com' -verify_return_error </dev/null
How do I know it worked?

Record the stapling observation separately from the strict trust/name result and the CA’s actual revocation mechanism.

09

LET’S BUILD

Validate a known public chain offline when necessary

For a private PKI or a controlled comparison, obtain the leaf, intermediates and approved root bundle through your authenticated certificate-management channel. The filenames below are public certificate files in a new review directory, never private keys. This command tests the chosen material and explicit root, not what an endpoint currently serves. Do not promote an intermediate or a server leaf to a trust anchor to silence a failure.

For this controlled comparison, the trusted option disables the default CA file/path/store and uses only the supplied approved root bundle; it does not install that trust system-wide.

bash

Authorized Linux terminal

openssl verify -purpose sslserver -verify_hostname 'app.example.com' -trusted approved-roots.pem -untrusted intermediates.pem leaf.pem
How do I know it worked?

An OK result applies to the explicit input chain and root bundle; repeat the live strict probe after any approved server correction.

Repair the owning layer and repeat from a clean client

A wrong leaf calls for correct vhost/SNI binding or issuance; a missing intermediate calls for the proper server chain; an old client trust store calls for a supported update; an expired leaf calls for renewal and successful installation. Use the existing certificate/deployment procedure with its before copies. These read-only diagnostics need no rollback. If a change fails, restore the exact previously valid bundle and binding, not a bypass flag. Never upload private keys into a diagnostic website.

Acceptance is a matrix, not a green padlock

Repeat the strict named probe for every serving node and address family used by clients, then test the affected application’s actual TLS library with its supported trust. Record SNI, SAN, chain, expiry, trust-store version and fingerprint. This documented guide does not claim hands-on testing of all TLS clients, browser revocation behavior or your custom endpoint.

GO TO THE SOURCE

Official references

Each environment states how it was reviewed. A documentation review does not claim a hands-on test of every version.

Explore all tutorials ↗