A TLS client must build a valid certificate path to an anchor it already trusts, and verify the requested hostname. Printing certificates is a useful diagnostic, but does not establish either result by itself.

A server-sent leaf and needed intermediates feed client path building. A separately configured trust anchor supplies trust. Requested hostname and certificate validity are additional checks; printing or counting certificates proves none of these alone.
The server supplies certificates; trust comes from the client’s anchor. Validate the path, requested hostname and validity period. Printed certificate counts cannot establish those results.

The leaf is not the whole story

The endpoint presents the leaf first. It contains the public key, validity period, and subject alternative names used for hostname checks. A public-CA deployment normally also sends the intermediates needed to build a path. Missing intermediates can break clients that do not already have them cached or cannot retrieve them.

The self-signed root normally need not be sent: trust comes from the client’s configured anchors, not from a server including a certificate. A cross-signed certificate whose subject says “Root” can instead be an intermediate in the selected path. Certificate count alone is therefore not a completeness or trust test.

Read the chain the edge actually sends

OpenSSL documents s_client -showcerts as the server’s certificate list, not a verified chain. The earlier version of this note recorded this site snapshot:

certificate 0: CN=www.xbcatm.com
    issuer    : C=US, O=Let's Encrypt, CN=YE1
    notAfter  : Nov 19 08:37:12 2026 GMT

certificate 1: CN=YE1 (intermediate)
    issuer    : C=US, O=ISRG, CN=Root YE

certificate 2/3: Root YE / ISRG Root … (CA certificates)

The original report counted four blocks. Its raw handshake log is not retained here, and this review did not reproduce the live handshake; treat the values as a historical report, not current edge evidence. Let’s Encrypt’s chain documentation does describe YE1 and a cross-signed Root YE path, so those names alone are not evidence of an invalid chain. Which certificate terminates trust depends on the client’s trust store and path building.

Keep issuance authorization separate

Intermediates let a CA keep its root key offline and separate issuance operations. Revoking an intermediate can invalidate dependent leaf paths and may require replacement certificates; it does not preserve every leaf automatically.

CAA authorizes a CA’s documented issuer-domain identifier at issuance time. It does not pin an intermediate, change browser trust, or prove that an existing certificate complied with historical CAA. The dns-caa-records note covers that separate policy check.

Count for inventory, validate for trust

The earlier inventory command was:

$ echo | openssl s_client -connect www.xbcatm.com:443 -servername www.xbcatm.com -showcerts 2>/dev/null | grep 'BEGIN CERT' | wc -l
4

This is read-only network traffic, but it suppresses diagnostics and the final count can succeed even when an earlier command failed. Do not use 4, or any other fixed count, as a health threshold. A leaf-only result warrants checking the expected issuer path rather than declaring every one-certificate chain invalid.

For actual validation, configure hostname checking and failure on verification errors with OpenSSL’s -verify_hostname and -verify_return_error options, retain diagnostics, and record the trust store and client version. Also test the clients you support; one OpenSSL trust store cannot establish compatibility with all browsers.

Sources