¿Por qué las cadenas de certificados son diferentes en Firefox y Chrome?

7

Tengo un servidor con HTTPS y noté un comportamiento muy extraño que no puedo entender.

Cuando verifiqué la cadena en Firefox , hay esto:

PeroenChromeveoesto:

Estáclaroquelasrutassondiferentes(4contra5elementosencadena).Enmásdetalle,parecequeelcertificado"Trusted Root CA SHA256 G2" tiene un certificado padre diferente.

Cuando verifiqué la cadena usando portecle también hay 5 elementos en cadena.

Mi pregunta es: ¿la cadena está construida en base a CN / DN? Si bien esto es, diría, solo un nombre, parece débil ... ¿Alguien sabe de dónde viene la diferencia?

editar: Gracias a la pregunta de Marko, me di cuenta de una cosa importante que no destacé, lo siento.

En esas dos cadenas, hay un certificado "GlobalSign", que parece ser correcto, pero en la cadena de Firefox, el número de serie del certificado es 04:00:00:00:00:01:21:58:53:08:A2 pero en la cadena de Chrome el certificado con el mismo alias tiene el número de serie ‎04 00 00 00 00 01 25 07 1d f9 af , por lo que es preocupante que el certificado "Trusted Root CA SHA256 G2" tenga un certificado primario diferente.

    
pregunta Betlista 11.05.2016 - 16:13
fuente

2 respuestas

2

Es probable que Firefox y Chrome hayan decidido confiar en los certificados en diferentes niveles. Chrome confía en "GlobalSign Root CA" y encadena el certificado hasta la raíz para verificar su validez, pero FireFox confía en "Trusted Root CA SHA256 G2" y no hay necesidad de que lo compruebe todo para la raíz Si ese navegador confía en ello. Entonces, si ambos navegadores devolvieron esa cadena es válida, debería estar bien. Las cadenas se basan en el certificado del padre FIRMANDO al hijo uno, y la verificación de la firma solo puede indicar si la ruta es válida. Espero que esto ayude!

editar: Bueno, los alias de los certificados no son únicos, por lo que una CA puede usar el mismo nombre para muchos de sus certificados. Por ejemplo, un CA con el que trabajé usó varios certificados intermedios con los mismos alias para emitir certificados de clientes por diferentes períodos de tiempo. Entonces, en este caso, tendrían el mismo alias, la misma raíz, ambos serían válidos, pero aún tendrían números de serie o tiempo de caducidad diferentes. Por lo tanto, no importa qué alias o números de serie usen los certificados, solo que todos ellos se encadenan a un certificado raíz en el que usted confía. En este caso, puede haber tantas cadenas con el mismo nombre que todas conduzcan a GlobalSign Root, y si confía en esa raíz como si la cadena de firmas es válida, la ruta a ella no importa. Espero que esto haya ayudado a sus preocupaciones.

    
respondido por el Marko 11.05.2016 - 16:35
fuente
2

GlobalSign tiene tres CA raíz activas de las cuales dos tienen un CommonName de simplemente GlobalSign, aunque otros componentes de nombre son diferentes si nos fijamos en los detalles.

Raíz-R1: CN = GlobalSign Raíz CA, OU = Raíz CA, O = GlobalSign nv-sa, C = BE
válido del 09/09/09 al 2028/01/28
sha1 huella dactilar b1 bc 96 8b d4 f4 9d 62 2a a8 9a 81 f2 15 01 52 a4 1d 82 9c

Raíz-R2: CN = GlobalSign, O = GlobalSign, OU = GlobalSign Root CA - R2
válido del 12/12/2005 al 2021/12/15
huella dactilar sha1 75 e0 ab b6 13 85 12 27 1c 04 f8 5f dd de 38 e4 b7 24 2e fe

Root-R3: CN = GlobalSign, O = GlobalSign, OU = GlobalSign Root CA - R3
válido del 18/03/2009 al 2029/03/18
huella dactilar sha1 d6 9b 56 11 48 f0 1c 77 c5 45 78 c1 09 26 df 5b 85 69 76 ad

Observe que R1 ha estado en uso poco después del inicio de SSL y HTTPS, pero R2 y R3 son significativamente más nuevos. (También tienen R4 R5 R6 emitido para uso futuro).

El certificado intermedio (no privado) que aparentemente usa su servidor es emitido por R3 para:
CN = raíz de confianza CA SHA256 G2, O = GlobalSign nv-sa, OU = raíz de confianza, C = BE
válido del 04/04/25 al 2027/04/25
sha1 huella digital 9a bb 55 a2 6f 9c 06 d5 00 c4 59 91 f0 2c 15 b5 5d 00 a7 02

Puede revisar esa huella digital para asegurarse de que estamos viendo lo mismo.

Además de a su propio certificado raíz, cada CA raíz puede tener certificados emitidos por otros CAs; genéricamente, estos se denominan 'CA cruzado' o simplemente 'certificados' cruzados y se pueden usar para varios propósitos. En particular, cuando un operador de CA establecido crea o adquiere una nueva raíz, comúnmente emiten un certificado de "puente" que autentica el nombre y la clave de la nueva CA de la raíz anterior, de modo que los verificadores (navegadores, etc.) que ya confían (los certificados emitidos en) la raíz antigua también confiarán en los certificados emitidos en la nueva raíz, sin esperar a que los almacenes de confianza de los verificadores se actualicen con la nueva raíz, que puede demorar desde unos pocos meses hasta muchos años. A la inversa, una nueva raíz puede "volver a autenticar" la (s) antigua (s), de modo que si se crea o modifica un verificador para admitir solo nuevas raíces con características de ostentación como SHA-2 o SHA-3 o Super Radiant Frabjosity, todavía aceptará pares que utilizan cadenas de certificados existentes y perfectamente servibles pero sin brillo.

Un cliente SSL / TLS (incluido el navegador HTTPS) en particular no se limita a la cadena de certificados de servidor enviado en el saludo, puede construir y usar cualquier cadena de confianza válida elige del servidor (hoja) cert a una raíz en la que confía. La coincidencia se realiza en el nombre completo del Asunto / Emisor, también conocido como 'Nombre distinguido', no solo de CommonName; aun así es fácil duplicar un nombre por malicia y posiblemente por accidente. Esto no es 'débil' porque la firma en el certificado de niño debe verificarse bajo la clave principal, que no puede ser falsificada a menos que la clave de la CA legítima esté comprometida, lo que no debería suceder, o alguien puede romper la criptografía, que para los tamaños utilizados actualmente (RSA 2048) requiere más materia y energía de la que existe en el sistema solar.

El sitio web GlobalSign, en la página de productos intermedios ExtendedSSL que se emiten bajo R2 (y me parece que probablemente fueron las primeras cosas emitidas bajo R2 y, por lo tanto, los primeros en enfrentar esta preocupación) describe y proporciona un R1 a R2 certificado cruzado No veo nada en el sitio web sobre R1 a R3, pero los registros de transparencia en crt.sh tienen tres y éste tiene el número de serie que publicaste; comprueba la huella digital de esa contra la que ves.

Pero si te refieres a Chrome en Windows, mis dos máquinas con Windows (8.1 y Vista) tienen R3 (huella digital que comienza en d6 9b). Puede consultar su tienda raíz (en Opciones de Internet / Contenido / Certificados / TrustedRoots, o en el complemento de MMC para certificados convenientemente disponible como certmgr.msc ) para ver si este certificado está allí, o solo R1. Si te refieres a otra plataforma pero no dijiste cuál, creo que Chrome siempre usa el almacén de confianza de la plataforma, por lo que depende de la plataforma y quizás de la versión / actualización. Si tiene ambas raíces, está permitido elegir cualquiera, pero creo lo he observado eligiendo la más corta. (Firefox, por otro lado, utiliza su propio almacén de confianza en todas las plataformas, y mi 38esr tiene GlobalSign R1 R2 R3 y R4 R5 y varios intermedios.)

    
respondido por el dave_thompson_085 12.05.2016 - 21:38
fuente

Lea otras preguntas en las etiquetas