En Enero de 2013, Rob Stradling propuso y formalizó la implementación de un estándar para la Autorización de Entidades de Certificación (Certification Authority Authorization, por sus siglas en inglés) mediante el RFC 6844.

El propósito de los registros CAA es "designar" una o más entidades de certificación a emitir certificados SSL/TLS a un dominio o subdominio específicos. Los dueños de dominios podrán, además, declarar una dirección de correo electrónico para recibir notificaciones en caso que alguien solicite un certificado a una entidad de certificación no autorizada.

De no existir un registro CAA, cualquier entidad está autorizada a emitir certificados para ese dominio o subdominio.

Si bien el estándar data del año 2013, no fue hasta hace algunos meses que los proveedores de DNS y las entidades de certificación comenzaron su implementación. Algunos de ellos aun no aceptan registros del tipo CAA y otros aun no verifican la existencia del registro antes de emitir sus certificados, pero están gradualmente modificando sus infraestructuras para hacerlo. En mi caso utilizo DNS Made Easy desde hace algunos años y, además de soportar este tipo de registros, siempre he tenido estupendos resultados.

En lo que respecta a la creación de registros CAA, están compuestos por tres elementos. Demos un vistazo a su topología:

• flag: Un entero entre 0 y 255.
• tag: Existen tres tags definidos por el RFC.
• issue: Permite autorizar explícitamente a una única entidad de certificación a emitir certificados para ese dominio o subdominio. De ser necesario autorizar a más de una, se deberán crear múltiples registros CAA.
• issuewild: Permite autorizar explícitamente a una única entidad de certificación a emitir certificados de comodín (wildcard) para ese dominio/subdominio. Ningún otro certificado que no sea wildcard podrá ser emitido por esa entidad, salvo que esté expresamente configurado.
• iodef: Especifica a dónde deben enviarse los reportes de intentos de emisión de certificados por una entidad no autorizada (El formato debe ser "mailto:[email protected]").
• value: El valor del registro.

Vamos con algunos ejemplos:

Si queremos autorizar a Let’s Encrypt y a Comodo, debemos agregar un registro CAA para cada entidad:

pablofain.com.  CAA 0 issue "comodo.com"
 pablofain.com.  CAA 0 issue "letsencrypt.org"

Si la idea es autorizar a Let’s Encrypt y a Comodo, pero solo a esta última para emitir certificados wildcard, debemos configurar los registros de la siguiente manera:

pablofain.com.  CAA 0 issue "letsencrypt.org"
 pablofain.com.  CAA 0 issuewild "comodo.com"
 

Para recibir una notificación sobre el intento de emisión de certificados mediante una entidad de certificación no autorizada:

pablofain.com.  CAA 0 iodef "mailto:[email protected]"
 

Finalmente, para el caso de los subdominios podemos configurar cada uno de ellos para autorizar a diferentes entidades de certificación. En este ejemplo, Let’s Encrypt podría emitir certificados para todos los subdominios de pablofain.com, excepto sub1 y sub2.

pablofain.com.        CAA 0 issue "letsencrypt.org"
 sub1.pablofain.com.   CAA 0 issue "comodo.com"
 sub2.pablofain.com.   CAA 0 issue "rapidssl.com"
 

Hasta Abril de 2017, las entidades de certificación que verifican la existencia de registros CAA son: Amazon, Certum, Comodo, DigiCert, Entrust, GlobalSign, GoDaddy, Izenpe, QuoVadis, Starfield GoDaddy, StartCom WoSign, Let’s Encrypt, Symantec, GeoTrust, Thawte, T-Telesec, Trustwave y WoSign.

En cuanto a las desventajas o puntos débiles de CAA, a simple vista podemos observar dos:

• Si la entidad de certificación ha quedado comprometida o no realiza la verificación de registros CAA, el certificado podría ser emitido con normalidad.
• Si la zona DNS del dominio ha quedado comprometida, el registro CAA podría modificarse por el valor deseado por el atacante. Una buena idea para prevenir esto es implementar DNSSEC.

Si necesitan ayuda para configurar sus registros CAA, el sitio SSLMate ofrece un wizard que funciona a la perfección.

Fuente: Pablo Fain