Pode unha cadea de certificados do servidor anular o almacén de confianza do cliente?

Un navegador mostra un aviso de certificado nun sitio cuxa cadea está completa, e o primeiro instinto é arranxar o servidor. Normalmente o servidor presenta exactamente o que debería. O cliente decide que ancoraxes acepta, e ningunha disposición de certificados intermedios pode cambiar esa decisión desde o outro extremo da conexión. Esa fronteira explica a maior parte do que parece un problema de certificado.

A validación execútase no cliente, coas ancoraxes do cliente

A validación de ruta toma os certificados presentados e constrúe unha cadea ata unha ancoraxe de confianza que o sistema de validación xa posúe. RFC 5280 describe ese modelo, e sitúa a selección da ancoraxe na implementación local e non no servidor. Unha aplicación pode engadir a súa propia política por riba: unha chave fixada, un almacén de confianza empresarial, ou unha comprobación de identidade máis estrita. A lista de certificados que envía un servidor é unha proba ofrecida a ese proceso, nunca unha instrución dirixida a el.

Así, unha cadea completa demostra que o servidor ten as pezas. Non demostra que o cliente as vaia aceptar.

Para ver que envía realmente o servidor, execute openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts e conte os certificados na saída. Unha cadea incompleta aí é unha corrección do lado do servidor. Unha cadea completa traslada a pregunta ao cliente e ás súas ancoraxes, onde o servidor non ten voto.

Que cambia realmente a inspección de TLS

Un dispositivo de inspección termina a sesión TLS do lado do cliente e abre unha sesión separada cara ao servizo real. O cliente entón valida o certificado do dispositivo, que debe encadear ata unha ancoraxe na que o cliente confíe. Por iso os dispositivos xestionados reciben a raíz de inspección mediante a xestión de dispositivos, e por iso un dispositivo persoal sen ela mostra un aviso.

A disposición é deliberada e local. Nada na cadea do servidor orixinal pode obrigar un navegador non xestionado a aceptar a identidade substituta, e nada nela impide que un dispositivo xestionado o faga.

A terminación de VPN non é descifrado de HTTPS

Unha capa de VPN transporta paquetes entre un cliente e unha pasarela. Quitala, ou ler a súa configuración, non expón unha carga útil HTTPS dentro.

A sesión TLS segue executándose entre o navegador e o servidor web, coas mesmas regras de validación, a menos que algo a termine explicitamente. Confundir as dúas capas produce unha petición ao administrador da VPN para que proporcione o certificado, cando o certificado en cuestión pertence a un proxy de inspección ou ao propio sitio. Pregunte que compoñente presenta o certificado antes de cambiar calquera almacén de confianza.

Fixe as expectativas no compoñente que controla

Se xestiona a aplicación e o seu cliente, defina á vez a identidade de servizo esperada, os emisores aceptados e calquera requisito de fixación ou autenticación de cliente. Planifique a renovación e a recuperación para que un cambio lexítimo de certificado non se converta nunha interrupción. Se só xestiona o servidor público, documente que autenticación esixe e que contornos de cliente admite. Enviar unha cadea preferida non certifica o dispositivo dun descoñecido.

En equipos xestionados, resolva a incompatibilidade cos responsables da aplicación e da rede. Desactivar a verificación, engadir unha raíz sen explicación ou tentar sobrevivir a unha política de inspección non establece a relación de iguais prevista.

Probe o resultado nun perfil de cliente limpo, non na máquina onde xa se engadiu unha excepción. Esa é a única comprobación que mostra o que experimentará un dispositivo novo.