Resumen

  • El 9 de noviembre de 2015, Let’s Encrypt fijó un máximo de 90 días para reducir la vigencia útil tras una clave comprometida o una emisión errónea y empujar el HTTPS hacia la automatización. Renovar al día 60 dejaba cerca de un mes para que el operador recuperase a mano un recambio fallido mientras los suscriptores aprendían la nueva rutina.
  • La nota sobre la beta pública, tres días después, contabilizó más de 11.000 certificados emitidos durante la beta limitada y reconoció que la experiencia del cliente aún debía funcionar bien en muchas plataformas.

Análisis

Quien abre un sitio no recibe un certificado válido solo porque ayer todo funcionara. En la validación de rutas de la RFC 5280, la fecha actual debe estar dentro del intervalo del certificado. Cuando pasa notAfter, quien opera el sitio necesita emitir e instalar un reemplazo. Una fecha inscrita en el certificado se convierte en un plazo para mantener la conexión de confianza.

El 9 de noviembre de 2015, Josh Aas, director ejecutivo de Internet Security Research Group, explicó por qué Let’s Encrypt no emitiría certificados de más de 90 días. Atribuyó dos funciones al límite. Una clave privada robada o un certificado emitido por error conservaría menos tiempo su validez. Y los vencimientos frecuentes incentivarían la automatización, indispensable para que el HTTPS resultara fácil de mantener.

La recomendación de renovar cada 60 días concreta el diseño. Let’s Encrypt no pedía esperar hasta el último día. Quedaba aproximadamente un mes antes del máximo; el administrador todavía podía intervenir a mano. Aas explicó que el servicio era joven y que la automatización resultaba nueva para muchos suscriptores. El mes entre el objetivo del día 60 y el límite de 90 días daba al operador tiempo para detectar un recambio fallido e intervenir a mano.

El calendario aclara el momento de la decisión. El 12 de noviembre, Aas dijo que la beta limitada había empezado el 12 de septiembre y ya había emitido más de 11.000 certificados. La beta pública estaba prevista para el 3 de diciembre. El mismo aviso llamó a la automatización una pieza central de la estrategia y reconoció que la experiencia del cliente requería más trabajo para funcionar sin tropiezos en muchas plataformas. Había emisiones a escala de beta; el buen funcionamiento de la renovación todavía era una tarea pendiente.

El argumento era directo: los administradores no podían encargarse a mano de cada renovación en toda la Web. Si la emisión y el recambio eran automáticos, acortar la vigencia no añadía trabajo cotidiano a quien atendía un sitio. La medida de seguridad y el modelo de operación iban unidos: el reloj avanzaba más rápido y el cliente debía mantenerlo al día.

La intervención manual seguía disponible, pero era una salida de emergencia. El servicio normal dependía del cliente de renovación, de la tarea programada, de la compatibilidad con la plataforma y de que el nuevo certificado llegara realmente al servicio. El día 60 era la instrucción de calendario; automatizar era lo que podía convertirla en una rutina repetible.

La cifra de la beta cuenta certificados emitidos hasta el 12 de noviembre. No cuenta renovaciones fallidas ni exitosas. Una serie fechada de esos resultados permitiría saber si la ventana manual bastaba; los dos comunicados no la incluyen.

Fuentes