Digamos que creo un certificado X509 autofirmado y lo uso para emitir el certificado B. Pongo el certificado A en mis autoridades raíz de confianza para que todos los certificados firmados por él sean aceptados. Mi pregunta es:
Cuando luego utilizo un servicio protegido por el certificado B, ¿cómo sabe mi computadora que realmente está firmado por el certificado A? ¿Está el certificado padre de alguna manera incrustado en su hijo?
En un certificado de X.509 , también se incluye el nombre del emisor (en su ejemplo, el nombre de A) (como issuerDN ). Además, un certificado puede contener una extensión que apunta a un lugar donde se puede descargar el certificado del emisor ("Acceso a la información de la autoridad", sección 4.2.2.1 de RFC 5280); tenga en cuenta que dado que todos los certificados son entidades firmadas que se aceptan y utilizan solo después de haber verificado estas firmas, se pueden descargar y transportar con poco cuidado. Finalmente, es habitual, en los protocolos donde una parte puede mostrar un certificado, mostrar realmente una lista de certificados que contenga los certificados de CA intermedios necesarios. Esto es lo que sucede, por ejemplo, en un mensaje SSL Certificate .
Todo esto ofrece muchas maneras para que una computadora realice creación de rutas de certificación , es decir, reconstruyendo cadenas de certificados en las que La validación (incluida la verificación de firmas criptográficas) parece relevante.
Cuando la CA emite el certificado, lo firman utilizando su clave privada. Solo la clave pública de la AC puede verificar que la firma sea auténtica y que el certificado no haya sido manipulado.
Lo que es extraño es que la propiedad de la firma parece faltar en muchas instancias (la clase X509Certificate de .NET y al ver un certificado en Windows). Descubrí que aunque no siempre se muestra, aún está dentro del certificado. Dado un certificado en formato binario DER, puede decodificarlo en texto plano que SÍ muestre la firma del firmante.
openssl x509 -text -noout -inform DER -in certFile.der
Signature Algorithm: sha1WithRSAEncryption
30:d9:40:ac:d8:0d:46:81:68:14:8a:c6:a7:29:96:4e:b4:58:
7b:e6:12:3f:45:4f:c6:9b:18:aa:f2:99:23:ee:48:df:5f:c0:
a3:c7:e4:ba:3a:bc:6f:58:57:fe:a8:a7:23:d0:d1:9a:47:a6:
42:1a:d8:20:e8:f1:ec:76:43:47:0b:75:d6:a1:d2:71:2b:f7:
19:96:e3:48:57:e2:36:0f:0c:25:5d:7f:f8:26:50:c2:5e:80:
8e:17:ac:37:ad:f1:e3:3c:6f:a3:20:a6:16:93:df:2b:04:9c:
22:d3:01:33:f9:4c:3b:f8:a8:39:f1:6c:41:74:de:ba:96:6a:
0b:f1:e6:f0:7b:d8:1f:42:ec:b5:73:d1:94:1b:01:4a:4c:13:
ca:5e:2b:af:fd:2c:eb:43:d3:fc:2f:ea:5a:8d:db:a9:6a:f6:
b6:9b:58:e1:b7:94:7f:14:6d:11:8b:2c:b7:4e:f3:82:ad:c4:
92:04:c4:97:a3:7a:52:e5:a0:b1:1b:8f:47:bb:43:a3:2c:1a:
fb:31:d9:51:7c:23:7b:57:8e:73:46:81:c4:25:f3:48:c5:a1:
8f:0d:3d:f2:e1:4b:fd:7f:49:b9:f9:b1:2a:c2:22:9e:8a:85:
61:bd:b7:18:8e:56:33:a4:6e:d2:7d:db:2e:37:d0:fb:9a:35:
87:c8:2a:69
De enlace
Para validar este certificado, se necesita un segundo certificado que coincide con el Emisor (Thawte Server CA) del primer certificado. Primero, uno verifica que el segundo certificado es de un tipo de CA; es decir, que puede ser utilizado para emitir otros certificados. Esto se hace por inspeccionar un valor del atributo CA en la extensión X509v3 sección. Entonces la clave pública RSA del certificado de CA se usa para decodifique la firma en el primer certificado para obtener un hash MD5, que debe coincidir con un hash MD5 real calculado sobre el resto de la certificado.
Lea otras preguntas en las etiquetas public-key-infrastructure tls certificates certificate-authority x.509