APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
HTTPS protege uma ligação utilizando TLS, com verificação da identidade esperada segundo a configuração do cliente. Não é uma prova de que todos os saltos internos têm a mesma proteção. Se o proxy termina TLS e abre outra ligação, o segundo salto precisa da sua própria análise. O certificado apresentado ao browser não valida o upstream. Em NGINX, verifica opções efetivas de validação, nome e confiança: a documentação apresenta proxy_ssl_verify desligado por omissão, pelo que escrever https no destino não confirma autenticação do backend. Esta aula usa os princípios TLS 1.3 e identidade de serviço como base selecionada, sem ensinar uma configuração criptográfica completa para todos os ambientes.
Aplicação guiada
Num teste anterior à mudança DNS, mantém o hostname no URL e usa uma substituição de resolução delimitada, como --resolve em curl. Alterar apenas Host num URL com IP não garante a identidade TLS pretendida. Se a confiança falha, investiga a cadeia, o nome e as autoridades aprovadas; desativar a verificação oculta a falha. HSTS num browser que já conhece a política impõe acesso seguro, mas não prolonga um certificado expirado. Num caso fictício, a migração do upstream apresenta outro nome no certificado. Corrige o alinhamento nesse salto e valida a ligação; renovar apenas o certificado público do proxy não responde à evidência recolhida.
Browser-proxy válido e proxy-upstream inválido são resultados compatíveis: os saltos são diferentes.
Armadilhas comuns
Host como substituto de SNI e nome TLS; -k como correção; cadeado como garantia de todos os saltos; HSTS como renovação.
Tópicos relacionados: O pedido e a representação pretendida · Métodos, estados e repetição controlada · Cache, variantes e validação
Confirma nome, confiança e proteção em cada ligação relevante.
Referência: curl TLS certificate verification · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance