¿Puede una cadena de certificados del servidor anular el almacén de confianza del cliente?

Un navegador muestra una advertencia de certificado en un sitio cuya cadena está completa, y el primer instinto es arreglar el servidor. Normalmente el servidor presenta exactamente lo que debería. El cliente decide qué anclajes acepta, y ninguna disposición de certificados intermedios puede cambiar esa decisión desde el otro extremo de la conexión. Ese límite explica la mayor parte de lo que parece un problema de certificado.

La validación se ejecuta en el cliente, con los anclajes del cliente

La validación de ruta toma los certificados presentados y construye una cadena hasta un anclaje de confianza que el sistema de validación ya posee. RFC 5280 describe ese modelo, y sitúa la selección del anclaje en la implementación local y no en el servidor. Una aplicación puede añadir su propia política encima: una clave fijada, un almacén de confianza empresarial, o una comprobación de identidad más estricta. La lista de certificados que envía un servidor es una prueba ofrecida a ese proceso, nunca una instrucción dirigida a él.

Así, una cadena completa demuestra que el servidor tiene las piezas. No demuestra que el cliente las vaya a aceptar.

Para ver qué envía realmente el servidor, ejecute openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts y cuente los certificados en la salida. Una cadena incompleta ahí es una corrección del lado del servidor. Una cadena completa traslada la pregunta al cliente y sus anclajes, donde el servidor no tiene voto.

Qué cambia realmente la inspección de TLS

Un dispositivo de inspección termina la sesión TLS del lado del cliente y abre una sesión separada hacia el servicio real. El cliente entonces valida el certificado del dispositivo, que debe encadenar hasta un anclaje en el que el cliente confíe. Por eso los dispositivos gestionados reciben la raíz de inspección mediante la gestión de dispositivos, y por eso un dispositivo personal sin ella muestra una advertencia.

La disposición es deliberada y local. Nada en la cadena del servidor original puede obligar a un navegador no gestionado a aceptar la identidad sustituta, y nada en ella impide que un dispositivo gestionado lo haga.

La terminación de VPN no es descifrado de HTTPS

Una capa de VPN transporta paquetes entre un cliente y una puerta de enlace. Quitarla, o leer su configuración, no expone una carga útil HTTPS dentro.

La sesión TLS sigue ejecutándose entre el navegador y el servidor web, con las mismas reglas de validación, a menos que algo la termine explícitamente. Confundir las dos capas produce una petición al administrador de la VPN para que proporcione el certificado, cuando el certificado en cuestión pertenece a un proxy de inspección o al propio sitio. Pregunte qué componente presenta el certificado antes de cambiar cualquier almacén de confianza.

Fije las expectativas en el componente que controla

Si opera la aplicación y su cliente, defina a la vez la identidad de servicio esperada, los emisores aceptados y cualquier requisito de fijación o autenticación de cliente. Planifique la renovación y la recuperación para que un cambio legítimo de certificado no se convierta en una interrupción. Si solo opera el servidor público, documente qué autenticación exige y qué entornos de cliente admite. Enviar una cadena preferida no certifica el dispositivo de un desconocido.

En equipos gestionados, resuelva la incompatibilidad con los responsables de la aplicación y de la red. Desactivar la verificación, añadir una raíz sin explicación o intentar sobrevivir a una política de inspección no establece la relación de iguales prevista.

Pruebe el resultado en un perfil de cliente limpio, no en la máquina donde ya se añadió una excepción. Esa es la única comprobación que muestra lo que experimentará un dispositivo nuevo.