Resumen

  • DigiCert reconoció que algunas validaciones de dominio por CNAME se ejecutaron sin el prefijo de guion bajo que exige el método, un defecto que según ella afectó a cerca del 0,4 % de las validaciones de dominio aplicables.
  • Después se aplicó a sí misma la regla de revocación en 24 horas del CA/Browser Forum, recalculó el plazo desde otro evento de inicio y aplazó la revocación hasta 120 horas, hasta el 3 de agosto de 2024 a las 19:30 UTC.

La validación de control de dominio es el punto en que una solicitud deja de ser una pretensión y se convierte en un certificado. La autoridad comprueba que quien pide el certificado controla de verdad el nombre y entonces firma. Ese control es código: puede escribirse bien, revisarse bien y aun así no hacer lo que la norma dice que debe hacer.

El camino CNAME de DigiCert hacía otra cosa. «Recently, we learned that we did not include the underscore prefix with the random value used in some CNAME-based validation cases», escribió la empresa en su propia página del incidente (página del incidente de DigiCert).

El guion bajo no es decoración. En una validación por CNAME el solicitante publica un valor aleatorio en un registro DNS bajo una etiqueta con prefijo, y la autoridad lo lee. Sin el prefijo, la comprobación ejecutada ya no es la comprobación especificada. DigiCert sitúa el alcance en torno al 0,4 % de las validaciones de dominio aplicables (página del incidente de DigiCert). Ese porcentaje es la cifra que publicó la propia operadora. Ningún recuento independiente de certificados o clientes afectados aparece en el material examinado aquí.

Y llega la parte que hace que este expediente valga la pena. La detección fue de DigiCert. La divulgación también: en su página, con sus palabras. Y la aplicación de la regla, igual.

El 29 de julio de 2024 a las 02:17 UTC la empresa presentó un informe preliminar del incidente; a las 22:36 UTC del mismo día envió el aviso de revocación y afirmó: «The 24-hour revocation rule applies in this circumstance as the issue impacts domain validation» (Mozilla Bugzilla 1910322). El texto de los Requisitos Básicos del CA/Browser Forum no se consultó para este reportaje: la regla aparece aquí solo tal como la caracteriza DigiCert, y nada de lo que sigue concluye que la prórroga cumpliera o incumpliera esa norma.

El documento siguiente hace visible el reloj y, de paso, lo convierte en una decisión. «The 24 hours expired at 22:36 - 24 hours from when we had the serial numbers» (Mozilla Bugzilla 1910805). Esa frase fija un plazo y revela, en el mismo movimiento, que descansa en una elección: qué evento abre las veinticuatro horas. El informe de DigiCert señala la ambigüedad sin resolverla.

Lo que vino después no fue un plazo incumplido. Fue un plazo trasladado. El mismo informe registra la decisión de retrasar la revocación hasta 120 horas, tomada tras conversaciones sobre el impacto en clientes, posibles acciones legales y circunstancias excepcionales (Mozilla Bugzilla 1910805). Ningún tercero aparece aprobando, ordenando o revocando esa decisión.

El plazo de reemplazo aterrizó en la página de estado: «All certificates impacted by this incident, regardless of circumstances, will be revoked no later than Saturday, August 3rd 2024, 19:30 UTC» (DigiCert Status). La misma cronología indica que los certificados TLS identificados se revocaron el 3 de agosto de 2024 hacia las 19:30 UTC. Son las marcas de tiempo de la operadora. No se obtuvo confirmación independiente de la revocación de los números de serie afectados, así que el registro de revocación es aquí la palabra del obligado sobre el trabajo del obligado.

Hay un último elemento que merece una segunda mirada, porque muestra qué es en realidad una página pública de incidentes. La página se publicó el 29 de julio de 2024, lleva la marca de una actualización del 4 de agosto de 2024 y hoy pide a los clientes afectados que reemplacen sus certificados antes del 9 de agosto de 2024 a las 20:30 UTC (página del incidente de DigiCert). Esa instrucción es una actualización posterior, no el plazo original. Quien la lea hoy ve la versión asentada de un documento que se reescribió mientras el incidente seguía abierto.

Lo que no está en ese expediente es un veredicto externo. Ninguna medida de un programa raíz de Mozilla o de un fabricante de navegadores, ninguna votación y ninguna consecuencia posterior aparece en los cuatro documentos examinados para este análisis —la página del incidente de DigiCert, sus dos informes en Bugzilla y su historial de estado— y este texto no afirma ningún resultado sancionador.

Las partes fiables de esta reparación son reales. Un número de serie revocado se observa, un certificado caducado no conecta, una instrucción de reemplazo se puede seguir. Las partes que no se pueden comprobar desde fuera son justo las que decidieron el calendario: qué evento abrió el reloj, por qué la prórroga llegó a cinco días y no a uno, y si alguna autoridad competente sobre la regla dio su visto bueno. DigiCert, Inc. tiene una ficha en el directorio de esta publicación; la ficha describe una huella institucional, no un juicio sobre prácticas de validación.

El expediente muestra a una operadora que divulgó rápido, defendió su caso en público y luego cumplió el plazo que ella misma se había escrito. También muestra que ese plazo se movió porque el obligado lo movió.