Cómo configurar correctamente los registros CAA

Un registro Certification Authority Authorization (CAA) es uno de los controles de seguridad más sencillos que puede añadir a un dominio, y también uno de los más fáciles de configurar mal sin darse cuenta. Es un registro DNS que viene a decir: “solo estas autoridades de certificación pueden emitir certificados TLS para este nombre”. Desde septiembre de 2017, los Baseline Requirements del CA/Browser Forum obligan a toda autoridad de certificación de confianza pública a comprobar el CAA antes de emitir un certificado. Si el registro existe y no autoriza a esa CA, la solicitud debe rechazarse.

Eso convierte al CAA en una protección útil contra la emisión indebida: una cuenta comprometida en otra CA, un empleado descuidado que pide un certificado a un proveedor no aprobado o una CA cuya validación de dominio ha sido engañada. También significa que un registro CAA defectuoso puede detener sin avisar sus propias renovaciones de certificados. Esta guía recorre la sintaxis definida en la RFC 8659, las etiquetas que realmente usará, cómo buscan las CA los registros y cómo probarlo todo antes de que importe.

Qué contiene un registro CAA

La RFC 8659, publicada en 2019, sustituyó a la RFC 6844 original y es el estándar vigente. Todo registro CAA tiene tres partes:

• Flags: un número de 0 a 255. En la práctica se usa 0. El valor 128 activa el bit “issuer critical”, que indica a la CA que debe negarse a emitir si no entiende la etiqueta.
• Etiqueta (tag): el nombre de la propiedad, como issue, issuewild o iodef.
• Valor: una cadena entre comillas cuyo significado depende de la etiqueta; normalmente, el nombre de dominio de una CA.

En sintaxis de archivo de zona, un registro básico tiene este aspecto:

example.com.    3600    IN    CAA    0 issue "letsencrypt.org"

Puede publicar varios registros CAA en el mismo nombre. Cada registro issue añade una CA permitida más; se combinan, no se sobrescriben.

Las tres etiquetas que necesita conocer

issue

La etiqueta issue autoriza a una CA a emitir cualquier certificado para el nombre, incluidos los comodines, salvo que un registro issuewild diga lo contrario. Un valor especial formado por un solo punto y coma, ";", significa “no se permite ninguna CA”. Resulta útil para dominios que nunca deberían tener un certificado, como nombres aparcados o dominios usados solo para correo.

issuewild

La etiqueta issuewild se aplica únicamente a certificados comodín como *.example.com. Cuando existe al menos un registro issuewild, las CA ignoran issue en las solicitudes de comodín y usan exclusivamente issuewild. Un patrón habitual es permitir certificados normales de una CA y bloquear por completo los comodines:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild ";"

iodef

La etiqueta iodef proporciona una URL a la que una CA puede informar de una solicitud que rechazó por su política. Acepta direcciones mailto: y https:. Su soporte es opcional, así que considérelo una señal adicional y no un sistema de monitorización.

example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Identificadores CA de los proveedores habituales

El valor de un registro issue debe coincidir con el identificador que publica la propia CA, normalmente en su Política de Certificación o CPS. Equivocarse en esta cadena es la causa más frecuente de emisiones fallidas. Los identificadores siguientes están ampliamente documentados, pero consulte la documentación actual de su CA antes de confiar en ellos.

Recuerde que muchos servicios obtienen certificados en su nombre. Una CDN, un hosting gestionado de WordPress o un producto de seguridad de correo pueden usar una CA que usted nunca eligió directamente. Antes de restringir nada, averigüe qué CA utiliza cada proveedor que esté delante de su dominio.

Cómo encuentran las CA su registro: la subida por el árbol

Una CA no se limita a mirar el nombre exacto de la solicitud de certificado. La RFC 8659 define una búsqueda que empieza en el nombre solicitado y sube etiqueta a etiqueta. El primer nombre que devuelve un conjunto de registros CAA no vacío es el que cuenta, y la búsqueda se detiene ahí.

Para una solicitud de shop.eu.example.com, la CA comprueba en este orden:

1. shop.eu.example.com
2. eu.example.com
3. example.com
4. com

De ello se derivan dos consecuencias prácticas. Primera: un único conjunto de registros en el ápice suele proteger todos los subdominios, y por eso la mayoría de los dominios solo necesitan CAA en example.com. Segunda: un registro CAA en un subdominio sustituye por completo la política del ápice para ese subárbol; no se suma a ella. Si añade 0 issue "digicert.com" a eu.example.com, Let’s Encrypt deja de estar permitida allí aunque el ápice la autorice. Si no existe ningún registro CAA en toda la cadena, cualquier CA puede emitir.

Registros CNAME y CAA

Los CNAME son el punto donde el CAA se vuelve confuso. Cuando una CA consulta el tipo CAA de un nombre que es un CNAME, la resolución DNS normal sigue el alias y devuelve los registros CAA que existan en el destino. Si el destino tiene registros CAA, se usan para el nombre original.

Según la RFC 8659, si el destino del alias no tiene registros CAA, la CA continúa subiendo por el árbol del nombre original, no por los padres del destino. El comportamiento anterior de la RFC 6844, que también subía por el árbol del destino, se eliminó. Esto importa cuando www.example.com apunta a algo como example.cdn-provider.net:

• Si la CDN publica CAA en el destino, su política se aplica a su nombre www y nunca se llega a su registro del ápice.
• Si el destino no tiene CAA, la CA pasa a example.com y aplica su política del ápice.

Como no se pueden publicar otros registros junto a un CNAME en el mismo nombre, no es posible anular la política del destino en el propio alias. Si el CAA de un proveedor bloquea la CA que necesita, consulte al proveedor o use otra configuración de nombres de host.

Configuración paso a paso

1. Haga inventario de sus certificados. Anote cada nombre de host con TLS y qué CA lo emitió. Los registros de Certificate Transparency, como crt.sh, le ayudan a encontrar certificados que había olvidado.
2. Decida una política. Elija las CA que permitirá y si necesita comodines.
3. Publique los registros en el ápice. Añada un issue por CA, un issuewild opcional y un contacto iodef.
4. Empiece con un TTL bajo. Un TTL de 300 segundos le permite corregir errores rápidamente; súbalo cuando todo esté estable.
5. Pruebe una renovación. Lance una renovación de prueba (staging o dry-run) para confirmar que la CA sigue pudiendo emitir.

Un ejemplo completo para un dominio que usa Let’s Encrypt para la web y Sectigo para un comodín sería este:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "sectigo.com"
example.com.  3600  IN  CAA  0 issuewild "sectigo.com"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

Algunas CA admiten además parámetros adicionales definidos en la RFC 8657, como accounturi, para limitar la emisión a una sola cuenta ACME, y validationmethods, para permitir solo determinados tipos de validación. Refuerzan aún más la seguridad, pero confirme primero que su CA los admite.

Cómo probar los registros CAA con dig

Consulte siempre el DNS público en lugar de fiarse del panel de su proveedor. Estos comandos muestran lo que verá una CA:

dig example.com CAA +short
dig www.example.com CAA +short
dig @1.1.1.1 example.com CAA
dig +trace example.com CAA

Una respuesta correcta para el ejemplo anterior tiene este aspecto:

0 issue "letsencrypt.org"
0 issuewild ";"
0 iodef "mailto:security@example.com"

Que un subdominio no devuelva nada es normal; la CA subirá al nombre padre. Lo que no quiere ver es un SERVFAIL. Una CA que no obtiene una respuesta definitiva suele negarse a emitir, y algunos servidores DNS y dispositivos antiguos responden mal al tipo de registro CAA. Si además necesita ver qué servidores de nombres y qué registrador usa un dominio, la consulta WHOIS de TLDix lo muestra junto con la fecha de caducidad.

Errores habituales que debe evitar

• Cambiar de CA sin actualizar el CAA. Añada primero la nueva CA, emita el certificado y después elimine la antigua.
• Erratas en los identificadores. letsencrypt.com o lets-encrypt.org bloquean la emisión sin avisar.
• Olvidar los servicios de terceros. Una CDN o un dominio personalizado en un SaaS pueden necesitar que su CA figure en la lista.
• Activar el flag crítico a la ligera. Un 128 en una etiqueta no reconocida detiene toda emisión.
• Ignorar DNSSEC. El CAA solo es tan fiable como la respuesta DNS; DNSSEC hace la suplantación mucho más difícil.

El CAA funciona mejor como parte de una rutina más amplia: controle las fechas de caducidad de los certificados, vigile los registros de Certificate Transparency y revise los cambios de DNS. Si los tipos de registro son nuevos para usted, nuestra guía sobre los fundamentos de los registros DNS es un buen punto de partida.