El CA/Browser Forum ha votado para que las extensiones ACME CAA sean obligatorias a partir de marzo de 2027. Este cambio es una de las últimas piezas que faltaban para respaldar una validación de dominio sólida y validada criptográficamente en Web PKI. En esta publicación de blog, analizamos por qué Web PKI no ofrece suficiente garantía para sitios web de alto perfil, y cómo DNSSEC, ACME y CAA pueden combinarse para lograr una validación criptográfica sólida de la emisión de certificados.
Convergencia de DNSSEC y Web PKI
No a todos les gusta DNSSEC, pero proporciona una funcionalidad de seguridad importante que no podemos obtener en ningún otro lugar. Las empresas que lo habilitan en sus nombres de dominio logran la integridad de la resolución DNS. Algunas personas argumentan que Web PKI funciona bien, y así es, pero solo para el caso de uso común: proteger sitios web que no están bajo una amenaza seria. En resumen, los sitios web de alto perfil necesitan una mejor seguridad.
Durante mucho tiempo, los defensores de DNSSEC argumentaron que podría reemplazar a Web PKI. Su razonamiento era que, una vez que se logra la integridad de la resolución DNS, se obtiene una propiedad de seguridad sobre la cual se puede construir para hacer que los certificados X.509 funcionen sin CAs. Esto es cierto, pero solo en teoría. En la práctica, DNSSEC tiene una variedad de problemas de diseño y operativos que dificultan su amplia adopción. Como resultado, después de muchos años, el soporte para esta tecnología está lejos de donde debería estar. Web PKI y las CAs llegaron para quedarse.
Aun así, las organizaciones que necesitan una seguridad pública X.509 robusta no tienen otra opción que implementar DNSSEC por sus características únicas.
En 2025, el CA/Browser Forum, el organismo que rige la emisión de certificados, decidió incorporar la validación de DNSSEC en el proceso de validación de dominio. El requisito se volvió obligatorio en marzo de 2026 y, por primera vez, hizo posible una validación criptográfica sólida de la emisión de certificados.
Debilidades en la raíz de Web PKI
Web PKI es la PKI pública más estrictamente gestionada, con reglas y controles elaborados. Es un ecosistema que hemos pasado décadas mejorando. Sin embargo, en su núcleo, tiene dos problemas importantes. Estos hacen que el sistema sea más fácil de usar, pero pagamos ese precio con requisitos de seguridad más laxos.
En primer lugar, no existe autenticación del solicitante del certificado. Cualquier persona en el mundo puede solicitar un certificado para cualquier nombre de dominio; si el proceso de validación tiene éxito, el certificado se emitirá al solicitante, incluso si el propietario del dominio no lo autoriza.
En segundo lugar, cuando se solicita un certificado, la CA realiza la validación de dominio a través de BGP, DNS y tráfico de red no seguros. Cualquiera que pueda interferir con alguno de estos tres elementos puede romper la validación de dominio.
Si añadimos DNSSEC a esta combinación, eso ayuda a asegurar el DNS, pero los dos aspectos restantes (BGP y tráfico de red en texto plano) siguen siendo inseguros. Necesitamos lograr algo aquí: tomar las decisiones clave a través de DNSSEC y evitar el uso de cualquier otro método.
Certification Authority Authorization
Las debilidades en Web PKI pueden abordarse utilizando un estándar llamado Certification Authority Authorization (CAA), definido en RFC 8659. CAA está diseñado para permitir que los propietarios de dominios publiquen sus políticas de emisión de certificados.
La versión básica de CAA ha sido obligatoria desde septiembre de 2017, pero es insuficiente para nuestras necesidades. Existe otro documento (RFC 8657) que conecta el protocolo ACME para la emisión automatizada de certificados con CAA, añadiendo soporte para permisos de grano fino.
Con las extensiones ACME CAA, podemos resolver ambos problemas que describimos anteriormente, con la ayuda de un único registro de recurso CAA en nuestro DNS que se ve algo así:
example.com. CAA 0 issue "letsencrypt.org;
accounturi=https://acme-v02.api.
letsencrypt.org/acme/acct/1726001367;
validationmethods=dns-01"¿Qué hace esto?
A la izquierda, vemos el nombre de dominio para el cual queremos controlar la emisión de certificados, en este caso, example.com. A la derecha, tenemos tres controles. El primero es la identidad de una CA que tiene permitido emitir certificados para el nombre de dominio, en este caso, letsencrypt.org.
El segundo control es la instrucción accounturi, que restringe la emisión únicamente a la cuenta ACME indicada. Dado que ACME siempre utiliza cifrado y autenticación criptográfica sólida para las cuentas ACME, esta sección garantiza que solo los usuarios autorizados puedan solicitar certificados para este nombre de dominio.
El tercer control es la instrucción validationmethods, que restringe la emisión para usar únicamente un método de validación de dominio basado en DNS. Cuando DNSSEC está habilitado para un nombre de dominio, esta sección garantiza que todas las operaciones de validación de dominio sean criptográficamente seguras. Con esto, ya no nos preocupamos por otros métodos inseguros; la CA nunca los aceptará en primer lugar.
¿Podemos usar las extensiones ACME CAA ahora?
Las extensiones ACME CAA existen desde 2019, y algunas CAs (por ejemplo, Let's Encrypt, Google Trust Services y otras) ya las admiten. Entonces, en teoría, podrías haber tenido controles de emisión más sólidos desde marzo de 2026, cuando DNSSEC se volvió obligatorio para la validación de dominio. En la práctica, hasta que una función se incorpora en los Baseline Requirements, siempre existe reticencia por parte de las CAs a comprometerse por completo. Esto se debe a que cada nueva función aumenta su carga de trabajo y hace su labor más compleja. El incumplimiento de una política escrita podría dar lugar a la emisión de un certificado.
El equipo de Chrome ha sido durante mucho tiempo un defensor de la automatización. El soporte para la automatización ha sido una parte central de su Root Program Policy y, dentro de ella, los requisitos para ACME y las extensiones ACME CAA. En febrero de 2026, la política se modificó para exigir el soporte de ACME CAA a todas las CAs que admiten ACME.
En mayo de 2026, el CA/Browser Forum votó (en la Ballot SC-098v2) para extender formalmente el soporte de CAA y hacer que las extensiones ACME CAA (RFC 8657) sean obligatorias para todas las CAs, a partir de marzo de 2027.
Puedes usar las extensiones ACME CAA hoy mismo si trabajas con CAs que las admitan. A partir del próximo año, esta función será ampliamente compatible, y tendrás una variedad de CAs entre las cuales elegir.
Ivan Ristic is the Chief Scientist for Red Sift and former founder of Hardenize. Learn more about how Red Sift helps organizations with their Certificate Monitoring.