Skip to content

Verificador de Registros CAA Online Gratis

En el navegador · consultas a APIs públicas
Última verificación junio 2026 — corre en tu navegador

Verificador de Registros CAA — Autoriza CAs, Bloquea Emisión No Autorizada

CAA (Certification Authority Authorization, RFC 8659 Hallam-Baker, Stradling y Hoffman-Andrews 2019, obsoleta el RFC 6844) es un tipo de registro DNS que permite a los propietarios de dominios especificar qué Autoridades Certificadoras están autorizadas a emitir certificados para su dominio. Desde el 8 de septiembre de 2017 los CA/Browser Forum Baseline Requirements §3.2.2.8 (Ballot 187, versión 1.4.3) obligan a todas las CAs públicamente confiadas a comprobar CAA antes de emitir — una CA que ignore o aplique mal CAA puede perder su anclaje de confianza en los programas raíz. La sintaxis del registro tiene tres etiquetas de propiedad: issue autoriza a una CA específica a emitir cualquier certificado, issuewild controla los certificados wildcard por separado, y iodef apunta a un endpoint de reporte de incidentes (formato IODEF de RFC 5070) donde la CA notifica violaciones de política. RFC 8657 (Landau, 2019) añadió los parámetros accounturi y validationmethods que restringen aún más la emisión a cuentas ACME específicas y métodos de validación. Esta herramienta obtiene registros CAA vía Cloudflare DNS-over-HTTPS, recorre el árbol DNS desde el FQDN consultado hasta el apex mostrando políticas heredadas, y marca el bit crítico (flags=128) cuando está activo.

Relacionado:

Verificador SSL Verifica estado de certificado SSL/TLS, HSTS y logs de transparencia Búsqueda DNS Consulta registros DNS de cualquier dominio — A, AAAA, MX, CNAME, TXT, NS, SOA Búsqueda WHOIS Consulta detalles de registro de dominio, registrador y nameservers via RDAP Cabeceras HTTP Inspecciona cabeceras HTTP de respuesta y análisis de seguridad Verificador de Redirecciones Traza la cadena completa de redirecciones de cualquier URL con códigos de estado Verificador CAA Comprueba qué Autoridades Certificadoras pueden emitir certificados SSL para un dominio

Cómo comprobar registros CAA

  1. Introduce un nombre de dominio (FQDN o apex).
  2. La herramienta consulta el registro CAA vía Cloudflare DoH, luego recorre el árbol DNS si el FQDN no tiene — reportando políticas heredadas de zonas ancestras (RFC 8659 §3).
  3. Revisa los valores issue, issuewild e iodef; el bit crítico (flags=128) se resalta cuando está activo.
  4. Si la política está vacía o es incorrecta, arregla los registros DNS antes de la próxima renovación — la emisión fallará según CA/Browser Forum BR §3.2.2.8.

Casos de uso comunes

  • Restringir la emisión de certificados a una sola CA (p.ej., Let's Encrypt) para reducir el riesgo de emisión indebida.
  • Depurar un fallo de emisión ACME que se queja de discrepancias CAA.
  • Auditar qué CAs están autorizadas para un dominio antes de una revisión de seguridad o auditoría de cumplimiento.
  • Añadir contactos iodef (RFC 5070 IODEF) para que los intentos de emisión no autorizados se reporten al equipo de seguridad.

Preguntas frecuentes

¿Qué hace realmente un registro CAA?

RFC 8659 (2019, obsoleta RFC 6844) permite a un dominio restringir qué CAs pueden emitir certificados para él. Desde el 8 de septiembre de 2017 (CA/B Forum BR §3.2.2.8), todas las CAs públicamente confiadas DEBEN comprobar CAA antes de emitir — una CA no conforme pierde su anclaje de confianza en programa raíz.

¿Cuál es la diferencia entre issue e issuewild?

issue autoriza a una CA a emitir certificados estándar. issuewild controla wildcards (*.ejemplo.com) específicamente. Si publicas issuewild, los wildcards la siguen ignorando issue. Patrón: permitir LE para estándar via issue, excluir wildcards publicando issuewild vacío.

¿CAA aplica al apex o a subdominios?

Heredado por el árbol DNS — comprueba el nombre exacto primero, luego sube: api.app.ejemplo.com → app.ejemplo.com → ejemplo.com. La primera zona con registros CAA aplica (RFC 8659 §3). Publica en el apex para cubrir todo lo de abajo.

¿Qué pasa si no publico CAA?

Cualquier CA públicamente confiada puede emitir certificados para tu dominio. La mayoría de dominios operan así — los logs Certificate Transparency detectan emisiones indebidas a posteriori vía monitorización. CAA añade una capa de prevención en el momento de emisión.

¿Puedo restringir CAA a una cuenta ACME específica o método de validación?

Sí — RFC 8657 (Landau, 2019) añadió los parámetros accounturi y validationmethods. accounturi restringe la emisión a un URI de cuenta ACME específico; validationmethods limita qué métodos de validación de dominio (DNS-01, HTTP-01, TLS-ALPN-01) puede usar la CA. Boulder de Let's Encrypt honra ambos desde 2022.

Cómo funciona la consulta tree-climbing y cómo CAA se complementa con Certificate Transparency

Sin un registro CAA, cualquier CA en los programas raíz públicamente confiados (navegadores, almacenes de raíces del SO) puede emitir un certificado para tu dominio — la restricción es procedimental (política de validación propia de la CA) más que aplicada. CAA endurece esto a una comprobación procedimental-más-DNS: la CA consulta el registro CAA antes de emitir y rechaza si la política la excluye. La consulta recorre la jerarquía DNS: una petición para mail.api.ejemplo.com primero comprueba mail.api.ejemplo.com, luego api.ejemplo.com y luego ejemplo.com, parando en la primera zona con registros CAA (RFC 8659 §3). Esto significa que publicar CAA en el apex cubre todo lo de abajo; los registros específicos de subdominio sobrescriben la política del apex para esa rama. El flag bit crítico (issuer-critical, valor 128) gobierna el manejo de etiquetas no reconocidas: si una CA encuentra una etiqueta que no entiende Y el bit crítico está activo, DEBE rechazar la emisión. Útil para desplegar tipos de etiqueta nuevos sin romper CAs antiguas. CAA no reemplaza la monitorización de Certificate Transparency — los logs CT (consultables vía herramientas como crt.sh) detectan emisiones indebidas a posteriori mientras CAA las previene en el momento de emisión. Las dos capas se complementan: CAA para prevención, CT para detección.

  • Recuperación de registros CAA vía Cloudflare DNS-over-HTTPS (RFC 8659)
  • Consulta tree-climbing desde FQDN al apex (políticas heredadas explicitadas)
  • Etiquetas admitidas: issue, issuewild, iodef + RFC 8657 accounturi/validationmethods
  • Detección de flag bit crítico (flags=128 enforcement de etiquetas no reconocidas)
  • Comprobación CAA obligatoria según CA/Browser Forum BR §3.2.2.8 (efectiva 2017-09-08)
  • Trazado de herencia de subdominio al apex con cadena explícita

Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.

Fuentes (5)
  • Hallam-Baker, P., Stradling, R., & Hoffman-Andrews, J. (2019). DNS Certification Authority Authorization (CAA) Resource Record. RFC 8659, IETF (obsoletes RFC 6844).
  • Hallam-Baker, P., & Stradling, R. (2013). DNS Certification Authority Authorization (CAA) Resource Record. RFC 6844, IETF (original spec, obsoleted by RFC 8659).
  • Landau, H. (2019). CAA Record Extensions for Account URI and ACME Method Binding. RFC 8657, IETF (accounturi, validationmethods parameters).
  • CA/Browser Forum (2017). Baseline Requirements §3.2.2.8 — CAA Records (Ballot 187 v1.4.3). Effective 8 September 2017 (cabforum.org).
  • Danyliw, R., Meijer, J., & Demchenko, Y. (2007). The Incident Object Description Exchange Format (IODEF). RFC 5070, IETF (iodef tag context for incident reporting).

Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.

Guías relacionadas

Por ·