Los navegadores se desconectan de las zonas horarias y la renovación de los certificados de seguridad

2

El viernes por la noche (JST) estaba revisando el sitio web de una empresa que se ocupa del comercio de divisas. No hay problemas. El sábado por la mañana, intente volver al sitio, pero tanto Chrome como Safari dicen que no confían en el certificado de seguridad. Lo comprobé y la validación había expirado. Qué extraño.

Luego,estamañana,visitéelsitionuevamente,elcertificadoesválidoypuedoingresar(tantoenChromecomoenSafari)

Entoncesnotéunapeculiaridad.

Conelcertificadofallido,elavisodecíaqueelcertificadoexpiróelsábado13deagostode2016alas8:59:59JST.

Peroconelcertificadoválidodehoy,elavisodicequeelcertificadoesválidoapartirdel13deagostode201600:00:00GMT.

Hiceunaverificacióndeladiferenciahorariay8:59:59JSTes23:59:59GMT(nota:elReinoUnidoestáenhorariodeverano)

¿Se trata de un problema con la forma en que los navegadores comprueban la validez del certificado? ¿Siempre asumen que el tiempo de vencimiento es 23:59:59 y el tiempo de validez es 00:00:00, pero nunca verifica si hay una diferencia de zona horaria o una diferencia de verano?

    
pregunta mycowan 14.08.2016 - 00:49
fuente

2 respuestas

4

Supongo que el certificado del sitio web realmente caducó, y luego compraron uno nuevo y lo reemplazaron antes de que lo comprobaras nuevamente.

Cuando Comodo emite un certificado, la hora de "válida desde" se retrasa hasta las 00:00:00 UTC del día en que se emitió, y la hora de "válida hasta" es 23:59:59 del día en que vence. Así que el nuevo certificado podría haber sido emitido en cualquier momento del día 13 de agosto.

(Eso es solo la política particular de Comodo. Otras CAs lo manejan de manera diferente)

Es un poco tarde para probar esto ahora, pero puede buscar el dominio en una herramienta como Censys y ver si tienen una copia del certificado de ayer.

Línea de tiempo hipotética:

  1. 2016-08-12 21:00:00 JST (2016-08-12 12:00:00 UTC): Usted visita el sitio web con éxito. El certificado anterior caducará el 2016-08-13 08:59:59 JST (2016-08-12 23:59:59 UTC), 11:59:59 a partir de ahora. Los administradores de sistemas no tienen idea.
  2. 2016-08-13 08:59:59 JST (2016-08-12 23:59:59 UTC): El certificado anterior expira. Todos los administradores de sistemas están dormidos.
  3. 2016-08-13 10:00:00 JST (2016-08-13 01:00:00 UTC): visita el sitio web y recibe un error. El antiguo certificado expiró hace 01:00:01. Los administradores de sistemas todavía están dormidos.
  4. 2016-08-13 15:00:00 JST (2016-08-13 06:00:00 UTC): Los administradores de sistemas se activan, se dan cuenta de que lo hicieron estallar y se apresuran a reemplazar el certificado. La nueva es válida a partir del 2016-08-13 09:00:00 JST (00:00:00 UTC).
  5. 2016-08-14 07:00:00 JST (2016-08-13 22:00:00 UTC): vuelve a visitar el sitio web. El nuevo certificado es, por supuesto, válido.
respondido por el Matt Nordhoff 14.08.2016 - 02:23
fuente
2
  

¿nunca verificas si hay una diferencia de zona horaria o una diferencia de horario de verano?

La hora de caducidad de un certificado se establece en GMT (UTC). Lo que ve es la diferencia de cómo los diferentes navegadores presentan la hora de vencimiento del certificado, es decir, Safari lo transforma en JST (probablemente su zona horaria local) mientras que Chrome lo muestra en GMT. La comprobación en sí misma se realiza comparando ambas horas dentro de la misma zona horaria, es decir, comparando la hora local con la GMT antes de la verificación.

  

¿Siempre asumen que el tiempo de caducidad es 23:59:59 y el tiempo de validez es 00:00:00,

El tiempo de caducidad tiene una precisión de segundos y los navegadores lo verifican de esta manera. Además, algunas CA pueden establecer el tiempo de caducidad a las 23:59:59, otras no.

    
respondido por el Steffen Ullrich 14.08.2016 - 01:08
fuente

Lea otras preguntas en las etiquetas