¿Por qué emitir un certificado SSL que caduca en 2037?

11

En Firefox, si veo la Autoridad de certificación raíz universal de Verisign, noto que caduca en 2037.

( Settingspestaña -> advanced-> view certificates-> VeriSign Universal Root Certification Authority-> View.)

¿Por qué tiene una vida útil de 23 años?
¿Por qué no lo fijarían para que caduque antes? ¿O después?

ssl-certificate certificate-authority user3298687
fuente
55
Como dice la respuesta, para evitar tener que reemplazar el certificado raíz durante el mayor tiempo posible. Es probable que alguien le haya puesto un vencimiento de 25 o 30 años, porque es un dolor tener que reemplazarlos y no proporciona ningún beneficio. Las probabilidades son mucho antes de que expire, tendrá que ser reemplazado por uno con una clave más larga (y tal vez un algoritmo criptográfico diferente, para el caso). Hago lo mismo con nuestros certificados SSL internos, solo porque no quiero tener que instalar otro certificado en $ [crappy_printer]. Establezca el período de caducidad a más largo que la vida útil del dispositivo, y el problema resuelto
HopelessN00b

Respuestas:

13

La caducidad se estableció en 2037 para evitar la posibilidad de encontrarse con el problema de la fecha del año 2038 de Unix . Básicamente, a principios de 2038, las fechas de Unix ya no caben en un entero de 32 bits firmado, por lo que usar una fecha justo antes de eso evita activar cualquier código que aún no se haya actualizado para solucionar el problema.

Los certificados raíz se llevan todos los certificados encadenados cuando caducan, por lo que desde una perspectiva práctica deben caducar después de cualquier certificado encadenado.

Brian
fuente
7

Si entiendo su pregunta, los certificados raíz de reemplazo tendrían que volver a implementarse en los clientes. Entonces, las probabilidades son que su vida útil se establece lo suficientemente lejos donde hay poca o ninguna posibilidad de que expire el certificado raíz.

MikeAWood
fuente
44
En cuanto a "¿Por qué 2037" (o, más ampliamente "¿Por qué no un tiempo de expiración 100 años?") - Es posible que haya restricciones técnicas en el juego , pero al menos en un reciente OpenSSL (0.9.8y, en un sistema de 64 bits) esto no fue un problema, así que probablemente solo sea "Lo hice durar ## años")
voretaq7
1
@ voretaq7 no es (solo) el problema con el procesamiento de bibliotecas, el problema es que el formato estándar y bien probado para las fechas anteriores a 2038 está utilizando UNIX epoch. Si desea establecer fechas posteriores, debe usar un formato de fecha diferente, y es posible que otras bibliotecas anteriores no lo admitan.
Hubert Kario
1
@HubertKario Sí, recuerdo que OpenSSL anteriormente tenía "problemas" con fechas más allá de la línea roja Y2038. Parecen haber resuelto dichos problemas, al menos en lo que respecta a mi caso de prueba (creé un certificado que expira dentro de 100 años y no se quejó) :-)
voretaq7
0

Definitivamente he visto implementaciones SSL de 32 bits en el error 2038, por lo que casi con certeza explica "por qué 'solo' 2037".

En cuanto a por qué no caducar antes? Bueno, uno de los propósitos originales de la expiración era evitar que un certificado comprometido fuera válido por demasiado tiempo, pero con toda sinceridad, eso no le da mucho. Ahora, por supuesto, tenemos listas de revocación de certificados, por lo que podemos invalidar con bastante facilidad un certificado que nos está causando problemas, por lo que no hay una obligación real de tener poco tiempo de vida.

Tom Newton
fuente