Quiero saber si mis diversos proveedores cambiaron su certificado debido a Heartbleed, o si están usando un certificado vulnerable antiguo. ¿Cómo puedo saber eso? ¿La fecha "válida desde" también es la fecha de creación?
Quiero saber si mis diversos proveedores cambiaron su certificado debido a Heartbleed, o si están usando un certificado vulnerable antiguo. ¿Cómo puedo saber eso? ¿La fecha "válida desde" también es la fecha de creación?
Heartbleed tiene muy poca relación con los certificados. El único enlace es que una consecuencia potencial de un corazón explotado con éxito es una revelación de la clave privada del servidor SSL. Por lo tanto, puede querer ir al modo de paranoia completa y considerar que cualquier clave privada que se usó en un servidor vulnerable es tostada y debe reemplazarse. Esto es bastante extremista, y de alguna manera pierde el punto porque el mismo argumento se aplica a cada desbordamiento de búfer explotable de forma remota que se haya descubierto en el servidor, y hay varios de ellos cada año; señalar que el error "del corazón del corazón" no está justificado.
Ahora un certificado contiene dos "fechas de validez", llamadas notBefore
y notAfter
. Generalmente , la fecha notBefore
es cercana a la fecha en que se emitió el certificado, es decir, cuando la CA lo firmó. Normalmente, la fecha notBefore
es ligeramente anterior porque la CA desea producir un certificado que el propietario pueda usar de inmediato, incluso si los relojes de sus máquinas no son precisos. Por ejemplo, la CA de Microsoft ("Servicios de certificado"), de manera predeterminada, escribirá "14:35" como notBefore
tiempo si el certificado se emitió realmente a las 14:45. Otros CA pueden ir más lejos; Sé de una CA que usó la medianoche (de la noche anterior) como notBefore
time sistemáticamente.
Pero debe tener en cuenta que esta fecha califica la fecha de emisión del certificado , no de la clave . Es relativamente común "renovar" un certificado emitiendo un nuevo certificado (con nuevas fechas de validez) que contenga la clave pública y la identidad de same como en un certificado anterior. Para el escenario de "explotación de corazón" anterior, le preocupa si la clave privada potencialmente filtrada fue descartada y regenerada o no. Nada en el contenido del certificado le dirá nada sobre el momento en que se creó la clave privada (bueno, la clave privada existía antes del certificado, pero tal vez long antes, o tal vez no; el contenido del certificado ganó) no digas).
Vamos a ser un poco más real aquí. Heartbleed es solo otro error potencialmente explotable en una implementación; este no es el primero, y no el último. La probabilidad de que un servidor determinado se haya explotado entre el momento en que se descubrió el error y el tiempo en que se reparó el código del servidor es, en promedio, extremadamente baja. El error se convirtió en furor de la noche a la mañana, pero no se observó antes en la naturaleza.
Según la página de wikipedia y especificaciones un certificado no contiene información sobre la fecha de creación.
Toma mi cromo como ejemplo, en la url, hay un candado verde:
alhacerclicenelcandadoverde,verá:
cuando haga clic en "información del certificado", verá el certificado, haga clic en los detalles, puede ver:
el"no es válido antes" es cuando se crea el certificado. En realidad, en este caso, ya que Yahoo está afectado, su certificado se emite hoy mismo.
Mientras tanto, puede encontrar cualquier sitio afectado aquí , he probado algunos de ellos, algunos de los certificados se actualizan, mientras que otros todavía no lo están.
Lea otras preguntas en las etiquetas certificates heartbleed