Certificado verificado usando dos rutas diferentes

Question

Certificado verificado usando dos rutas diferentes

#1 de Thomas Pornin (6 votos)

4

StartSSL tiene un certificado intermedio que utilizan para firmar sus certificados EV: sub.class4.server .ca.pem . openssl x509 muestra al emisor de este certificado como / C = IL / O = StartCom Ltd./OU=Secure Digital Certificate Signing / CN = StartCom Certification Authority . Esto coincide con el certificado que distribuyen como su CA raíz: ca.pem .

Sin embargo, Firefox / Mozilla incluye dos certificados con ese tema. Uno es el mismo que el certificado que distribuye StartSSL. El otro ^{(adjunto a continuación)} es verificable diferente; por ejemplo, el número de serie del primero es 1, mientras que el número de serie del último es 45. Editar: Después de más investigaciones, resulta que este es el mismo que el certificado que StartSSL se distribuye como ca-sha2.pem .

Si uso openssl verify para verificar sub.class4.server.ca.pem contra ca.pem , funciona:

% openssl verify -CAfile ca.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: OK

Sin embargo, resulta interesante que si lo comparo con el certificado de Firefox / Mozilla, todavía funciona:

% openssl verify -CAfile ca-ff.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: OK

Solo para asegurarme de que algo más no estaba entrando allí y ensuciar mis resultados, lo probé contra un certificado que sabía que era el incorrecto:

% openssl verify -CAfile ca-wrong.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Extended Validation Server CA
error 20 at 0 depth lookup:unable to get local issuer certificate

Eso deja dos posibilidades: o bien openssl verify no está verificando la firma real y confiando únicamente en el Asunto del Emisor (posiblemente porque lo estoy usando incorrectamente), o de alguna manera este certificado puede verificarse con dos certificados diferentes.

Para verificar la primera posibilidad, creé un certificado autofirmado con la misma información del emisor y lo usé para verificar el certificado intermedio:

% openssl verify -CAfile ca-fake.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Extended Validation Server CA
error 20 at 0 depth lookup:unable to get local issuer certificate

Así que parece que openssl verify no es tan fácil de engañar.

Entonces se me ocurrió que dos certificados diferentes podrían verificar el mismo certificado secundario si usaban la misma clave RSA, y encontré que el módulo de clave pública reportado para los dos certificados es el mismo.

¿Es preocupante en absoluto que StartCom haya usado aparentemente la misma clave RSA para dos certificados diferentes? Me parece una mala idea, pero solo soy un aficionado.

Para conveniencia de cualquier persona que busque esto, aquí está el certificado adicional que tiene Firefox:

digital-signature certificates certificate-authority rsa x.509

pregunta wfaulk 27.03.2014 - 17:58

fuente

1 respuesta

Lea otras preguntas en las etiquetas digital-signature certificates certificate-authority rsa x.509

¿Uso de sal para la seguridad de Spring? Autenticación de Windows e identificadores de sesión

score 6 · Accepted Answer

En lo que respecta a X.509, no hay ningún problema en tener varios certificados con la misma clave pública. El proceso de validación se describe con todos los detalles aquí ; en pocas palabras, se verifica que:

cada certificado de la cadena es válido actualmente (en lo que respecta a las fechas de inicio y finalización de la validez);
la firma en cada certificado es correcta para el contenido del certificado y la clave pública en la CA emisora;
el DN del emisor de cada certificado coincide con el DN del sujeto de su CA emisora;
todas las extensiones de certificado (políticas de certificado, restricciones de nombre ...) son correctas.

Tener la misma clave pública en dos certificados distintos no es un problema. Cada certificado establece un enlace entre una clave pública y una identidad . Si tiene diez certificados que afirman el mismo enlace, tanto mejor.

En la práctica, tener varios certificados con el mismo nombre y clave es el resultado normal de las renovaciones. Cuando caduque un certificado, es posible que desee mantener el mismo par de claves para el nuevo certificado.

En su caso, la situación es ligeramente diferente porque los certificados involucrados son certificados raíz, es decir, no son certificados "reales": no son emitidos por una CA; son recipientes convenientes para anclajes de confianza . Sin embargo, una comparación de ambos certificados (con openssl x509 -text -noout -in ca.pem ) revela la razón por la cual hay dos (y es una muy mala razón): esto es parte de un anatema general predicho en SHA-1. De hecho, un certificado raíz es a menudo autofirmado (porque hay un campo no opcional para una firma en el formato X.509), y un algoritmo de firma comienza por una función hash. El certificado "antiguo" (el archivo ca.pem de StartSSL) declara una firma con SHA-1, mientras que el certificado "nuevo" (de las entrañas de Firefox) usa una firma basada en SHA-256.

Otra diferencia es que el certificado "nuevo" no incluye la URL para la descarga de CRL, lo cual es correcto ya que un certificado raíz, por definición, no puede ser revocado por su CA emisora.

Además de los números de serie, el algoritmo hash y la URL para la descarga de CRL, los dos certificados son idénticos; Contienen el mismo nombre, clave pública y fechas de validez. Creo que el principal impulso aquí es el rechazo ciego, sistemático y exagerado de SHA-1. Esta es una mala razón porque:

SHA-1 no está roto aún, en particular para firmas, que funcionan más en las imágenes previas que en las colisiones.
La firma en un certificado raíz no tiene sentido, por lo que no importa si la función hash declarada es SHA-1, SHA-256, MD5 o FOOBAR42.