Uma cadeia de certificados do servidor pode anular o repositório de confiança do cliente?

Um navegador mostra um aviso de certificado num site cuja cadeia está completa, e o primeiro instinto é corrigir o servidor. Normalmente o servidor apresenta exatamente o que deveria. O cliente decide que âncoras aceita, e nenhuma disposição de certificados intermédios pode alterar essa decisão a partir do outro extremo da ligação. Esse limite explica a maior parte do que parece um problema de certificado.

A validação ocorre no cliente, com as âncoras do cliente

A validação do caminho pega nos certificados apresentados e constrói uma cadeia até uma âncora de confiança que o sistema de validação já possui. A RFC 5280 descreve esse modelo, e coloca a seleção da âncora na implementação local e não no servidor. Uma aplicação pode acrescentar a sua própria política por cima: uma chave fixada, um repositório de confiança empresarial, ou uma verificação de identidade mais rigorosa. A lista de certificados que um servidor envia é uma prova oferecida a esse processo, nunca uma instrução dirigida a ele.

Assim, uma cadeia completa prova que o servidor tem as peças. Não prova que o cliente as aceitará.

Para ver o que o servidor envia realmente, execute openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts e conte os certificados na saída. Uma cadeia incompleta aí é uma correção do lado do servidor. Uma cadeia completa transfere a questão para o cliente e as suas âncoras, onde o servidor não tem voto.

O que a inspeção de TLS altera realmente

Um equipamento de inspeção termina a sessão TLS do lado do cliente e abre uma sessão separada para o serviço real. O cliente valida então o certificado do equipamento, que tem de encadear até uma âncora em que o cliente confie. É por isso que os dispositivos geridos recebem a raiz de inspeção através da gestão de dispositivos, e é por isso que um dispositivo pessoal sem ela mostra um aviso.

A disposição é deliberada e local. Nada na cadeia do servidor original pode forçar um navegador não gerido a aceitar a identidade substituta, e nada nela impede um dispositivo gerido de o fazer.

A terminação de VPN não é desencriptação de HTTPS

Uma camada de VPN transporta pacotes entre um cliente e um gateway. Removê-la, ou ler a sua configuração, não expõe uma carga útil HTTPS lá dentro.

A sessão TLS continua a decorrer entre o navegador e o servidor web, com as mesmas regras de validação, a menos que algo a termine explicitamente. Confundir as duas camadas produz um pedido ao administrador da VPN para fornecer o certificado, quando o certificado em causa pertence a um proxy de inspeção ou ao próprio site. Pergunte que componente apresenta o certificado antes de alterar qualquer repositório de confiança.

Defina as expectativas no componente que controla

Se opera a aplicação e o seu cliente, defina em conjunto a identidade de serviço esperada, os emitentes aceites e qualquer requisito de fixação ou autenticação de cliente. Planeie a renovação e a recuperação para que uma alteração legítima de certificado não se torne uma interrupção. Se opera apenas o servidor público, documente que autenticação exige e que ambientes de cliente suporta. Enviar uma cadeia preferida não certifica o dispositivo de um desconhecido.

Em equipamento gerido, resolva a incompatibilidade através dos responsáveis da aplicação e da rede. Desativar a verificação, adicionar uma raiz sem explicação ou tentar sobreviver a uma política de inspeção não estabelece a relação de pares pretendida.

Teste o resultado num perfil de cliente limpo, não na máquina onde já foi adicionada uma exceção. É a única verificação que mostra o que um novo dispositivo irá experimentar.