Checking a served TLS certificate chain and its expiry from the command line with openssl

Goal

Answer, for one hostname, three questions a browser answers silently: which certificates does the server send, do they form a chain a client can verify, and when does each expire. This is the one-off diagnostic; scheduled alerting is a separate article.

Prerequisites

An openssl binary, network access to the host, and the exact hostnames clients use (apex, www, API hosts), because the server may pick a different certificate per name.

Steps

1. Fetch what the server sends, with SNI set explicitly: openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null > sent.txt. The manual states that -showcerts displays the server certificate list as sent, in the order sent, and that this list is not a verified chain. It also states that without -servername the SNI is filled from the -connect name only if that looks like a DNS name, so pass it when connecting to an IP address.
2. Read the verification outcome that s_client prints after the handshake; a chain that verifies locally still needs step 4, because the local trust store may hold an intermediate that clients lack.
3. Split sent.txt into one PEM file per certificate and inspect each: openssl x509 -in cert1.pem -noout -subject -issuer -enddate -ext subjectAltName. Per the manual, -enddate prints the notAfter date and -ext prints named extensions such as subjectAltName. The first certificate should be the leaf whose SANs contain the hostname; each following certificate should be the issuer of the previous one.
4. Rebuild the chain independently of what the server claims: openssl verify -show_chain -untrusted intermediates.pem leaf.pem. The manual describes -untrusted as a file of untrusted certificates used for chain building and -show_chain as displaying the chain that was built, with untrusted members flagged. Run it against the system trust store and, if needed, against a specific -CAfile.
5. Repeat step 1 with -4 and again with -6; the manual documents these as IPv4-only and IPv6-only connections. A load balancer may serve a different certificate per address family.
6. Repeat for every hostname and every port that terminates TLS.
7. Record hostname, address family, leaf notAfter, earliest intermediate notAfter and verification result in a table.

Expected result

A short table per hostname showing that the sent chain is complete and ordered, that verification succeeds without the local trust store papering over a missing intermediate, and the earliest expiry in the chain.

Limits and test basis

A missing intermediate can pass on a machine that has cached it and fail on a fresh client; step 4 with a minimal trust store is the honest test. Commands follow the cited manuals; option availability varies by OpenSSL version. No field results are claimed.