A TLS client can send a server name during the handshake so a shared listener selects the intended certificate and policy. The later HTTP authority or Host field chooses an application route. These are related names but separate protocol steps. A request can reach the correct IP and still fail before HTTP if the TLS name is absent, the wrong certificate is selected, or the certificate does not cover the requested name.
Make this comfortable
TLS name selection: test SNI, certificate, and HTTP host together
Operational decision
A receipt portal moves to a shared edge listener. Test the exact public hostname with a normal client and inspect the certificate chain, name coverage, and expiry. Then use the diagnostic handshake below to see what the edge presents when the intended SNI is sent; compare with a no-SNI connection only to understand the listener default, not as proof of user behavior. Test the HTTP route separately after certificate validation. A synthetic check that connects to an IP with a custom Host header may omit SNI and report a misleading failure, so configure it to use the actual hostname or an explicit name-resolution override. During rotation, keep old and new names covered for the compatibility window and verify both edge locations before removing the prior certificate. Do not disable certificate verification to make a route test pass; that only hides the trust failure.
openssl s_client -connect receipt-edge.internal:443 -servername receipts.internal -verify_return_errorCost and verification
Certificate checks add handshake work, but they are cheap compared with serving traffic under the wrong identity. Multiple certificates and edge locations increase rotation coordination and monitoring scope. Record failures by TLS name, selected certificate, and edge location, as well as HTTP route result after handshake. A successful TCP connect says nothing about name validation. The command reports the presented chain, but a complete client test must also validate hostname rules and trust using the client's own TLS stack.
Common Mistakes
- Do not test a named HTTPS route only by connecting to its IP without SNI.
- Do not bypass certificate verification to mask a bad edge rollout.
- Do not treat the HTTP Host field as a replacement for TLS name selection.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- DNS, TLS, and reverse-proxy failure boundaries
- Certificate renewal: verify the served certificate after issuance
- Synthetic transactions: measure the route a user actually takes
- Gateway API routing: accepted route versus working request
Practice and check
TLS trust operations follow-up
devops
operations