Resumen

  • Let's Encrypt informó el 29 de febrero de 2020 de un fallo en Boulder, su software de autoridad de certificación, en la forma de reverificar registros DNS CAA para solicitudes con varios nombres [1].
  • RFC 8659 define CAA como un registro DNS que permite al titular de un dominio indicar qué autoridades de certificación pueden emitir certificados para ese dominio [2].
  • La cuestión de responsabilidad no era si Let's Encrypt soportaba CAA en general. Era si cada nombre cubierto por una validación reutilizada recibió una comprobación reciente antes de la emisión [1].
  • La página oficial de Let's Encrypt describe el servicio como una autoridad de certificación proporcionada por Internet Security Research Group. En producción, BTW enlaza este tipo de cobertura con la entidad existente internet-society, sin cambiar el sujeto factual del incidente [3].

Qué ocurrió

El aviso de Let's Encrypt describe un defecto descubierto el 29 de febrero de 2020 en Boulder. Boulder normalmente comprueba los registros CAA cuando valida el control del dominio por parte de un suscriptor. Como algunas validaciones pueden seguir siendo utilizables después del primer control, la autoridad puede necesitar comprobar CAA otra vez justo antes de emitir. Let's Encrypt explicó que la regla aplicable exigía una comprobación CAA dentro de las ocho horas previas a la emisión cuando la validación era más antigua [1].

El modo de fallo fue concreto. Cuando una solicitud de certificado contenía varios nombres que necesitaban reverificación CAA, Boulder seleccionaba un nombre y lo comprobaba varias veces, en lugar de comprobar cada nombre relevante. Así, una solicitud podía pasar aunque uno o más nombres no hubieran recibido la comprobación DNS fresca esperada. Let's Encrypt dijo que confirmó el fallo a las 03:08 UTC, detuvo la emisión a las 03:10 UTC, desplegó una corrección a las 05:22 UTC y después reanudó la emisión [1].

Ese calendario importa porque la responsabilidad de una autoridad de certificación no se demuestra solo afirmando que el código fue corregido. También hay que identificar los certificados potencialmente afectados, avisar a los suscriptores, permitir el reemplazo y ejecutar la revocación. El expediente público combinó identificación del defecto, reparación de la emisión y limpieza del ciclo de vida de los certificados [1].

Por qué CAA es un control DNS

RFC 8659 presenta CAA como un registro DNS con el que el titular de un dominio especifica qué autoridades pueden emitir certificados. También lo describe como un control adicional para reducir el riesgo de emisión no prevista [2]. En la práctica, CAA es una frontera entre el estado DNS publicado por el operador del dominio y la decisión de emisión de la autoridad.

Para una lectura de riesgo y responsabilidad, lo importante no es la marca del certificado. Es la cadena de autoridad operativa: el propietario publica CAA, la infraestructura DNS devuelve el estado visto por la CA, el software interpreta ese estado y la automatización del suscriptor espera que la renovación funcione a escala. Si todo se resume como «validación aprobada», la frontera de evidencia se vuelve demasiado blanda.

Límite del directorio

El sujeto directo del artículo es Let's Encrypt y el servicio ISRG descrito por las fuentes oficiales. El enlace de directorio usa entity:internet-society porque es la entidad publicada disponible y ya usada en producción para una cobertura anterior de Let's Encrypt. Eso no afirma que Internet Society tomara la decisión de ingeniería de Boulder. Si una puerta propietaria exige una entidad ISRG directa, el candidato debe cerrarse con precisión antes de publicar.

Evidencia esperada

Un cierre defendible debe mostrar qué nombres requerían nueva comprobación CAA, qué respuestas DNS se usaron, qué camino de software tomó la decisión, qué certificados quedaron en el perímetro, cómo se notificó a los suscriptores y cómo se probó la no repetición. Sin esas pruebas, el arreglo queda como una afirmación privada en una cadena de confianza pública.

Fuentes

  1. https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591
  2. https://www.rfc-editor.org/rfc/rfc8659
  3. https://letsencrypt.org/about/