APRENDER. PRATICAR. EVOLUIR.Desenhar quem valida quem
O laboratório tem duas ligações: curl para o NGINX e NGINX para a origem Python. O cliente confia em front-ca e valida portal.fund.test. O proxy confia em origin-ca e valida origin.fund.test. Escreve estes pares na grelha antes de ler os resultados. A primeira ligação não autentica automaticamente a segunda. Num serviço fictício alojado atrás de middleware, renovar o certificado público pode concluir uma tarefa sem resolver uma falha upstream. A responsabilidade operacional precisa de indicar o proprietário de cada configuração e a prova que permite aceitar esse salto, além do resultado funcional de ponta a ponta.
Interpretar 502 com TLS válido no frontend
As rotas /wrong-name e /wrong-trust preservam a ligação TLS do cliente ao proxy e introduzem falhas distintas no segundo salto. Em ambas, curl recebe 502 e termina com zero por omissão. A origem não recebe o pedido HTTP. O log NGINX distingue incompatibilidade de nome de falha de verificação da cadeia. Repetir /wrong-name com --fail-with-body mantém o estado 502 e altera a saída para 22, conservando o corpo de erro. Usa estes eixos separadamente no diagnóstico. Um código de saída só é interpretável conhecendo a política do cliente; não representa por si só o estado de todas as dependências.
Distinguir SNI de verificação
Na rota /no-sni, o envio de SNI é desligado, mas a verificação do certificado e o nome esperado permanecem definidos. A origem apresenta um único certificado e o pedido passa neste ensaio. O resultado não autoriza remover SNI numa arquitetura que seleciona certificados por nome. Nessa arquitetura, a matriz precisa de testar cada nome relevante e o certificado efetivamente apresentado. Por outro lado, enviar um nome por SNI não é prova de que foi verificado. Mantém separadas as perguntas sobre seleção de certificado, identidade esperada e confiança na cadeia. Regista a configuração efetiva para evitar conclusões baseadas apenas no ficheiro que se pretendia instalar.
Usar o controlo negativo sem o aceitar
A rota /negative-control é deliberadamente insegura e existe apenas no processo descartável de loopback. Desliga proxy_ssl_verify e mantém o nome errado; o pedido passa a receber 200. A evidência marca acceptedConfiguration como false. Esta comparação demonstra o perigo de usar apenas disponibilidade aparente como critério de recuperação. O exercício não recomenda desativar verificação como mitigação. Num incidente fictício, compara uma correção do nome e confiança com uma reversão para configuração conhecida, mantendo os controlos exigidos. A decisão precisa de validar também o conteúdo entregue. Um resultado técnico que remove a condição de aceitação não demonstra que essa condição foi satisfeita.
Validar o resultado que o consumidor precisa
Em /login, os dois saltos TLS são aceites e o cliente recebe 200, mas o corpo é uma página HTML de login. O consumidor do caso esperava JSON de prontidão. O check funcional deve falhar sem inventar uma falha de certificado. Define campos esperados, versão necessária e percurso autorizado para esse consumidor. Se houver três proxies e trust stores diferentes, um teste num único caminho deixa cobertura por demonstrar. Preenche uma linha por combinação relevante e indica o que não pôde ser ensaiado. Os dados e contas usados devem ser sintéticos quando possível; o relatório não precisa de chaves privadas ou credenciais.
Entregar a operação à equipa seguinte
Reserva quinze minutos para preencher a grelha abaixo com um incidente do laboratório. Escreve uma atualização em inglês que identifique o salto em falha, o impacto funcional, a ação em curso, o responsável e o próximo ponto de situação. Um colega pode perguntar se o serviço está recuperado; responde com os critérios de aceitação e a evidência disponível. O exercício é proposto ao formando, não um workshop humano já realizado. Para o fecho, inclui procedimento de reversão, teste no percurso normal e lacunas assumidas. Este material usa exemplos fictícios e não representa procedimentos internos BNP Paribas ou aprovação de produção.
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:
O frontend aceita TLS enquanto o upstream é rejeitado por nome. O cliente recebe 502; renovar de novo o certificado público não resolve a condição observada.
Armadilhas comuns
Fechar pela saída zero de curl, aceitar 200 com verificação desligada, confundir SNI com validação ou declarar todas as instâncias testadas a partir de uma só.
Tópicos relacionados: O pedido e a representação pretendida · HTTPS, identidade e saltos de proxy · Diagnóstico e orçamento de tempo
A recuperação deve manter os controlos de identidade e demonstrar o resultado esperado nos percursos relevantes, com limitações explícitas no handover.
Referência: NGINX HTTP proxy module: upstream TLS · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance