En SSL / TLS el servidor debe mostrar su certificado como parte de una cadena. Teóricamente, el servidor debe asegurarse de que la cadena enviada sea correcta, y el cliente tiene "derecho moral" a rechazar la conexión si la cadena exacta enviada por el servidor no puede validarse. Sin embargo, a los clientes se les permite hacer esfuerzos adicionales; Si pueden validar el certificado con otra cadena, entonces está bien continuar.
Por lo tanto, uno no puede culpar formalmente a algunos clientes por no validar el certificado del servidor si el servidor envía una cadena defectuosa.
Cuando un cliente intenta construir una cadena alternativa, utilizará algunos o todos los métodos siguientes:
- El cliente puede tener certificados de CA intermedios instalados localmente (en el sistema Windows, el almacén de "CA intermedia" está destinado a eso).
- Los certificados enviados por el servidor pueden reutilizarse (pero quizás no en el mismo orden).
- El cliente puede tener acceso a algún servidor LDAP o equivalente en el que algunos certificados pueden buscarse por nombre de sujeto (esto puede ocurrir en las configuraciones de Windows / Active Directory). El plan inicial para X.509 era que debería haber un Directorio mundial, como algún tipo de DNS generalizado, pero nunca sucedió.
- El cliente puede intentar descargar otros certificados de CA intermedios siguiendo la URL que se encuentra en Acceso a la información de la autoridad extensiones de los certificados.
Este último método es el que normalmente funcionará. Un certificado bien emitido contendrá una extensión AIA con una URL que apunta al certificado de la CA que lo emitió. Ese certificado puede contener una extensión AIA que apunta a la CA de nivel superior, y así sucesivamente, hasta la raíz. Mientras todas las URL sean de acceso público, la red está en funcionamiento y ningún administrador del sistema entró en su patética excusa para que una mente bloquee ese mecanismo (desafortunadamente lo he visto), entonces la cadena se reconstruirá con éxito. Los sistemas modernos de Windows lo hacen automáticamente.
Pero recuerde que a los clientes SSL se les permite no comportarse de esa manera. Un punto importante a tener en cuenta es que el seguimiento de URL se basa en HTTP. Un navegador web sabe HTTP; Esa es una especie de característica principal de un navegador. Sin embargo, una aplicación independiente que utiliza alguna biblioteca SSL puede no ser capaz de emitir solicitudes HTTP aleatorias, o simplemente estar dispuesta a hacerlo. Algunas bibliotecas SSL proporcionan el soporte de protocolo pero confían en la persona que llama para que realmente proporcione conectividad de red (la persona que llama abre y opera la conexión TCP, la biblioteca es simplemente la parte computacional). Dependiendo de cómo esté diseñada la aplicación y su implementación de SSL, puede o no tener éxito en enviar los certificados adicionales cuando sea necesario.
Es mucho mejor si el servidor está correctamente instalado en primer lugar.