DigiCert revocará los certificados que no tuvieran la Verificación de control de dominio (DCV) adecuada. Antes de emitir un certificado a un cliente, DigiCert valida el control o la propiedad del cliente sobre el nombre de dominio para el que solicita un certificado utilizando uno de varios métodos aprobados por CA/Browser Forum (CABF). Uno de estos métodos depende de que el cliente agregue un registro DNS CNAME que incluye un valor aleatorio que le proporciona DigiCert. Luego, DigiCert realiza una búsqueda de DNS para el dominio y verifica el mismo valor aleatorio, demostrando así el control del dominio por parte del cliente.
Existen varias formas válidas de agregar un registro CNAME de DNS con el valor aleatorio proporcionado para este propósito. Uno de ellos requiere que el valor aleatorio tenga como prefijo un carácter de subrayado. El prefijo de guión bajo garantiza que el valor aleatorio no pueda colisionar con un nombre de dominio real que utilice el mismo valor aleatorio. Si bien las probabilidades de que eso suceda son prácticamente insignificantes, la validación aún se considera no conforme si no incluye el prefijo de guión bajo.
Recientemente, supimos que no incluimos el prefijo de guión bajo con el valor aleatorio utilizado en algunos casos de validación basados en CNAME. Esto afectó aproximadamente el 0,4 % de las validaciones de dominio aplicables que tenemos vigentes. Según las estrictas reglas de la CABF, los certificados con un problema en la validación de su dominio deben ser revocados dentro de las 24 horas, sin excepción.
Acción requerida por el cliente
Los clientes afectados han sido notificados y deben reemplazar sus certificados dentro de las 24 horas. Inicie sesión en su cuenta DigiCert para ver los certificados afectados y los certificados de reemisión/nueva clave.
¿Cómo vuelvo a emitir certificados en CertCentral?
- Inicie sesión en su cuenta de CertCentral y vea el banner del incidente de revocación de CNAME cuando inicie sesión por primera vez para ver los certificados afectados.
- Navegue a la página Certificados > Pedidos y localice sus certificados afectados.
- Genere una nueva Solicitud de firma de certificado (CSR).
- En la página de detalles del N.º de pedido de cada certificado , en el menú desplegable Acciones del certificado , seleccione Reemitir certificado .
- Complete los pasos de validación adicionales requeridos.
- Instale su certificado SSL/TLS reemitido.
Si utiliza una solución de gestión de certificados como Trust Lifecycle Manager , consulte sus instrucciones sobre cómo automatizar el reemplazo de los certificados afectados.
Si tiene alguna pregunta, comuníquese con su administrador de cuentas o comuníquese con el soporte de DigiCert utilizando la información proporcionada en su cuenta de CertCentral. También puede comunicarse con nuestro soporte directamente al +1 801-770-1718.
Detalles técnicos
Los navegadores requieren que las autoridades certificadoras verifiquen cada dominio incluido en una solicitud de certificado TLS antes de emitir un certificado. Uno de los métodos permitidos de DCV se llama “Método 7” o “verificación basada en DNS”.
El requisito básico de CABF establece: “ 3.2.2.4.7 Cambio de DNS Confirmación del control del solicitante sobre el FQDN confirmando la presencia de un valor aleatorio o token de solicitud en un registro DNS CNAME, TXT o CAA para 1) un dominio de autorización Nombre; o 2) un Nombre de Dominio de Autorización que tiene como prefijo una Etiqueta de Dominio que comienza con un carácter de subrayado ”.
El método 7 verifica el control de un dominio haciendo que el propietario del dominio agregue un registro de recurso DNS con un valor aleatorio o un token de solicitud. Los propietarios de dominios pueden agregar el valor en el registro CAA, TXT o CNAME. Cuando se utiliza un registro CNAME, existen varias formas de agregar el registro. Por ejemplo, si se solicita un certificado para "foo.example.com", se puede agregar un registro CNAME DNS válido de las siguientes tres maneras:
- “ _randomValue .foo.example.com CNAME dcv.digicert.com”
- “foo.example.com CNAME valor aleatorio. dcv.digicert.com”
- “_dcv.foo.example.com CNAME valor aleatorio. dcv.digicert.com”
Tenga en cuenta que en el Caso 1, se requiere un prefijo de guión bajo ('_') con randomValue, mientras que en los Casos 2 o 3, no es necesario. El requisito del prefijo de guión bajo en el Caso 1 se basa en RFC1034 , que requiere que los nombres de dominio comiencen con un carácter alfanumérico. Incluir un guión bajo significa que el subdominio utilizado para la validación nunca podrá coincidir con un dominio real. No incluir el guión bajo se considera un riesgo de seguridad porque existe la posibilidad de que se produzca una colisión entre un dominio real y el subdominio utilizado para la verificación. Aunque la posibilidad de una colisión es extremadamente baja porque el valor aleatorio tiene al menos 150 bits de entropía, todavía existe una posibilidad. Debido a que existe una probabilidad limitada de colisión, la revocación es estrictamente necesaria según las reglas de la CABF.
La documentación proporcionada por DigiCert a los clientes para el Caso 1 no especifica explícitamente que se requiera el prefijo de guión bajo. Como resultado, las validaciones de dominio que utilizaron este método donde los clientes no agregaron el prefijo de guión bajo no cumplieron.
Según los requisitos básicos de CABF, cualquier incumplimiento de la validación de dominio requiere la revocación de los certificados emitidos en 24 horas:
“ 4.9.1.1 Razones para revocar un Certificado de Suscriptor […] Con la excepción de los Certificados de Suscriptor de corta duración, la CA DEBE revocar un Certificado dentro de las 24 horas y utilizar la CRLRazón correspondiente (consulte la Sección 7.2.2) si uno o más de los ocurre lo siguiente:
5. La CA obtiene evidencia de que no se debe confiar en la validación de la autorización o control de dominio para cualquier Nombre de Dominio Totalmente Calificado o dirección IP en el Certificado (CRLReasón #4, reemplazada). "
CABF considera cualquier problema con la validación del dominio como un problema grave y requiere acción inmediata. El incumplimiento puede generar desconfianza en la autoridad de certificación. Como tal, debemos revocar todos los certificados afectados dentro de las 24 horas posteriores al descubrimiento. No se permiten prórrogas ni retrasos. Le pedimos disculpas si esto le causa una interrupción en el negocio y estamos listos para ayudarlo a validar su dominio y emitir certificados de reemplazo de inmediato.
Análisis de raíz de la causa
En agosto de 2019, comenzamos a modernizar nuestros sistemas de validación de dominios y organizaciones hacia una arquitectura basada en servicios con el objetivo de mejorar el rendimiento y simplificar los flujos de trabajo. El código heredado en CertCentral (nuestro portal público de emisión de certificados TLS) agregaba automáticamente un prefijo de guión bajo a valores aleatorios si un cliente seleccionaba la verificación basada en CNAME. Nuestra nueva arquitectura redirigió toda la validación a través de servicios separados en lugar de la estructura de código monolítica heredada. El código que agrega un prefijo de guión bajo se eliminó de CertCentral y se agregó a algunas rutas en el sistema actualizado. La adición del prefijo de subrayado no se separó en un servicio distinto. Una ruta a través del sistema actualizado no agregó automáticamente el guión bajo ni verificó si el valor aleatorio tenía un guión bajo agregado previamente.
La omisión de un prefijo de subrayado automático no se detectó durante las revisiones del equipo multifuncional que se produjeron antes de la implementación del sistema actualizado. Si bien teníamos pruebas de regresión implementadas, esas pruebas no nos alertaron sobre el cambio en la funcionalidad porque las pruebas de regresión se centraban en los flujos de trabajo y la funcionalidad en lugar del contenido/estructura del valor aleatorio. Otras rutas a través del sistema agregaban guiones bajos automáticamente o requerían que los clientes agregaran manualmente el valor aleatorio antes de completar la verificación. Desafortunadamente, no se realizaron revisiones para comparar las implementaciones de valores aleatorios heredadas con las implementaciones de valores aleatorios en el nuevo sistema para cada escenario. Si hubiéramos realizado esas evaluaciones, habríamos aprendido antes que el sistema no agregaba automáticamente el prefijo de guión bajo al valor aleatorio cuando era necesario.
El 11 de junio de 2024, ingeniería completó un proyecto de mejora de la experiencia del usuario que colapsó múltiples microservicios de generación de valor aleatorio en un solo servicio. Este servicio comenzó a incluir un prefijo de guión bajo antes de cada valor aleatorio, independientemente del método de validación que eligiera el usuario. Este proyecto permite a DigiCert simplificar el proceso de generación de valores aleatorios. Esto también redujo las llamadas de atención al cliente relacionadas con la adición manual del prefijo de guión bajo, corrigió un error en la visualización del estado de validación de CertCentral y, sin darse cuenta, aseguró que cada verificación basada en CNAME incluyera un prefijo de guión bajo para cada valor aleatorio. Como antes, no comparamos este cambio de UX con el flujo de subrayado en el sistema heredado.
Hace varias semanas, alguien se comunicó con nuestro alias de informe de problemas por correo electrónico para preguntarnos sobre los valores aleatorios utilizados en la validación. Aunque el periodista no proporcionó los números de serie de ningún certificado, DigiCert llevó a cabo una investigación preliminar. Esta investigación inicial no descubrió ningún problema con la generación o validación de valores aleatorios. Después de que el reportero solicitó revisiones adicionales (aún sin proporcionar ningún número de serie de certificado), DigiCert buscó orientación de participantes externos del CABF, quienes sugirieron que DigiCert realizara una revisión adicional. Tras una revisión adicional, DigiCert descubrió un problema relacionado con el prefijo de guión bajo para valores aleatorios. Luego, DigiCert inició este proceso de gestión de incidentes.
Acciones preventivas tomadas
Reconocemos el impacto que un incidente como este puede tener en nuestros clientes y socios. Para evitar que tales incidentes vuelvan a ocurrir, hemos tomado o tomaremos las siguientes acciones:
- Consolidación y revisión de todos los generadores de valores aleatorios en DCV [Terminado]
- Simplificación de UX para que los clientes no necesiten conocer formatos de valores aleatorios específicos según su elección del método DCV [Completado]
- Los miembros del equipo de cumplimiento estarán integrados en todos los equipos de sprint de la Autoridad de certificación (CA) y la Autoridad de registro (RA) (incluidas las revisiones de diseño/arquitectura) y revisarán todos los cambios aplicables [Finalizado]
- Aumente la cobertura de las pruebas más allá de las pruebas funcionales en todos los flujos de trabajo de validación con casos de prueba automatizados basados en el cumplimiento [En progreso; ETA 5 de agosto de 2024]
- DCV de código abierto para revisión de la comunidad [En progreso; ETA 1 de noviembre de 2024]
No hay comentarios.:
Publicar un comentario