Let’s Encrypt tuvo una tasa de errores más alta durante 90 minutos hoy

Impacto de la interrupción y semántica de la página de estado

  • El incidente fue un período de ~90 minutos de errores de emisión elevados debido a la red ascendente, no una interrupción de todo el día.
  • El personal de Let’s Encrypt (publicando a título personal) dice que la mayoría de las solicitudes siguieron teniendo éxito; algunos usuarios informan de repetidos 400/500 y de cero renovaciones exitosas durante esa ventana.
  • Confusión sobre “Degraded Performance”: algunos lo leen como un fallo casi total; otros señalan que el lenguaje de la página de estado a menudo minimiza problemas serios.
  • Se critica que el banner de estado estuviera en verde durante un “Active Incident”, especialmente en móvil donde el texto de estado detallado queda fuera de la pantalla.

Vigencias de certificados más cortas frente a revocación

  • Debate sobre el impulso hacia vigencias cada vez más cortas (90 días → 45 días → incluso días).
  • Un lado: los periodos más cortos limitan el daño por claves robadas y reducen las CRL; la expiración es parte central del modelo.
  • El otro lado: renovaciones más frecuentes aumentan la dependencia del tiempo de actividad de la CA y la fragilidad de la infraestructura; en su lugar, debería arreglarse la revocación.
  • La revocación hoy se considera ampliamente rota, aunque algunos sostienen que mecanismos más nuevos (p. ej., CRLite en Firefox) resuelven en gran medida esto, a la espera de una adopción más amplia por parte de los proveedores.

Higiene operativa y automatización

  • Muchos destacan que los clientes deberían renovar con bastante antelación a la expiración (p. ej., al día 60 de 90) y con reintentos/backoff, haciendo que las interrupciones breves no supongan nada.
  • Críticas a configuraciones que intentan renovar solo poco antes de expirar; se compara con usar un pasaporte que técnicamente sigue siendo válido pero que en la práctica es inutilizable cerca de su vencimiento.

Alternativas y riesgo de centralización

  • Algunos ven a Let’s Encrypt como un punto único de fallo de facto para gran parte de la web; otros responden que existen CA alternativas (ZeroSSL, Google Trust Services, etc.).
  • Se cuestiona un cambio práctico en una crisis: falta de conmutación por error integrada, posibles picos de carga en otras CA y la complejidad de servir múltiples certificados por clave.
  • Críticas más amplias apuntan al modelo de la PKI web y a la dependencia de CA con sede en EE. UU.; las propuestas incluyen claves autofirmadas publicadas en DNS o una regulación más fuerte de los intermediarios de red.

Gestión de certificados caducados por parte de los navegadores

  • Hay desacuerdo sobre si los navegadores deberían suavizar los errores para certificados que acaban de expirar.
  • Algunos argumentan que los fallos duros son necesarios para forzar una automatización adecuada y evitar la complacencia en seguridad; otros creen que advertencias más matizadas y basadas en el tiempo podrían mejorar la usabilidad sin gran riesgo.