Registros CAA explicados: controle quién emite sus certificados

Técnicamente, cualquier autoridad de certificación de confianza pública puede emitir un certificado para cualquier dominio. El sistema se apoya en que cada CA valide correctamente el control del dominio, y la historia tiene ejemplos de que eso ha salido mal. Un registro CAA (Certification Authority Authorization) es su forma de acotar el campo: un registro DNS que dice "solo estas CA pueden emitir certificados para este dominio". Una CA que no figure en la lista debe negarse.

No cuesta nada, lleva cinco minutos y solo tiene una forma de perjudicarle: olvidar que existe cuando cambia de CA. Esta guía cubre las dos mitades.

Qué hace CAA y qué no

CAA está definido en el RFC 8659 (que sustituyó al RFC 6844 original), y desde septiembre de 2017 los Baseline Requirements del CA/Browser Forum obligan a toda CA de confianza pública a comprobar CAA antes de emitir.

Lo comprueba la CA, en el momento de la emisión. Los navegadores nunca lo miran. Un certificado emitido cuando CAA lo permitía sigue siendo válido aunque cambie el registro después.
Sin registro CAA no hay restricción. Cualquier CA puede emitir, como antes.
Reduce el riesgo de una emisión indebida a través de una CA que usted no usa, por ejemplo por parte de alguien que controla brevemente un servidor web o un buzón y prueba con una CA de método de validación más débil. No detiene a un atacante que controla su DNS, porque también puede cambiar el registro CAA.
No es un mecanismo de revocación ni sustituye la vigilancia de los registros de Certificate Transparency.

Anatomía de un registro CAA

example.com.   3600   IN   CAA   0 issue "ca.example"
;                                │ │     └ value
;                                │ └ tag
;                                └ flags

Flags es 0 en prácticamente todos los casos. El valor 128 activa el bit "crítico", que significa que una CA que no entienda la etiqueta no debe emitir.

Etiquetas:

Etiqueta	Significado
`issue`	La CA indicada puede emitir certificados para este nombre. Se aplica también a los certificados comodín, salvo que exista `issuewild`.
`issuewild`	Reglas solo para los certificados comodín. Si existe, sustituye a `issue` para las solicitudes de comodín.
`iodef`	Adónde puede una CA notificar una solicitud que violó la política (`mailto:` o `https:`). La compatibilidad entre las CA es limitada; trátelo como opcional.
`issuemail`	El mismo control para certificados S/MIME (RFC 9495).

El valor de issue/issuewild es el nombre de dominio identificador que documenta cada CA, por ejemplo en su página sobre CAA o en su CPS. No siempre es el nombre comercial ni el sitio web de la CA, y las CA que revenden certificados de otra CA usan el identificador de la CA de origen. Búsquelo; no lo adivine. El valor especial ";" significa "nadie".

Ejemplos

Una CA, sin comodines, con una dirección de notificación:

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild ";"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Dos CA (por ejemplo, su CA de ACME y la que usa su CDN):

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issue "ca-two.example"

Un dominio que nunca debería tener certificados:

parked.example.  IN  CAA  0 issue ";"

Comodines de una CA distinta de la de los certificados ordinarios:

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild "ca-two.example"

Cómo encuentra la CA el registro que le corresponde

Esta es la parte en la que la gente se equivoca. Para una solicitud de certificado que cubre www.shop.example.com, la CA:

consulta CAA en www.shop.example.com;
si ahí no hay ningún conjunto de registros CAA, consulta shop.example.com;
después example.com, y así hacia arriba en el árbol;
se detiene en el primer nombre que tiene algún registro CAA y usa solo esos.

Consecuencias:

Un registro en example.com cubre todos los subdominios que no tienen CAA propio.
Los registros no se combinan. Un CAA en shop.example.com sustituye por completo al de example.com para todo lo que hay bajo shop. Puede usar esto deliberadamente para dar a un subdominio una CA distinta.
Los CNAME se siguen. Si shop.example.com es un CNAME a stores.saas.example, la consulta CAA de shop.example.com se responde con los registros CAA del destino. La política CAA de un proveedor SaaS puede, por tanto, aplicarse a su nombre de host. Con el RFC actual, la CA no asciende por el árbol del destino; si el destino no tiene CAA, el ascenso continúa en su padre, example.com.
Un fallo de consulta no es lo mismo que "sin registro". Si la CA no puede obtener una respuesta limpia (tiempo de espera agotado, SERVFAIL, DNSSEC roto), no debe emitir. Un DNS autoritativo inestable se manifiesta como renovaciones fallidas.

Cada nombre de un certificado con varios nombres se comprueba por separado.

Vincular la emisión a una cuenta o a un método

El RFC 8657 añade parámetros que hacen CAA considerablemente más fuerte para los usuarios de ACME:

example.com. IN CAA 0 issue "ca-one.example; accounturi=https://acme.ca-one.example/acct/12345"
example.com. IN CAA 0 issue "ca-one.example; validationmethods=dns-01"

accounturi restringe la emisión a una única cuenta ACME, de modo que otra persona con una cuenta en la misma CA no pueda obtener un certificado aunque supere la validación. validationmethods restringe cómo puede demostrarse el control. Ambos solo funcionan con CA que los implementan; consulte la documentación de la CA antes de confiar en ellos, y acuérdese de actualizar el registro si alguna vez vuelve a crear la cuenta ACME.

Añadir CAA sin romper nada: lista de comprobación

Averigüe quién emite hoy para usted. Inspeccione los certificados de cada nombre de host, o busque su dominio en los registros de Certificate Transparency. Sorpresas típicas: la CDN, los certificados gestionados del balanceador de carga, la tienda alojada, la página de estado, el servicio de correo y un equipo interno que usa otra CA de ACME.
Recopile el identificador CAA de cada CA a partir de su documentación.
Compruebe los subdominios que son CNAME a terceros: consulte CAA en ellos y vea qué devuelven.
Publique los registros en el ápice de la zona con un TTL moderado (3600). Las CA pueden guardar en caché el resultado de una comprobación CAA como máximo durante el TTL del registro u 8 horas, lo que sea mayor.
Pruebe una renovación de inmediato (certbot renew --dry-run hace una validación completa contra el entorno de pruebas, que en la mayoría de las CA de ACME incluye una comprobación CAA) en lugar de descubrirlo en 60 días.
Documéntelo donde vaya a mirar la siguiente persona que cambie de CDN o de CA.

Consulte lo que está publicado:

$ dig +short example.com CAA
0 issue "ca-one.example"
0 issuewild ";"
$ dig +short www.shop.example.com CAA      # empty → the CA will climb

Errores frecuentes

Cambiar de CDN o de proveedor de alojamiento y olvidar que el nuevo usa otra CA. El certificado nuevo no llega a emitirse, sin aviso, y el antiguo se agota. Consulte certificado SSL caducado: qué hacer.
Usar el nombre comercial de la CA en lugar de su identificador CAA documentado.
issuewild ";" mientras hay un certificado comodín en uso en alguna parte.
Creer que un issue en el ápice y otro issue en un subdominio se suman. El conjunto del subdominio gana en solitario.
Un proveedor de DNS que no admite el tipo CAA, donde la gente intenta guardarlo como TXT. Eso no hace nada.
Errores con las comillas en los paneles de control: el valor es una cadena entrecomillada; el flag y la etiqueta, no.
Esperar que CAA invalide los certificados existentes. Solo afecta a las emisiones nuevas.
Cambiar de servidores de nombres y no copiar los registros CAA; están entre los registros que más a menudo se pierden, como se señala en cambiar de servidores de nombres sin interrupciones.

Compruébelo con OrbitProbe

La consulta DNS de OrbitProbe incluye CAA entre los tipos de registro que consulta, con el TTL, tal como lo devuelven los resolvers públicos en ese momento. Ejecútela primero sobre el dominio sin subdominio y después sobre cualquier subdominio que sea un CNAME a un servicio externo, para ver qué política encontraría realmente allí una CA. Para la visión de conjunto de cómo encaja CAA junto a los demás tipos de registro, consulte tipos de registros DNS explicados.