Explicación de los registros CAA: Cómo definir qué autoridades de certificación pueden emitir certificados para su dominio.

En el mundo de la infraestructura de clave pública (PKI) , la confianza es fundamental. Las organizaciones invierten mucho tiempo y dinero en proteger sus dominios con certificados SSL/TLS , pero muchas no se plantean quién está realmente autorizado a emitirlos. Esta falta de información puede causar graves problemas. Los registros CAA son una herramienta DNS sencilla que permite a los propietarios de dominios decidir, con claridad, qué autoridades de certificación están autorizadas a emitir certificados para su dominio.

Si su programa de seguridad aún no utiliza registros DNS CAA, esta guía le explicará qué son, cómo funcionan y por qué todas las organizaciones deberían utilizarlos.

Respuesta rápida: ¿Qué es un registro CAA?

Un registro CAA (Autorización de Autoridad de Certificación) es un registro de recursos DNS (RFC 6844, actualizado a RFC 8659) que indica a las Autoridades de Certificación cuáles están autorizadas a emitir certificados SSL/TLS para su dominio. Desde septiembre de 2017 , todas las CA de confianza pública deben verificar los registros CAA antes de emitir certificados. Un dominio sin registros CAA permite que cualquier CA emita certificados para él . Tres etiquetas controlan la emisión: issue , issuewild e iodef.

Puntos Clave

• Los registros CAA son un control de emisión de DNS estandarizado en RFC 6844 (actualizado en RFC 8659) que restringe qué autoridades de certificación pueden emitir certificados SSL/TLS para un dominio. Desde septiembre de 2017, los requisitos básicos del CA/Browser Forum exigen que todas las autoridades de certificación de confianza pública verifiquen los registros CAA antes de emitir cualquier certificado. Una autoridad de certificación que no figure en la lista debe rechazar la emisión; un error SERVFAIL durante la búsqueda también debe provocar el rechazo (comportamiento de seguridad ante fallos).
• Un dominio sin registros CAA en ningún nivel de la jerarquía DNS permite que cualquier CA públicamente confiable emita certificados para él. Con más de 100 CA raíz confiables en los almacenes raíz de los navegadores, dejar la emisión abierta a cualquiera de ellas equivale a dejar la puerta sin llave en el DNS. Los registros CAA solucionan este problema con una única entrada DNS en el dominio raíz que se hereda a través de todos los subdominios.
• La encuesta DigiCert Trust Pulse (2 de julio de 2025) reveló que el 45 % de las empresas experimentaron interrupciones del servicio relacionadas con certificados durante el año anterior. Los registros CAA mal configurados, en particular aquellos que omiten una CA activa, provocan fallos en la renovación de certificados que generan precisamente esas interrupciones: el certificado caduca porque la renovación se bloquea durante la comprobación CAA de la CA. Con una validez máxima de TLS de 47 días a partir de marzo de 2029 (CA/B Forum SC-081v3, aprobado en abril de 2025), un registro CAA mal configurado provoca fallos de renovación ocho veces al año por certificado afectado, en lugar de una sola vez.
• Los registros CAA utilizan tres etiquetas de propiedad. La etiqueta `issue` controla qué CA puede emitir certificados estándar. La etiqueta `issuewild` controla de forma independiente qué CA puede emitir certificados comodín. La etiqueta `iodef` especifica dónde deben enviar las CA los informes de infracción. Las etiquetas `issue` e `issuewild` son independientes; configurar una sin la otra deja sin control la mitad del espacio de nombres de certificados.
• DNSSEC protege los registros CAA de ataques de envenenamiento de caché DNS que, de otro modo, permitirían a un atacante insertar registros CAA falsos que autorizarían a la CA elegida. Sin DNSSEC, un registro CAA solo garantiza la aplicación de políticas frente a las CA honestas que verifican las solicitudes legítimas, no frente a atacantes activos que manipulan las respuestas DNS.

¿A quién debería importarle el historial de la CAA?

La configuración y el mantenimiento de los registros CAA son responsabilidad compartida entre las operaciones de DNS, la gestión de PKI, la arquitectura de seguridad y la gobernanza del cumplimiento normativo. Cada equipo es responsable de una parte específica del problema, y ​​las deficiencias en cualquier área pueden generar vulnerabilidades en la emisión de licencias (ausencia de registros CAA) o configuraciones incorrectas que bloquean la renovación (registros CAA obsoletos o incompletos).

Rol	POR QUÉ ES IMPORTANTE	Acción
Equipos de PKI y certificados	Es responsable de la asignación de certificados a CA que determina qué CA deben figurar en los registros CAA; publicar registros CAA sin auditar previamente qué CA emiten certificados activamente provoca fallos en la renovación; el calendario del Foro CA/Navegador SC-081v3 (validez máxima de 47 días para marzo de 2029) implica que cada registro CAA mal configurado provoca fallos en la renovación aproximadamente ocho veces al año por certificado afectado; el inventario de certificados debe mantenerse actualizado a medida que cambian las relaciones con las CA, los certificados migran entre CA y se aprovisionan nuevos dominios.	Audite todo el conjunto de certificados utilizando Administrador de CertSecure para producir una asignación actual de certificado a CA antes de publicar o actualizar cualquier registro CAA; utilice CBOM seguro Descubrir todos los certificados en entornos de nube, locales y multinube, e identificar todas las CA que emiten certificados activamente para cada dominio; confirmar que la plataforma CLM automatiza las renovaciones a través de las CA que figuran en el registro CAA para detectar las discrepancias en las renovaciones antes de que provoquen interrupciones.
Equipos de DNS e infraestructura	Publicación propia de registros CAA y mantenimiento de zonas DNS; los registros CAA solo pueden ser publicados y actualizados por equipos con acceso de escritura a la zona DNS; la firma DNSSEC es un requisito previo para proteger los registros CAA contra la suplantación de identidad, y la firma debe mantenerse de forma continua (la expiración de RRSIG provoca fallos de validación DNSSEC que hacen que los registros CAA no sean validables); las zonas DNS aprovisionadas en la nube y los subdominios de autoservicio para desarrolladores pueden no estar en el inventario del equipo DNS, lo que crea brechas en la cobertura de CAA.	Confirme que DNSSEC esté implementado y mantenido para cada zona donde se publicarán registros CAA; publique registros CAA en el dominio ápice para proporcionar cobertura de herencia para todos los subdominios; mantenga un inventario de zonas DNS que incluya todos los subdominios aprovisionados en la nube y aprovisionados por el desarrollador para confirmar que la cobertura CAA sea completa; pruebe los registros CAA con dig, MX Toolbox o el generador de registros CAA de SSLMate después de la publicación y después de cada actualización; planifique la migración del algoritmo de firma de zona DNSSEC a través de Centro de Excelencia PQC
Arquitectos de seguridad	Controle el modelo de gobernanza de CAA: defina la política para la separación de etiquetas de emisión frente a etiquetas comodín, establezca el requisito de implementación de DNSSEC, especifique el punto final iodef y la integración de monitoreo, y defina el manual de respuesta a la emisión no autorizada cuando se reciban informes iodef; sin un modelo de gobernanza definido, los registros CAA se publican de forma inconsistente en todos los dominios y se actualizan de forma reactiva en lugar de proactiva a medida que cambian las relaciones con las CA y los conjuntos de certificados.	Definir la política de gobernanza de CAA: qué CA están autorizadas para certificados estándar frente a certificados comodín (separación emisión frente a emisión comodín), DNSSEC como requisito previo obligatorio para todos los dominios con registros CAA, punto final iodef conectado a SIEM o sistema de tickets y cadencia de auditoría trimestral de CAA; definir el manual de respuesta a la emisión no autorizada: SLA de revisión de informes iodef, proceso de notificación de CA y ruta de escalamiento para la emisión indebida confirmada; planificar la migración del algoritmo DNSSEC a estándares post-cuánticos a través de Preparación para PQC servicios
Equipos de cumplimiento	Los registros CAA constituyen un control de emisión documentable que se corresponde directamente con los requisitos de gobernanza de certificados de SOC 2, ISO 27001 y PCI DSS 4.0; la evidencia de auditoría debe confirmar que los registros CAA están presentes para todos los dominios incluidos en el alcance, que reflejan con precisión el uso autorizado de la CA y que se supervisan y responden los informes iodef; la encuesta DigiCert Trust Pulse (2 de julio de 2025) reveló que el 37.5 % de las interrupciones relacionadas con certificados se debían a certificados caducados, y la configuración incorrecta de CAA que bloquea las renovaciones es una causa directa de ese patrón de caducidad en entornos donde las CA cambiaron pero los registros CAA no se actualizaron.	Incluir la presencia y precisión de los registros CAA en el paquete trimestral de evidencia de cumplimiento: porcentaje de dominios dentro del alcance con registros CAA, porcentaje de registros CAA que coinciden con la asignación actual de certificado a CA y tiempos de respuesta del informe iodef; confirmar que los registros CAA se actualizan como parte del proceso documentado de incorporación y baja de CA; asignar las fechas de fase del Foro CA/B SC-081v3 (marzo de 200 días de 2026, marzo de 2027 de 100 días, marzo de 2029 de 47 días) a los hitos de cumplimiento internos para el ajuste de la cadencia de auditoría de registros CAA
CISO	Los dominios sin registros CAA están expuestos a la emisión de certificados por cualquiera de las más de 100 CA de confianza pública; un certificado emitido fraudulentamente que permite un ataque MITM o la suplantación de marca produce el tipo de brecha que llega a la junta directiva; los registros CAA son uno de los controles preventivos más simples y de menor costo en el conjunto de herramientas de seguridad PKI; el programa de reducción de validez del Foro CA/B SC-081v3 significa que el mantenimiento de los registros CAA aumenta con la frecuencia de renovación, lo que hace que los registros CAA precisos sean un requisito operativo cada vez mayor a medida que la vida útil de los certificados se reduce a 47 días.	Exigir que cada dominio resoluble externamente tenga un registro CAA como estándar de seguridad básico; financiar el programa de descubrimiento de certificados y CLM necesario para mantener registros CAA precisos a medida que evolucionan el conjunto de certificados y las relaciones con las CA; evaluar PKI como servicio Para infraestructuras PKI privadas donde el uso interno de CA debe rastrearse junto con el uso público de CA en los registros CAA; se requiere que la cobertura y precisión de los registros CAA se informen trimestralmente como KPI a nivel de junta directiva junto con la cobertura de monitoreo de vencimiento de certificados.

¿Qué es un registro CAA?

Un registro de autorización de autoridad de certificación (CAA) es un registro de recursos DNS, estandarizado según el RFC 6844 y actualizado por el RFC 8659, que indica qué autoridades de certificación (CA) están autorizadas a emitir certificados SSL/TLS para su dominio o subdominio. Puede considerarse como una regla sencilla integrada en su DNS que indica a cualquier CA que verifique los permisos antes de emitir un certificado.

Un registro básico de la CAA tiene este aspecto:

Este registro indica a todas las autoridades de certificación (CA): solo Let's Encrypt está autorizada a emitir certificados para example.com. Cualquier otra CA que reciba una solicitud de certificado para ese dominio está obligada, según los Requisitos Básicos del Foro CA/Navegador, a verificar los registros CAA y seguir las reglas, o bien, rechazar la emisión. Los registros CAA también siguen la jerarquía DNS. Si un subdominio no tiene su propio registro CAA, la CA consultará el dominio principal y aplicará esas reglas, lo que facilita la gestión de políticas en un gran número de dominios.

Cómo definen los registros de la CAA las autoridades de certificación autorizadas

Los registros CAA funcionan conectando identificadores CA específicos a su dominio en el DNS. Cuando una CA recibe una solicitud para emitir un certificado, busca los registros CAA de ese dominio. Si existe un registro CAA y la CA no aparece en la lista, debe rechazar la solicitud. Si no existe ningún registro CAA, cualquier CA puede emitir certificados para su dominio, lo que representa una vulnerabilidad que los equipos de seguridad deben corregir.

Puede incluir más de una CA en sus registros CAA. Esto resulta útil para organizaciones que utilizan distintas CA para diferentes propósitos, como una CA pública para servicios de atención al cliente y una CA privada para sistemas internos. Cada CA autorizada tiene su propia entrada CAA, y debe coincidir con al menos una entrada para poder emitir el certificado.

Comprender el problema, issuewild y las etiquetas iodef

Los registros de la CAA utilizan tres etiquetas de propiedad principales para controlar la emisión de certificados. Cada etiqueta tiene una función diferente, y comprender las tres es importante para configurar correctamente los registros.

Problema: Esta etiqueta indica qué CA está autorizada a emitir certificados estándar para su dominio. Por ejemplo, el problema 0 “digicert.com” otorga a DigiCert permiso para emitir certificados para ese dominio.

Issuewild: Esta etiqueta controla qué autoridades de certificación pueden emitir certificados comodín , como *.example.com . Es independiente de la etiqueta issue, por lo que puede tener una política más flexible para los certificados estándar, pero una más estricta para los certificados comodín, según sus necesidades de seguridad.

Iodef: Esta etiqueta indica a las CA dónde enviar un informe si reciben una solicitud de certificado que infringe su política. Puede indicarle una dirección de correo electrónico o una URL, como esta:

0 iodef "mailto:[email protected]"

Un detalle importante a tener en cuenta: si solo configura la etiqueta issuewild sin la etiqueta issue, cualquier CA podrá emitir certificados estándar para su dominio. Ambas etiquetas son independientes, así que configure siempre ambas para garantizar que su política sea completa.

Referencia de etiquetas CAA: issue, issuewild e iodef

Utilice esta tabla como referencia rápida al configurar o auditar los registros CAA. Cada fila describe qué controla la etiqueta, un ejemplo de sintaxis, cuándo usarla y el modo de fallo si se omite o se configura incorrectamente. Las tres etiquetas deben revisarse trimestralmente con respecto a la asignación actual de certificados a CA del inventario CLM.

Etiqueta	Lo que controla	Sintaxis de ejemplo	Cuándo usar	Modo de fallo si se omite o se configura incorrectamente
de problemas	¿Qué CA pueden emitir certificados SSL/TLS estándar (sin comodines) para el dominio? Se permiten varias entradas de emisión, una por cada CA autorizada. Si se establece el valor en una cadena vacía (0 emisión ""), se prohíbe a todas las CA emitir certificados estándar.	0 problemas “digicert.com” 0 problemas “letsencrypt.org”	Siempre. Cada dominio debe tener al menos una etiqueta de emisión que indique explícitamente todas las autoridades de certificación autorizadas para emitir certificados estándar para ese dominio. Sin esta etiqueta, cualquier autoridad de certificación puede emitir certificados estándar independientemente de las demás etiquetas presentes.	Omitido: cualquier CA puede emitir certificados estándar. Lista de CA incorrecta: la renovación falla cuando la CA activa verifica el registro de la CAA y no aparece en la lista; con una validez de 47 días, esto provoca fallos de renovación aproximadamente 8 veces al año por cada certificado afectado.
problema	¿Qué CA pueden emitir certificados SSL/TLS comodín (*.dominio.com) para el dominio? Independientemente de la etiqueta de emisión. Si no se especifica issuewild, la emisión del certificado comodín se rige por las restricciones de la etiqueta de emisión.	0 issuewild “digicert.com” 0 issuewild “” (bloquea toda emisión de comodines)	Cualquier dominio para el que se emitan o puedan emitirse certificados comodín. Configúrelo explícitamente para autorizar a CA específicas para la emisión de certificados comodín o para prohibir completamente la emisión de certificados comodín (0 issuewild “”) para los dominios que no requieren certificados comodín.	Omitido: la emisión de comodines recurre a la etiqueta de emisión, que puede ser más permisiva de lo previsto. Mal configurado (lista de CA no utilizadas para comodines): la renovación de comodines falla. No configurar issuewild cuando no es necesario es aceptable si los controles de la etiqueta de emisión son suficientes.
yodef	Las autoridades de certificación deben enviar un informe cuando reciben una solicitud de emisión de certificado que infringe la política CAA del dominio. Acepta una dirección de correo electrónico (mailto:) o una URL. No bloquea la emisión; solo proporciona una notificación.	0 iodef “mailto:[email protected]" 0 iodef “https://example.com/caa-report”	Cualquier dominio con registros issue o issuewild. La etiqueta iodef es el mecanismo de notificación que permite observar la aplicación de las políticas de CAA. Sin ella, las infracciones de las políticas pasan desapercibidas: la CA las rechaza, pero el propietario del dominio nunca recibe notificación.	Omitido: las infracciones de política no se detectan; no se envía ninguna notificación cuando una CA no autorizada recibe una solicitud de certificado para el dominio. Punto final no supervisado: las notificaciones llegan, pero nadie actúa en consecuencia, lo que elimina la utilidad operativa de la etiqueta iodef.

Por qué los registros CAA son esenciales para la seguridad del dominio

La emisión no autorizada de certificados es un problema grave. Ya sea por ingeniería social, errores en la autoridad de certificación o sistemas comprometidos, se han emitido certificados de forma errónea para dominios conocidos. En estos casos, los atacantes pueden interceptar el tráfico cifrado, realizar ataques de intermediario o suplantar la identidad de servicios legítimos.

Los registros CAA no previenen todos los posibles ataques, ya que dependen de que las CA los verifiquen y cumplan, y el cumplimiento está regulado por el Foro CA/Browser. Sin embargo, desde septiembre de 2017, todas las CA de confianza pública están obligadas por los Requisitos Básicos del Foro CA/Browser a verificar los registros CAA antes de emitirlos. Una CA que ignore esta obligación corre el riesgo de perder su estatus de confianza, lo cual tiene graves consecuencias.

Los registros CAA también respaldan el cumplimiento normativo. En marcos como SOC 2, ISO 27001 y PCI DSS , poder demostrar que usted controla qué CA emiten certificados para su dominio constituye un control de seguridad sólido y documentable. Esto facilita las auditorías y demuestra que su organización gestiona la seguridad del dominio correctamente.

Cómo las autoridades de certificación validan los registros CAA

Cuando una CA recibe una solicitud de certificado, realiza una búsqueda DNS de registros CAA en el nombre de dominio completo (FQDN) de la solicitud. Si encuentra registros y la CA no aparece en la lista, rechaza la emisión del certificado. Si la consulta DNS falla debido a un error SERVFAIL, un tiempo de espera agotado o una configuración incorrecta, la CA también debe rechazar la solicitud. Este enfoque de seguridad ante fallos significa que una configuración defectuosa le protege en lugar de dejarle expuesto.

DNSSEC añade una capa adicional de protección. Sin DNSSEC, los registros CAA pueden ser falsificados mediante el envenenamiento de la caché DNS, donde un atacante inserta registros falsos que permiten a la CA elegida emitir un certificado. Al firmar sus zonas DNS con DNSSEC, la precisión e integridad de sus registros CAA quedan garantizadas a nivel criptográfico.

Si no existe un registro CAA para un FQDN específico, la CA recorre el árbol DNS hacia arriba, hasta el dominio padre y luego el abuelo, hasta encontrar uno. Esto significa que un único registro CAA en su dominio raíz puede cubrir todo su espacio de nombres de dominio, lo que resulta una forma muy eficiente de aplicar políticas a gran escala.

Configuración de CAA: Requisitos, modos de fallo y señales de monitorización

Utilice esta tabla para relacionar cada requisito de configuración de CAA con su método de validación, el modo de fallo cuando no se cumple el requisito, la señal de monitorización que detecta el fallo y la fuente de política autorizada. Los registros de CAA y los requisitos básicos del Foro CA/Browser se revisan trimestralmente y pueden actualizarse de forma independiente.

Requisito	Método de validación	Modo de fallo	Señal de monitoreo	Fuente de la política
Registros CAA presentes para cada dominio resoluble externamente	Búsqueda DNS (dig TYPE257 domain.com o dig CAA domain.com); comprobación CAA de MX Toolbox; generador de registros CAA de SSLMate; auditoría de dominio de la plataforma CLM	Sin registro CAA: cualquier CA de confianza pública puede emitir certificados para el dominio; la emisión no autorizada pasa desapercibida hasta que un monitor de registro CT o un informe iodef lo revela.	Auditoría de dominio de la plataforma CLM que muestra dominios sin registros CAA; alerta de monitoreo de registro CT por certificado inesperado emitido para un dominio no protegido.	RFC 6844 (estándar CAA); RFC 8659 (actualización CAA); Requisitos básicos del CA/Browser Forum, sección 3.2.2.8 (mandato de verificación CAA, vigente desde septiembre de 2017)
Las etiquetas issue e issuewild coinciden con todas las CA que emiten activamente para el dominio.	Compare el inventario de certificados CLM (qué CA emitió cada certificado para cada dominio) con las CA que figuran en el registro CAA para ese dominio; confirme que todas las CA activas están incluidas; realice una prueba solicitando la renovación de un certificado a través de cada CA autorizada y confirmando que la verificación CAA se realiza correctamente.	El registro CAA omite una CA activa: la renovación del certificado falla en la verificación CAA de la CA; con una validez máxima de 47 días (SC-081v3, marzo de 2029), esto provoca fallos de renovación aproximadamente 8 veces al año por certificado afectado; el fallo aparece como un error de rechazo de la CA en lugar de una advertencia de vencimiento.	Las alertas de fallos en la renovación de certificados en la plataforma CLM se correlacionaron con errores de búsqueda de CAA; las respuestas de error de CA citan la política de CAA durante la renovación; la comparación del inventario de CLM muestra una discrepancia de CA entre el emisor del certificado y el contenido del registro de CAA.	RFC 6844 Sección 4 (etiquetas de propiedad CAA); Requisitos básicos del CA/Browser Forum Sección 3.2.2.8; CA/B Forum SC-081v3 (aprobado en abril de 2025) para el contexto de la frecuencia de renovación.
El punto final iodef está configurado y supervisado.	Confirme que la etiqueta iodef esté presente en el registro CAA para todos los dominios; compruebe que el punto final iodef sea accesible y tenga el formato correcto; confirme que los informes iodef se envíen al SIEM o al sistema de gestión de incidencias y se revisen dentro del SLA definido; nota: no todas las CA implementan la generación de informes iodef; confirme la compatibilidad con iodef con cada CA autorizada.	Etiqueta Iodef ausente: las infracciones de política no se detectan; una CA no autorizada recibe una solicitud de certificado, pero el propietario del dominio nunca es notificado; la infracción solo se puede descubrir mediante la monitorización del registro CT. Punto final Iodef no monitorizado: llegan notificaciones, pero nadie actúa en consecuencia.	Alerta del sistema SIEM o de gestión de incidencias sobre un nuevo informe iodef recibido; se identificó una brecha en el registro de revisión del informe iodef durante la auditoría trimestral; alerta de monitorización del registro CT por un certificado inesperado que debería haber activado un informe iodef.	RFC 6844 Sección 5.4 (etiqueta de propiedad iodef); CA/Browser Forum Baseline Requirements Sección 3.2.2.8
DNSSEC firmado para todos los dominios con registros CAA	Validador DNSSEC externo (DNSViz, Verisign DNSSEC Analyzer); confirme que el indicador AD esté establecido en las respuestas de registro CAA de los resolvedores que validan DNSSEC; confirme que los registros RRSIG estén presentes y no hayan caducado para la zona.	Sin DNSSEC: los registros CAA son vulnerables al envenenamiento de la caché DNS; un atacante puede insertar registros CAA falsos que autoricen a su CA elegida a emitir un certificado fraudulento; el registro CAA proporciona cumplimiento de políticas solo contra CA honestas, no contra atacantes activos que manipulan DNS.	Error de validación DNSSEC por parte de validadores externos; la bandera AD no está establecida en las respuestas DNS del registro CAA; advertencias de caducidad de RRSIG por parte del monitoreo DNS; certificado emitido para un dominio con un registro CAA falsificado (detectado mediante el monitoreo del registro CT).	RFC 4033-4035 (DNSSEC); RFC 6844 Sección 3 (recomienda DNSSEC para CAA); NIST SP 800-81-2 (guía de implementación de DNSSEC)
Los registros de CAA se actualizan cuando cambian las relaciones con CA.	Confirme que los procesos de incorporación y baja de CA incluyan un paso de actualización de registros CAA; audite los registros CAA con respecto al mapeo actual de certificados a CA trimestralmente; pruebe la renovación a través de cualquier CA agregada o eliminada desde la última auditoría para confirmar que los registros CAA son correctos.	El registro CAA indica una CA que ya no está en uso: no hay fallo inmediato, pero persiste una exposición innecesaria al emisor autorizado. El registro CAA no indica una CA recién incorporada: las renovaciones de certificados fallan inmediatamente para todos los certificados que se migran a la nueva CA.	Alertas de fallos en la renovación de certificados en la plataforma CLM durante la migración de CA; comparación del inventario de CLM que muestra que la CA recién incorporada no aparece en el registro CAA; auditoría trimestral de CAA que identifica entradas de CA obsoletas en los registros CAA para dominios donde esa CA ya no emite certificados.	RFC 8659 Sección 4 (mantenimiento de registros CAA); Requisitos básicos del Foro CA/Navegador Sección 3.2.2.8; política interna de gestión de cambios para la incorporación y desvinculación de CA

Buenas prácticas para configurar y administrar registros CAA

Configurar los registros de la CAA es sencillo, pero hacerlo bien requiere cierta planificación. Estas son las prácticas clave a seguir:

• Primero, audita tu inventario de certificados: Antes de añadir registros CAA, averigüe qué autoridades de certificación (CA) ya emiten certificados para sus dominios. Herramientas como crt.sh pueden ayudarle con esto. Si restringe la emisión a una CA que no utiliza, las renovaciones de certificados fallarán.
• Establezca explícitamente las etiquetas issue e issuewild: No dé por sentado que una opción cubre la otra. Tenga claro qué autoridades de certificación pueden emitir certificados estándar y comodín, y mantenga un registro de los motivos por los que cada autoridad está autorizada.
• Agregue una etiqueta iodef y monitoréela: Los informes solo son útiles si alguien los lee. Conecte su punto final de iodef al sistema de gestión de incidencias o SIEM de su equipo de seguridad y trate con seriedad cualquier alerta de infracción.
• Utilice los registros CAA junto con DNSSEC: DNSSEC garantiza que su política CAA no pueda ser falsificada a nivel DNS. Si sus zonas aún no están firmadas con DNSSEC, este es un buen motivo para comenzar.
• Compruebe sus registros de CAA después de la publicación: Utilice herramientas como dig, el generador de registros CAA de SSLMate o MX Toolbox para comprobar que sus registros se resuelven correctamente desde múltiples ubicaciones.
• Actualice los registros de CAA cada vez que cambien sus relaciones con CA: Cada vez que cambie de CA, contrate un nuevo proveedor o participe en una fusión, actualice sus registros de CAA para que coincidan. Los registros desactualizados pueden ser tan riesgosos como los que faltan.

Cómo puede ayudar la consultoría de cifrado

Configurar correctamente los registros CAA comienza por saber con exactitud qué Autoridades de Certificación (CA) ya emiten certificados para sus dominios. Sin este inventario, corre el riesgo de bloquear una CA que esté renovando certificados activamente, lo que provoca interrupciones en el servicio en cuanto falla una renovación. Esta auditoría es donde la mayoría de las organizaciones se estancan, y es donde CertSecure Manager marca la diferencia.

CertSecure Manager es la plataforma de gestión del ciclo de vida de certificados de Encryption Consulting. Proporciona a su equipo un inventario completo y actualizado continuamente de todos los certificados SSL/TLS de su entorno, incluyendo la CA que emitió cada uno, su fecha de vencimiento y su ubicación. Esta visibilidad es fundamental antes de crear un solo registro CAA. Para una visibilidad completa del entorno criptográfico, más allá de los certificados, CBOM Secure amplía la detección a algoritmos, claves y dependencias criptográficas en entornos en la nube, locales e híbridos.

Así es como CertSecure Manager aborda cada uno de estos desafíos:

Descubrimiento e inventario de certificados: Nuestro Administrador de CertSecure analiza su red y entornos en la nube para detectar todos los certificados en uso, independientemente de la CA que los haya emitido. Antes de restringir la emisión mediante registros CAA, necesita saber qué certificados ya existen. El sistema se encarga de este paso automáticamente.

Seguimiento de relaciones con CA: Dado que la precisión de su política CAA depende de su conocimiento sobre las CA que realmente utiliza, CertSecure Manager mantiene actualizado su inventario de certificados para que sus registros CAA se mantengan alineados con la realidad, incluso a medida que su entorno crece o sus relaciones con las CA cambian.

Automatización de renovaciones: Una vez que sus registros CAA estén configurados, cualquier renovación de certificado que se envíe a una CA no autorizada fallará. CertSecure Manager automatiza las renovaciones a través de sus CA autorizadas, para que no haya sorpresas de última hora cuando un certificado esté a punto de caducar.

Registro de auditoría para el cumplimiento: Para marcos como SOC 2, ISO 27001 y PCI DSS, poder demostrar el control sobre la emisión de certificados es un control de seguridad documentable. CertSecure Manager registra cada evento de certificado, proporcionando a su equipo de cumplimiento la evidencia que necesita.

Los registros CAA proporcionan políticas. CertSecure Manager ofrece la visibilidad y la automatización necesarias para que dichas políticas funcionen de forma coherente en todo el entorno de certificados. Para las organizaciones que desarrollan o amplían su infraestructura PKI privada, PKI como servicio ofrece una jerarquía de CA totalmente gestionada donde el uso interno de CA se integra perfectamente con la gobernanza de los registros CAA. Para la planificación de la migración post-cuántica de los algoritmos de firma de zona DNSSEC utilizados junto con CAA, realice un seguimiento de los requisitos a través del Centro de Excelencia de PQC.

Conclusión

Los registros CAA son fáciles de pasar por alto porque funcionan discretamente en segundo plano, pero su omisión crea una verdadera brecha de seguridad. Dado que la emisión indebida de certificados sigue siendo un riesgo en internet, los propietarios de dominios necesitan controlar quién puede emitir certificados en su nombre. Los registros CAA ofrecen ese control de forma sencilla y estandarizada.

Cuando los registros CAA se configuran correctamente y se combinan con DNSSEC, un punto final iodef supervisado y un proceso sólido de gestión de certificados, se convierten en una parte fundamental de su estrategia PKI. Su implementación es sencilla, pero es necesario mantenerlos actualizados a medida que su entorno evoluciona.

Esta guía se revisa trimestralmente y de inmediato cada vez que el Foro CA/Browser actualiza sus reglas de verificación CAA de requisitos básicos o introduce nuevas etiquetas de propiedades CAA.

Preguntas frecuentes

¿Cuál es la principal conclusión de "Explicación de los registros CAA: Cómo definir qué autoridades de certificación pueden emitir certificados para su dominio"?

Los registros CAA son un control de emisión de DNS (RFC 6844, actualizado a RFC 8659) que restringe qué Autoridades de Certificación pueden emitir certificados SSL/TLS para su dominio, y que se aplica mediante los Requisitos Básicos del Foro CA/Navegador desde septiembre de 2017. Un dominio sin registros CAA permite que cualquier CA de confianza pública emita certificados para él. Tres etiquetas controlan la emisión: issue (certificados estándar), issuewild (certificados comodín) e iodef (informes de infracción). DNSSEC protege los registros CAA contra la suplantación de identidad. Las etiquetas issue e issuewild son independientes; configurar una sin la otra deja la mitad del espacio de nombres del certificado sin control.

¿Por qué son importantes los registros CAA para los equipos de PKI empresariales?

Los equipos de PKI empresariales se enfrentan a dos riesgos relacionados con CAA. Un dominio sin registros CAA está expuesto a la emisión de certificados por cualquiera de las más de 100 CA de confianza pública, cualquiera de las cuales puede verse comprometida o coaccionada. La encuesta DigiCert Trust Pulse (2 de julio de 2025) reveló que el 45 % de las empresas experimentaron tiempo de inactividad relacionado con los certificados; los registros CAA mal configurados que omiten una CA activa provocan fallos de renovación que generan precisamente ese tiempo de inactividad. Con una validez máxima de TLS de 47 días a partir de marzo de 2029 (CA/B Forum SC-081v3, aprobado en abril de 2025), un registro CAA mal configurado provoca fallos de renovación aproximadamente ocho veces al año por certificado afectado.

¿Qué riesgos aumentan si los registros de CAA no están configurados o se gestionan manualmente?

Aumentan tres categorías de riesgo: exposición a la emisión abierta (sin registros CAA, cualquier CA de confianza pública puede emitir certificados para el dominio); bloqueo de renovaciones por mala configuración (un registro CAA que omite una CA activa provoca fallos de renovación, ocho veces al año con una validez de 47 días); y brecha de comodines (configurar issue sin issuewild, o issuewild sin issue, deja la mitad del espacio de nombres del certificado sin control).

¿Qué equipos deberían encargarse de la configuración y el mantenimiento de los registros de CAA?

Los equipos de DNS e infraestructura son responsables de la publicación de registros CAA y del mantenimiento de DNSSEC. Los equipos de PKI y certificados son responsables del mapeo de certificados a CA que determina qué CA deben incluirse. Los arquitectos de seguridad son responsables del modelo de gobernanza: política de emisión frente a emisión no autorizada, monitorización de endpoints de iodef y manual de respuesta ante emisiones no autorizadas. Los equipos de cumplimiento son responsables de la evidencia de auditoría que confirma que los registros CAA están presentes, son precisos y están actualizados para todos los dominios incluidos en el ámbito de aplicación.

¿Cómo se relacionan los registros CAA con la gestión del ciclo de vida de los certificados?

Los registros CAA son una dependencia del ciclo de vida: cada renovación de certificado activa una consulta CAA en la CA emisora. Un registro CAA que omite la CA que renueva provoca que la renovación falle. CertSecure Manager proporciona el inventario de certificados necesario para confirmar qué CA deben figurar antes de publicar los registros CAA y automatiza las renovaciones a través de las CA autorizadas para evitar interrupciones del servicio por discrepancias en los registros CAA.

¿Cómo deberían las organizaciones medir el éxito en la implementación de los registros de CAA?

Métricas clave: 100 por ciento de los dominios propiedad de la organización con registros CAA presentes; 100 por ciento de los registros CAA coinciden con la asignación actual de certificado a CA del inventario CLM; cero fallos en la renovación de certificados atribuibles a una configuración incorrecta de CAA; informes iodef revisados ​​dentro del SLA definido (objetivo: 100 por ciento en 24 horas); y cobertura de firma DNSSEC para el 100 por ciento de los dominios con registros CAA.

¿Qué se debe auditar o supervisar periódicamente?

Supervisar continuamente: informes iodef de todas las CA autorizadas con alertas automatizadas; eventos de fallos en la renovación de certificados que se correlacionen con errores de búsqueda de CAA. Auditar trimestralmente: presencia de registros CAA para todos los dominios propiedad de la organización; precisión de los registros CAA con respecto a la asignación actual de certificados a CA; estado de firma DNSSEC para todos los dominios con registros CAA; y requisitos básicos del Foro CA/B para cualquier actualización relacionada con CAA.

¿Cómo afectan los registros CAA a los entornos PKI en la nube, híbridos o con múltiples autoridades de certificación?

Los entornos con múltiples CA son donde los registros CAA se vuelven más complejos: cada dominio puede tener varias CA autorizadas (CA pública para TLS de cara al cliente, CA privada para servicios internos, CA del proveedor de la nube para cargas de trabajo nativas de la nube), y el registro CAA debe enumerarlas todas con precisión. Los subdominios aprovisionados en la nube que no se encuentran en el inventario DNS generan brechas de cobertura. Una plataforma CLM con detección entre entornos es un requisito previo para obtener registros CAA precisos en un entorno con múltiples CA y múltiples nubes.

¿Qué errores comunes deben evitar los equipos?

Los errores más frecuentes son: publicar registros CAA antes de auditar qué CA están emitiendo activamente (provoca fallos de renovación si se omite una CA activa); configurar issuewild sin configurar también issue (deja la emisión de certificados estándar abierta a cualquier CA); no incluir todas las CA utilizadas en todos los subdominios; no configurar DNSSEC (deja los registros CAA vulnerables al envenenamiento de la caché DNS); y no supervisar los informes iodef (elimina el valor de notificación de la etiqueta iodef).

¿Qué se debe renovar trimestralmente?

Trimestralmente: compare los registros CAA con la asignación actual de certificados a CA del inventario CLM; confirme que DNSSEC firma todos los dominios con registros CAA; revise los informes iodef del trimestre anterior; confirme que los nuevos dominios agregados desde la última auditoría tienen registros CAA; y verifique que los requisitos básicos del Foro CA/B no hayan introducido nuevas reglas de verificación de CAA. Para la planificación de la migración del algoritmo DNSSEC posterior a la computación cuántica, consulte el Centro de Excelencia PQC . Esta publicación se revisa trimestralmente.