A certificate renewal can look successful in a hosting panel while one edge server still presents yesterday’s chain. The homepage opens normally on your laptop, then an API client fails from a clean container. That gap is why a useful TLS check asks several smaller questions instead of trusting one green badge.

What a working HTTPS connection must prove

  • Identity: the certificate covers the requested DNS hostname through its Subject Alternative Name entries.

  • Trust: the server presents enough intermediate certificates for a client to build a path to a trusted root.

  • Time validity: the current time falls between notBefore and notAfter.

  • Key possession: the server completes the handshake using the private key corresponding to the certificate.

  • Negotiation: client and server agree on an acceptable TLS version and cipher suite.

  • Page integrity: the HTTPS document does not quietly load scripts, styles, images, or fonts over HTTP.

TLS provides encryption, integrity, and server authentication. It does not certify that a business is honest, that an application has no vulnerabilities, or that content is harmless. The browser’s security indicator describes the connection, not the character of the site behind it.

Start with the exact hostname users type

Test example.com and www.example.com separately when both are public. They may resolve to different infrastructure or present certificates with different names. Do the same for API, admin, CDN, or regional hostnames that clients actually use.

Terminalbash
openssl s_client -connect example.com:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error \
  -brief < /dev/null

What this handshake check tells you

  • -connect example.com:443 opens TCP and TLS to the chosen endpoint and port.

  • -servername example.com sends Server Name Indication, allowing a shared server or CDN to select the intended virtual host certificate.

  • -verify_hostname example.com checks the certificate identity against that hostname; merely printing a certificate would not perform this check.

  • -verify_return_error stops on a verification failure instead of continuing a diagnostic session after reporting it.

  • -brief keeps the output focused on the negotiated protocol, cipher, peer certificate, and verification result.

  • A successful exit validates against the trust store available to this OpenSSL installation; another client with a different trust store can still behave differently.

Inspect identity, issuer, SANs, and dates

Terminalbash
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

How to read the certificate fields

  • s_client performs the remote handshake and emits the presented leaf certificate in PEM form.

  • The pipe sends that certificate to openssl x509; it does not save or alter the server certificate.

  • subject identifies the certificate subject, while issuer identifies the authority that signed it.

  • notBefore and notAfter define the validity window; monitor the latter with enough margin to repair failed automation.

  • subjectAltName is the decisive list of covered DNS names for modern hostname verification.

  • Redirecting from an uncovered hostname does not help because TLS validation occurs before the browser can receive the HTTP redirect.

Inspect the chain the server actually sends

Terminalbash
openssl s_client -connect example.com:443 \
  -servername example.com \
  -showcerts < /dev/null

What the chain output means

  • -showcerts displays the certificates the server sent; it is not, by itself, proof that OpenSSL validated them.

  • The leaf certificate normally appears first, followed by one or more intermediates.

  • Servers normally omit the root certificate because clients carry trusted roots locally.

  • A missing intermediate may work on a browser that cached it while failing on a clean client, embedded device, or service runtime.

  • The final Verify return code and an explicit hostname-aware verification command provide stronger evidence than counting PEM blocks.

Let’s Encrypt’s chain documentation explains why an issued certificate is delivered with intermediates: the server presents a path that lets the client validate signatures toward a root already in its trust store.

Turn expiry into a machine-friendly health check

Terminalbash
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -checkend 1209600
Certificate will not expire

Why this works in monitoring

  • -checkend compares the certificate’s expiry with the current time plus the supplied number of seconds.

  • 1209600 equals 14 days; choose an alert window longer than your realistic renewal and deployment recovery time.

  • The command communicates through its exit status, which makes it suitable for a monitoring job.

  • This checks the served leaf certificate, not whether an ACME client merely downloaded a newer certificate somewhere on disk.

Verify the HTTP-to-HTTPS journey

Terminalbash
curl -I http://example.com/docs/page?mode=test
curl -I https://example.com/docs/page?mode=test

What to verify in the headers

  • -I requests response headers, making redirect status and Location visible.

  • The HTTP request should redirect permanently to the intended HTTPS hostname while preserving the meaningful path and query.

  • The HTTPS request should return the expected application response rather than a certificate error or redirect loop.

  • Strict-Transport-Security can protect subsequent visits, but deploy HSTS only after every required subdomain and certificate path is ready.

Test protocol policy, not a hard-coded “TLS 1.3 only” slogan

TLS 1.3 is current and TLS 1.2 remains necessary for some supported clients; TLS 1.0 and 1.1 should no longer be used. The correct compatibility boundary depends on your real browsers, API clients, operating systems, and embedded devices. Test the oldest client you claim to support and reject obsolete versions deliberately.

An external scanner such as Qualys SSL Labs complements local OpenSSL checks by testing protocol versions, ciphers, chain presentation, and several client simulations from outside your network. Do not submit private hostnames or sensitive preproduction endpoints to a public scanner.

Check the page above TLS for mixed content

A valid certificate protects the main HTTPS connection, but a page can still request an image, stylesheet, font, script, iframe, or API URL over plain HTTP. Browsers may upgrade, warn about, or block these requests depending on resource type and policy. Inspect the browser console and network panel across representative pages.

  • Search templates, configuration, and stored content for hard-coded http:// asset URLs.

  • Check third-party embeds and fonts, not only resources hosted on your domain.

  • Fix the source URL rather than hiding the browser warning.

  • Test authenticated and checkout pages whose resources may differ from the homepage.

Common failures and the clue each one gives you

Hostname mismatch

The requested hostname is absent from the SAN extension, the wrong virtual host answered, or the connection went to an old load balancer. Confirm DNS, CDN custom-domain configuration, SNI routing, and certificate coverage for every public alias.

Unable to get local issuer certificate

The server may be missing an intermediate, or the client may lack an appropriate trust anchor. Compare the presented chain with the certificate authority’s documented chain and test from a clean environment before changing client trust.

Expired certificate after renewal succeeded

The renewed file may not be attached to the active listener, a service may need a reload, or one node in a load-balanced pool may still serve the old certificate. Repeat the check against each known edge or origin where operational access permits.

Browser works, command-line client fails

Compare hostname, SNI, proxy path, clock, OpenSSL version, and trust store. Browsers and operating systems can use different trust stores and may cache intermediates, so the disagreement is useful diagnostic evidence rather than proof that one side is irrational.

A padlock is the beginning of the check

The reassuring result is not “all green” on one page. It is agreement between hostname-aware verification, the served chain, the validity window, the HTTP redirect, supported clients, and real page resources. Once those layers agree, you know what is working—and which check should alert you before it stops.