Front-end TLS success and backend trust failure
A fictional HTTP virtual-server design terminates client TLS and re-encrypts a separate backend connection. The client validates the front-end certificate successfully, but supplied backend logs report a certificate-name mismatch after a server replacement. One colleague proposes disabling all backend verification because the browser shows a secure connection. Another separates the two TLS legs and compares the intended backend hostname, chain and configured trust requirements. No network request or certificate configuration is changed in this written exercise. The learner must explain why one successful handshake does not validate the other connection, identify a focused evidence path and consider how an authorized repair can preserve the intended trust boundary without creating an unrelated access-policy exception.
1. Why is the browser result insufficient?
Read the worked answer
It concerns the client-facing leg under its validation rules. The separate backend TLS connection has its own peer name, trust and configuration requirements.
2. What is the appropriate repair direction?
Read the worked answer
Confirm the intended backend identity, actual certificate names/chain, trust and supported server-side TLS configuration. Use an authorized narrow correction and verify both legs instead of broadly disabling verification.