En esta publicación veremos qué son los registros CAA y cómo pueden elevar el nivel de seguridad de nuestro dominio. También explicaremos el proceso para definir y publicar una serie de registros CAA en nuestro dominio.

Siglas y términos

En este apartado definiremos las abreviaturas que el RFC6844 considera importantes para la comprensión de este concepto.

• RFC: Request For Comments, forma que tiene la comunidad técnica de proponer, debatir y afianzar estándares.
• Authorization Entry: concede o deniega un conjunto específico de permisos a un grupo de entidades.
• Certificate: un certificado en formato X.509, tal y como se define en RFC5280.
• Certificate Evaluator: Una parte que no es una parte de confianza que evalúa la fiabilidad de los certificados emitidos por las Autoridades de Certificación.
• Certification Authority (CA): Autoridad de Certificación, un emisor que emite certificados de acuerdo con una Política de Certificación especificada.
• Certification Practices Statement (CPS): Especifica los medios por los que se cumplen los criterios de la política de certificación. En la mayoría de los casos, éste será el documento contra el que se auditan las operaciones de la Autoridad de Certificación. Véase RFC3647.
• Issuer: Emisor, una entitidad que emite certificados.
• Property: La porción clave-valor de el Registro de Recursos (RR) de CAA.

Como he indicado anteriormente, este es otro de los muchos protocolos surgidos para mejorar la seguridad de Internet. Si bien está afianzado y usado por grandes empresas y muchos usuarios, merece la pena destacar el proceso de generación de estándares:

¿Qué es un registro CAA?

Según la Fábrica Nacional de Moneda y Timbre (FNMT), podemos definir un registro CAA de la siguiente manera:

Un Registro AAC (CAA record) permite a un titular de nombre de dominio DNS especificar qué Autoridades de Certificación están autorizadas para emitir certificados para ese dominio. Así, la publicación de los registros de recursos de CAA permite a un titular de nombres de dominio implementar controles adicionales para reducir el riesgo de que se produzca una emisión no autorizada de un Certificado de autenticación de sitio web para su nombre de dominio.

Es, por tanto, muy similar en definición a SPF: aunque para otra tecnología, claro. Al igual que en SPF indicamos desde qué orígenes vamos a enviar correos electrónicos, con el registro SPF podemos definir qué Autoridades de Certificación (CA en la jerga de certificados y PKI) queremos que sean consideradas autorizadas para emitir certificados para nuestro dominio.

El estándar de este Resource Registry (RR) y los detalles que lo rodean están recogidos en el RFC6844.  

Formato de un registro CAA

Veamos los registros CAA de Google:

pablo@equipo:$ dig CAA google.com +short
0 issue "pki.goog"

Veamos también los registros CAA de Cloudflare:

pablo@equipo:$ dig CAA cloudflare.com +short

0 iodef "mailto:[email protected]"
0 issue "comodoca.com"
0 issue "digicert.com; cansignhttpexchanges=yes"
0 issue "letsencrypt.org"
0 issue "pki.goog; cansignhttpexchanges=yes"
0 issuewild "comodoca.com"
0 issuewild "digicert.com; cansignhttpexchanges=yes"
0 issuewild "letsencrypt.org"
0 issuewild "pki.goog; cansignhttpexchanges=yes"```

(Microsoft en el momento de escribir este artículo de blog no tiene publicados registros de CAA).

Por tanto podemos dividirlo en:

Issuer critical // "0"

Es el 0 inicial de los registros  arriba mostrados. Según el RFC, este bit indica:

If set to '1', indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer. Issuers MUST NOT issue certificates for a domain if the relevant CAA Resource Record set contains unknown property tags that have the Critical bit set.

Property tags // "issue" / "issuewild" / "iodef"

Es un par clave-valor. En este par, la clave es la primera palabra, y el valores lo definido a continuación. Puede contener detalles adicionales a continuación.

Si los detalles indicados aquí están a nivel raíz del dominio, se aplicarán a todos los subdominios. Es posible definir registros CAA en niveles inferiores.

En el caso de "issue", solo las CA indicadas podrán emitir certificados para el nombre de dominio afectado por el RR.

En el caso de "issuewild", solo las CA indicadas podrán emitir certificados wildcard para el nombre de dominio afectado por el RR.

En el caso de "iodef", especifica la forma de reportar solicitudes de emisión de certificados que no son conformes con la política definida en los CAA publicados.

Definir el registro CAA a publicar

Lo primero que debemos hacer es conocer desde qué Autoridades de Certificación (AC) se publican certificados para nuestro dominio.

Aunque al principio puede parecer algo sencillo de responder, lo cierto es que si tenemos alguna clase de hosting gestionado podemos tener alguna sorpresa.

Certificate logs

Para los certificados que se han emitido con anterioridad podemos consultar los Certificados de Transparencia de Certificados, Certificate Transparency (CT) Logs.  

Esta solución viene a resolver la pregunta de "¿Quién controla al que controla?". Cuando una AC emite un certificado, envía la entrada y algunos datos a uno o varios registros/logs independientes. De esta forma, cualquiera puede consultarlo.

Se intenta evitar que ocurra algo similar a la brecha de seguridad descubierta en 2011 con la AC DigiNotar. Esta AC emitió certificados para subdominios de google.com. Puesto que la AC era "confiable", los navegadores confiaban en los certificados. De forma previa a los Certificados de Transparencia, se implementaron soluciones como el HPKP, HTTP Public Key .

Ver los Certificados anteriores

A través de esta página de Sectigo podemos consultar los certificados emitidos para un dominio que han sido incluidos en los Registros de Transparencia.

Esta es una captura de pantalla del informe para mi dominio.

De la anterior pantalla podemos sacar en claro:

• Let's Encrypt es la AC que más certificados emite para este dominio. No son wildcard.
• Google Trust Service también emite certificados en nuestro nombre. En concreto, para sitios en Firebase y Google Sites. No son wildcard.
• Cloudflare emite un solo certificado de forma puntual, pero siendo este wildcard.

Hay herramientas, como esta de SSLMate, que pueden ayudarnos a generar los registros adecuados.

Crear el registro

Puesto que ninguno de nuestros certificados son críticos (aunque nosotros nos creamos que lo son), el primer valor será cero. Añadiremos la clave issue para todas las entradas e issuewild para Cloudflare.

0 issue "letsencrypt.org"
0 issue "pki.goog"
0 issuewild "digicert.com"

La última entrada es debido a que Cloudflare emite a través de un sub-certificado emitido por Digicert.

También añadiremos un registro para reportar intentos de emisión de certificados fuera de lo declarado:

0 iodef "mailto:[email protected]"

Publicar el registro

El proceso de adición de este tipo de registros es similar a añadir cualquier otro. Algunos proveedores tiene una especie de asistente, pero las variaciones serán leves. Este es el caso de Cloudflare, que en lugar de issue, issuewild e iodef, permite al usuario escogerlo de un desplegable.

Añadiremos un nuevo registro para cada CA y política de notificación. En nuestro caso tendremos 4 registros (3+1), como podemos ver en la siguiente captura de pantalla:

Aunque al principio pueda sorprender al ver más registros de los añadidos, CloudFlare automáticamente añade una serie de registros para asegurar la emisión de certificados para su servicio. Al realizar la consulta veremos el siguiente resultado:

Hasta aquí esta entrada de blog, si quieres conocer más información sobre CAA te recomiendo esta publicación en el Blog de Cloudflare. A su vez, si eres cliente de este proveedor, puedes hacer que te notifiquen cada vez que se añada un certificado para tu dominio a los Registros de Transparencia.

Este es un ejemplo de notificación:

¿Alguna duda?

No dudes en ponerte en contacto conmigo para cualquier duda, sugerencia, queja o aclaración que creas necesaria. ¡Será un placer hablar contigo!