Investigate a client failure after a hostname change.

Instruction: Choose the first two observations before revealing Stage 2; then identify the failing boundary and verify a correction.

Context:

Stage 1. A fictional service moved from api.old.example to api.new.example. One client reports a connection failure for the new URL. Application request counts did not increase during its attempts. Choose checks that distinguish name resolution, transport, TLS and HTTP without disabling certificate verification.

Stage 2 — inspect after selecting your checks

Sanitized observations from the same client and minute follow. The DNS answer matches the approved new load-balancer address. The documentation-only IP is fictional.

DNS api.new.example -> 203.0.113.20
TCP connect to 203.0.113.20:443 -> established
TLS request SNI -> api.new.example
TLS certificate chain -> trusted; certificate dates -> current
Leaf certificate SAN -> DNS:api.old.example
HTTPS client -> hostname verification failed
HTTP response -> none

Updated

Official answer available

Read the opening below, then unlock the full answer and practical guidance.

I would first resolve the requested name and inspect a normal validating HTTPS connection from the failing client, including the selected address and TLS outcome...

Upgrade to view official answer

Related Questions