OpenSSL s_client: o 403 do proxy surge antes do TLS do destino
Interpreta um 403 no CONNECT através de um proxy OpenSSL como uma falha na fase de túnel e não diagnostiques o certificado do destino a partir de um handshake que nunca começou.
Se openssl s_client receber um HTTP 403 em resposta ao seu pedido CONNECT através do proxy, começa por essa recusa. O túnel pedido não foi estabelecido.
Com -proxy, o s_client pede primeiro ao proxy HTTP que se ligue ao destino indicado por -connect. Só uma resposta CONNECT bem-sucedida transforma essa troca num túnel para o handshake TLS do destino.
Esta ordem explica uma saída de outro modo confusa: um erro do proxy seguido de cabeçalhos relacionados com TLS, nenhum certificado do par ou uma linha de verificação aparentemente tranquilizadora. Esses campos não provam que o certificado do destino foi recebido e verificado. A operação parou numa etapa anterior.
Regista a resposta do proxy e o host e a porta de destino pedidos. Um 403 dirige a atenção para a decisão de acesso do proxy; um 407 pede autenticação no proxy. Nenhum dos dois se corrige desativando a verificação do certificado do destino.
Quando é permitido inspecionar a troca, a saída -debug do s_client pode ajudar a expor a recusa. Mantém quaisquer credenciais do proxy fora de rastos partilhados. Um túnel bem-sucedido continuaria a precisar da sua própria avaliação de TLS e de certificados depois disso, mas não há qualquer cadeia de certificados de destino para diagnosticar até essa etapa ser realmente alcançada.