¿Por qué el certificado descargado muestra una fecha de finalización diferente en comparación con el mismo certificado cuando se ve en línea?

Question

¿Por qué el certificado descargado muestra una fecha de finalización diferente en comparación con el mismo certificado cuando se ve en línea?

#1 de zedman9991 (7 votos)
#2 de Tom Leek (7 votos)

6

Esto es una especie de seguimiento de mi pregunta anterior ¿Qué campos de un certificado sospechoso debo ver?

Chrome acaba de presentar el icono de advertencia contra el certificado presentado por enlace (siempre escribo la URL) porque no se pudo verificar el CRL . Por falta de algo mejor que hacer, descargué la cadena de certificados y me sorprendió ver una entrada caducada contra el certificado intermedio en la cadena.

El certificado de intermediario se emitió a www.verisign.com/CPS Incorp. por ref. LIABILITY LTD. (C) 97 Verisign

Los campos de validez en este certificado d / l son los siguientes

De: 17/04/1997

Hasta: 01/08/2004

Sin embargo, cuando se visualiza en el navegador, este certificado muestra una fecha de finalización del 25/10/2016

Esperemos que no sea motivo de preocupación, pero no puedo dejar de preguntarme ...

¿Por qué el certificado descargado muestra una fecha de finalización diferente en comparación con el mismo certificado en línea?

p.s. Intenté volver a descargar la cadena de certificados en una ubicación diferente y aún veo una fecha de caducidad de 2004.

public-key-infrastructure tls

pregunta Everyone 05.01.2012 - 13:06

fuente

2 respuestas

Lea otras preguntas en las etiquetas public-key-infrastructure tls

¿Esta llamada jQuery ajax es vulnerable a XSS? El inicio de sesión de la aplicación de Banca pierde información

score 7 · Answer 1

Dan Kamisky descubrió y escribió un blog sobre un tema muy similar hace tres meses en Facebook. Rastreó el problema a Facebook y envió algunos balanceadores de carga de prueba basados en certificados VeriSign caducados. Como siempre con sus escritos, la investigación está bien hecha y presentada en una excelente lectura. La conclusión en su caso es que no hubo amenaza. La entrada del blog es una excelente lectura enlace del blog

score 7 · Answer 2

En SSL / TLS, el servidor envía su certificado como parte de una cadena. El cliente debe determinar la clave pública del servidor y utilizarla para finalizar el protocolo de enlace.

La forma en que el cliente debe "adivinar" y "validar" la clave pública del servidor es completamente su asunto; La cadena de certificados enviada por el servidor es, nominalmente, puramente indicativa. Es un caso de: "hey, cliente, necesita conocer (y estar seguro de) mi clave pública; este conjunto de certificados podría serle de alguna utilidad". Según especificación SSL / TLS , la cadena enviada por el servidor debería ser adecuada para la validación, y un cliente tendría derecho a abortar la conexión si la cadena exacta enviada por el servidor no se valida; pero nada dice que el cliente debe usar esa cadena exacta, y ninguna otra.

En su caso, es plausible que Chrome, al validar el certificado del servidor, encuentre que uno de los certificados está obsoleto, pero logra validar el certificado del servidor utilizando otros certificados que Chrome conoce. (O bien ya los vio desde otra conexión anterior en algún lugar, o los conoce inherentemente). Tenga en cuenta que saber un certificado no es lo mismo que confiar en un certificado; no hay ningún problema de seguridad al tener acceso a un gran almacenamiento potencialmente inseguro para certificados intermedios de CA, ya que las firmas en estos certificados adicionales aún se verificarán con el uso (los certificados de CA intermedios son no certificados raíz).

Para resumir, el servidor de Facebook hace una cosa no válida, según RFC 5246, ya que envía una cadena de certificados que obviamente no es válida. El mismo RFC 5246 aún permite que los clientes se recuperen de forma transparente, siempre que puedan parchear la cadena con certificados más actualizados, y eso es lo que hace Chrome.