Dentro de SSL / TLS, el servidor envía su cadena de certificados sistemáticamente al cliente (bueno, a menos que el cliente quiera negociar un conjunto de cifrado que no use ningún certificado, pero eso es bastante raro en la práctica). Consulte el estándar TLS , en particular este diagrama, que lo dice todo:
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1. Message flow for a full handshake
Para obtener explicaciones (mucho más completas) sobre cómo funciona SSL / TLS, lea esta respuesta .
Tenga en cuenta, sin embargo, que si bien SSL / TLS se basa formalmente en los certificados X.509, el protocolo no está irremediablemente vinculado con X.509. Dentro de la dinámica de handshake, la idea es que el servidor envíe su clave pública al cliente dentro de una cadena de certificados , y luego el cliente de alguna manera usa la clave pública del servidor. Cómo el cliente obtiene la clave pública del servidor está un poco fuera de alcance; normalmente, el cliente lo hace decodificando y validando la cadena de certificados enviada por el servidor, pero el cliente es libre de "conocer" la clave pública del servidor de cualquier otra forma que considere adecuada. En algunas aplicaciones dedicadas (especialmente en sistemas integrados), el cliente puede contener una copia codificada de la clave pública del servidor, y simplemente usarla, sin tener en cuenta lo que el servidor envíe como "cadena de certificados".
Además, la "cadena de certificados", desde el punto de vista de SSL / TLS, es una secuencia de manchas opacas, de manera que la longitud total no exceda de 16 megabytes. Si bien estos blobs son normalmente certificados X.509 codificados, pueden ser otra cosa, siempre que el cliente esté de acuerdo (y un cliente que ignora la cadena de certificados del servidor aceptará, por definición, cualquier cosa). Incluso hay un RFC definido formalmente para usar claves OpenPGP en lugar de certificados X.509 en SSL / TLS.
SI la cadena de certificados sigue las reglas habituales (certificados X.509, que el cliente valida), luego Se aplican las reglas X.509 . El algoritmo completo de validación de la ruta X.509 es un trabajo del Diablo para confundir y corromper las mentes de los hombres buenos . Sin embargo, como resumen simple, un certificado emitido (su "certificado de CA intermedio") coincide con su emisor (en su caso, la raíz) a través de las dos propiedades siguientes, que deben cumplirse todas:
-
El campo subjectDN en el emisor (raíz) debe ser igual al campo issuerDN en el emitido (CA intermedia). Gracias a la multitud de posibles codificaciones y las reglas bizantinas de Unicode para la coincidencia de casos, la "igualdad" real de los nombres es una noción potencialmente compleja.
-
Un certificado está firmado ; la firma en el certificado emitido debe ser verificable con respecto a la clave pública del emisor.
Por lo tanto, si desea mantener el certificado de CA intermedio sin cambios, entonces, como mínimo, la nueva raíz necesitará usar el mismo nombre exacto que el anterior, y también la exacta mismo par de claves. Si cambia cualquiera de los dos (o ambos), deberá volver a emitir un nuevo certificado para la CA intermedia.
Los mismos principios se aplican a lo largo de la cadena: si cambia el certificado de la entidad de certificación intermedia, es posible que los certificados de entidad final no se modifiquen (los certificados emitidos anteriormente por la entidad de certificación), si (y solo si) la nueva entidad de certificación. El certificado aún contiene el mismo nombre de CA intermedio y la clave pública de CA intermedia.