Resumen

  • accounturi y validationmethods restringen solamente la propiedad issue o issuewild que los contiene y solo cuando la autoridad certificadora reconoce esos parámetros.
  • Todas las vías de emisión que usan el mismo dominio identificador de la CA deben interpretar el soporte de forma coherente; separar identificadores es la salida prevista cuando no pueden hacerlo.
  • CAA expresa autoridad actual para emitir, no invalida certificados existentes ni hace que una propiedad restrictiva anule otra autorización aplicable.

La revisión más peligrosa de una política CAA puede terminar demasiado pronto. El operador encuentra una línea precisa: el dominio de la autoridad coincide, la URI de cuenta es la esperada y solo aparece el método dns-01. El cambio parece concluido. Dos líneas más abajo, otra propiedad issue autoriza a la misma CA sin parámetros. El DNS no contiene una negación; contiene dos caminos afirmativos.

Ese resultado procede de RFC 8659. Las autorizaciones CAA son aditivas. Una propiedad aplicable que autoriza no queda anulada porque otra sea más estrecha. Por eso la unidad de análisis no es la línea que el equipo acaba de editar, sino el conjunto pertinente para cada nombre solicitado.

RFC 8657 define cómo estrechar una propiedad individual. Cuando la CA reconoce accounturi, la solicitud debe proceder de la cuenta identificada por esa URI, además de coincidir con el dominio identificador de la CA. Si no hay parámetro, cualquier cuenta puede satisfacer esa propiedad. Una URI inválida o no reconocida, o varias apariciones del parámetro, hacen que esa propiedad no pueda autorizar.

La URI no es la credencial. Es un identificador público. En ACME puede ser la URI del objeto de cuenta; fuera de ACME, un sistema puede asignar otra. Publicarla permite correlacionar dominios y cuentas, pero no entrega por sí misma el control del account key ni traslada autorización entre CAs.

validationmethods restringe la propiedad a uno de los métodos enumerados. Una lista vacía no autoriza ningún método. Las etiquetas ACME tienen un registro; una vía no-ACME puede necesitar una etiqueta definida por la autoridad. Que el texto aparezca en DNS no prueba que el sistema que recibe la solicitud lo reconozca.

El soporte es opcional y específico del emisor. El titular del dominio necesita una declaración explícita. Let's Encrypt documenta su identificador letsencrypt.org, el formato de URI de cuenta y el reconocimiento de http-01, dns-01 y tls-alpn-01. Es un ejemplo público acotado, no una medición independiente de todos sus sistemas ni una afirmación sobre el resto del mercado.

Donde el estándar deja poco margen es en la coherencia interna. Todos los sistemas de emisión que usen un mismo dominio identificador deben reconocer los parámetros de la misma forma. RFC 8657 contempla la convivencia de canales ACME y no-ACME y la unión de sistemas antes separados. Si la CA no puede garantizar una interpretación común, puede emplear dominios identificadores diferentes. No debe anunciar el soporte bajo un nombre compartido mientras una vía lo interpreta de otro modo.

También debe evitar ambigüedad en las URI de cuenta a través de los dominios identificadores que reconoce. Una fusión de dos espacios donde ambos conservan “cuenta 1042” exige algo más que concatenar inventarios. Incluir una autoridad en la URI ayuda a mantener la procedencia. Esto no obliga a CAs no relacionadas a compartir una base de cuentas.

La rama wildcard cambia cuál propiedad se evalúa. Si existe issuewild, gobierna las solicitudes comodín y issue se ignora en ese caso. Para nombres ordinarios, issue sigue siendo la referencia. Una auditoría que prueba solo example.com puede no haber probado *.example.com en absoluto.

El bit crítico tampoco convierte los parámetros en una política de rechazo universal. Se refiere a etiquetas de propiedad desconocidas o incompatibles. Poner el valor crítico en issue no obliga a una CA a reconocer un parámetro que no admite. La etiqueta y sus parámetros son niveles diferentes de interpretación.

CAA se obtiene siguiendo alias durante la consulta, ascendiendo hasta el primer RRset no vacío y revisando todos los nombres de la solicitud. Una delegación puede establecer una política distinta. El emisor que implementa estas extensiones debe usar un resolvedor validador DNSSEC de confianza y proteger la comunicación con él. Una configuración demasiado estricta también puede impedir una renovación legítima.

La autorización y la emisión pueden ocurrir en momentos diferentes. Autorizaciones más breves o una nueva comprobación cerca de la emisión reducen el intervalo; el ejemplo aproximado de una hora en RFC 8657 no es una regla universal. Si una propiedad permisiva estuvo activa, los certificados emitidos entonces pueden seguir siendo válidos después de cerrarla.

La conclusión operativa es incómoda pero comprobable. Para afirmar que una restricción funciona hay que demostrar que no existe otra propiedad aplicable, que la rama de wildcard es la correcta, que el sistema reconoce cuenta y método, y que todas las vías detrás del mismo identificador toman la misma decisión.

Fuentes

  1. RFC 8657 — Extensiones CAA para URI de cuenta y vinculación del método ACME
  2. RFC 8659 — Registro DNS Certification Authority Authorization
  3. Let's Encrypt — Documentación sobre CAA
  4. Heng Lu — El problema de agencia en el núcleo de la gobernanza de Internet
  5. Heng Lu — Por qué existe BTW Media y por qué el producto es la realidad