LEARN. PRACTICE. GROW.Draw who verifies whom
The lab has two connections: curl to NGINX and NGINX to the Python origin. The client trusts front-ca and verifies portal.fund.test. The proxy trusts origin-ca and verifies origin.fund.test. Write these pairs in the worksheet before reading results. The first connection does not automatically authenticate the second. In a fictional service hosted behind middleware, renewing the public certificate can complete one task without resolving an upstream failure. Operational responsibility must identify the owner of each configuration and the evidence needed to accept that hop, alongside the end-to-end functional outcome.
Interpret 502 with valid frontend TLS
The /wrong-name and /wrong-trust routes preserve client-to-proxy TLS while introducing different failures on the second hop. On both, curl receives 502 and exits with zero by default. The origin receives no HTTP request. The NGINX log distinguishes a name mismatch from chain verification failure. Repeating /wrong-name with --fail-with-body retains status 502 and changes the exit to 22 while preserving the error body. Use these axes separately during diagnosis. An exit code is interpretable only with the client policy known; it does not by itself represent every dependency state.
Distinguish SNI from verification
On /no-sni, SNI sending is disabled, while certificate verification and the expected name remain configured. The origin presents a single certificate and the request succeeds in this experiment. The result does not authorize removing SNI from an architecture that selects certificates by name. In that architecture, the matrix must test each relevant name and the certificate actually presented. Conversely, sending a name through SNI is not proof that it was verified. Keep certificate selection, expected identity and chain trust as separate questions. Record effective configuration to avoid conclusions based only on the file intended for deployment.
Use the negative control without accepting it
The /negative-control route is deliberately unsafe and exists only in the disposable loopback process. It disables proxy_ssl_verify while retaining the wrong name; the request then receives 200. Evidence marks acceptedConfiguration as false. This comparison demonstrates the danger of using apparent availability alone as a recovery criterion. The exercise does not recommend disabling verification as mitigation. In a fictional incident, compare correcting name and trust with rolling back to known configuration while retaining required controls. The decision must also validate delivered content. A technical result that removes an acceptance condition does not establish that the condition was satisfied.
Validate the outcome the consumer needs
On /login, both TLS hops are accepted and the client receives 200, but the body is an HTML login page. The case consumer expected readiness JSON. The functional check should fail without inventing a certificate failure. Define expected fields, required version and the authorized path for that consumer. If there are three proxies and different trust stores, one test on a single path leaves coverage unproven. Fill one row per relevant combination and identify anything that could not be tested. Use synthetic data and accounts where possible; the report does not need private keys or credentials.
Hand operations to the next team
Set aside fifteen minutes to fill the worksheet below using a lab incident. Write an English update identifying the failing hop, functional impact, current action, owner and next update point. A colleague can ask whether the service has recovered; answer with acceptance criteria and available evidence. The exercise is proposed to the learner, not a human workshop already performed. For closure, include rollback procedure, a test on the ordinary path and acknowledged gaps. This material uses fictional examples and does not represent BNP Paribas internal procedures or production approval.
HTTPS ACCEPTANCE WORKSHEET / GRELHA DE ACEITACAO HTTPS
Consumer and operation / Consumidor e operacao:
Transport destination / Destino de transporte:
URL reference name / Nome de referencia do URL:
Client trust and result / Confianca e resultado no cliente:
Proxy upstream name and trust / Nome e confianca upstream:
SNI sent and HTTP Host / SNI enviado e Host HTTP:
Client exit and HTTP status / Saida do cliente e estado HTTP:
Origin HTTP reached / Pedido HTTP chegou a origem:
Required body, version and freshness / Corpo, versao e atualidade exigidos:
Instances covered and missing / Instancias cobertas e em falta:
Correction or rollback evidence / Evidencia de correcao ou reversao:
RUN owner and next update / Responsavel RUN e proxima atualizacao:
Unexecuted scope / Ambito nao ensaiado:
Frontend TLS succeeds while the upstream is rejected by name. The client receives 502; renewing the public certificate again does not resolve the observed condition.
Common pitfalls
Closing on curl exit zero, accepting 200 with verification disabled, confusing SNI with validation or declaring all instances tested from one result.
Related topics: The request and intended representation · HTTPS, identity, and proxy hops · Diagnosis and time budgets
Recovery must retain identity controls and demonstrate the expected result on relevant paths, with explicit handover limitations.
Reference: NGINX HTTP proxy module: upstream TLS · BigSavant HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance