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

Run on the authorized diagnostic host or disposable lab VM. Compare the installed OS and required packages below with the selected path. Obtain missing tools from the distribution’s enabled official repositories through your approved package-management process; this workflow does not reinstall an existing server or switch its repository.

Use an entitled RHEL repository or the matching official Rocky Linux/AlmaLinux repositories and a currently supported minor release. SELinux and system crypto policy remain enforced; do not weaken them to make a diagnostic pass.

The selected CA-bundle field makes the distribution trust input explicit for online probes: Debian/Ubuntu use the bundle under /etc/ssl; Red Hat-family systems use /etc/pki. Record curl’s actual TLS backend and the affected application’s trust configuration; Java and containers may use another store.

Inspect the curl executable and its owning package; a valid curl-minimal installation need not be replaced by full curl. Confirm HTTP/HTTPS support in the installed build’s version output.

cat /etc/os-release
rpm -q openssl ca-certificates coreutils
command -v openssl curl timeout
stat -c '%A %U %G %n' '/etc/pki/tls/certs/ca-bundle.crt'
if command -v curl >/dev/null 2>&1; then
  rpm -qf "$(command -v curl)"
else
  printf '%s\n' 'Required curl executable is missing.'
  exit 1
fi

Run on the affected Linux workstation. Record the OpenSSL build, system time and curl TLS backend. Different clients may use different trust stores, proxies or validation rules. An obsolete trust bundle and an incorrect clock can mimic a server-chain problem; do not change the system clock merely to make an expired certificate appear valid.

date -u +'%Y-%m-%dT%H:%M:%SZ'
openssl version -a
curl --version

Connect to the chosen IP while sending the actual DNS name as SNI and as the verification identity. The verification-return-error option matters: s_client can otherwise continue after a verification failure. The external timeout bounds the diagnostic. Inspect the verification result and process status rather than treating any printed certificate as success.

This online probe explicitly selects the reviewed CA file; compare the affected application and the isolated offline trust test separately when stores disagree.

timeout 15 openssl s_client -connect '203.0.113.10:443' -servername 'app.example.com' -verify_hostname 'app.example.com' -CAfile '/etc/pki/tls/certs/ca-bundle.crt' -verify_return_error -brief </dev/null
printf 's_client exit=%s\n' "$?"

This curl probe sends the right Host and SNI and verifies against curl’s configured trust. It bypasses ordinary DNS for one destination without editing hosts files or disabling verification. Use the same TLS port in both resolve mapping and URL. A 401 or 403 still means HTTP was reached; it is not an authentication acceptance test.

curl --cacert '/etc/pki/tls/certs/ca-bundle.crt' --noproxy '*' --resolve 'app.example.com:443:203.0.113.10' --connect-timeout 3 --max-time 15 -sS -o /dev/null -w 'HTTP %{http_code} TLSverify=%{ssl_verify_result}\n' 'https://app.example.com:443/'

Run this read-only handshake to display the public certificates transmitted by the endpoint. The displayed list is not a verified chain. A server normally sends its leaf and required intermediate certificates; a trusted root usually belongs in the client store and need not be sent. A browser can hide a missing intermediate through cached or fetched issuer material, while a clean API client fails.

timeout 15 openssl s_client -connect '203.0.113.10:443' -servername 'app.example.com' -showcerts </dev/null