Un registro CAA define qué autoridades de certificación pueden emitir certificados para un dominio. Sirve como salvaguarda. Una autoridad no listada debe rechazar la emisión. El CAA funciona por herencia. Sin regla en un subdominio se aplica la regla del apex.
Un registro CAA contiene un nombre, un tipo, una bandera, una etiqueta, un valor y un TTL. El TTL indica cuánto tiempo la respuesta permanece en caché en el resolutor local.
| Nombre | Tipo | Flag | Tag | Valor | TTL en segundos |
|---|
| @ | CAA | 0 | issue | "letsencrypt.org" | 3600 |
En este ejemplo la zona autoriza a Let's Encrypt a emitir certificados para el dominio. La bandera a cero conviene para los usos corrientes. El TTL a 3600 corresponde a una hora.
| Nombre | Tipo | Flag | Tag | Valor | Función |
|---|
| @ | CAA | 0 | issue | "digicert.com" | Autorizar una autoridad |
| @ | CAA | 0 | issuewild | "letsencrypt.org" | Autorizar certificados wildcard |
| @ | CAA | 0 | iodef | "mailto:security@ejemplo.com" | Recibir reportes de incidente |
| @ | CAA | 0 | issue | ";" | Prohibir toda emisión |
La etiqueta issue autoriza la emisión de certificados clásicos. La etiqueta issuewild se dirige a los certificados wildcard. La etiqueta iodef indica dónde enviar un reporte en caso de intento no autorizado.
Publicar el CAA en el apex para cubrir todo el dominio. Definir excepciones al nivel de un subdominio si es necesario.
El destino de un MX u otro servicio no cambia nada al CAA. La decisión de emisión se toma sobre el nombre del certificado objetivo.
La bandera crítica existe para usos avanzados. Un valor de ciento veintiocho pide a la autoridad comprender la etiqueta sino rechaza.
Un TTL corto hace visible un ajuste más rápido. Práctico durante un cambio de autoridad.
Un TTL medio o largo reduce las consultas hacia los servidores autoritarios. Adaptado a una política estable.
Reducir el TTL algunas horas antes del cambio luego subirlo después de la validación.
Bueno saber
La herencia es clave. Una regla establecida en tienda.ejemplo.com reemplaza la del apex para este subdominio. Sin regla local se aplica la regla padre.
En el apex para definir la política general. En un subdominio para otorgar una excepción controlada como un servicio gestionado por un tercero. Probar luego la emisión real en la autoridad objetivo.
A evitar
Olvidar el iodef que facilita las notificaciones.
Autorizar demasiadas autoridades lo que complica el control.
Dejar un CAA antiguo activo después de un cambio de proveedor.
Una búsqueda DNS en línea permite ingresar un nombre de dominio. El resultado muestra las etiquetas CAA y el TTL visible desde Internet. Es un primer control útil. Hacer luego una prueba local desde su máquina.
Windows proporciona nslookup. Se puede usar en modo interactivo.
nslookup
set q=caa
ejemplo.com
nslookup
set q=caa
server 1.1.1.1
ejemplo.com
La primera parte interroga según la configuración de red de la máquina. La segunda fuerza el uso de un resolutor tercero aquí el de Cloudflare.
En estos sistemas el comando dig es práctico y fácil de usar.
dig CAA ejemplo.com
dig CAA ejemplo.com @1.1.1.1
La presencia de una etiqueta issue o issuewild indica la autoridad autorizada. Un valor con punto y coma solo prohíbe la emisión.
Un TTL restante elevado puede explicar un desfase después de un cambio.
Una ausencia total de CAA significa ninguna restricción. Las autoridades pueden emitir según sus controles habituales.
- Listar la autoridad elegida y la eventual necesidad en wildcard.
- Publicar los CAA en el apex con un TTL reducido.
- Agregar iodef hacia una dirección de contacto funcional.
- Probar la emisión de un certificado de prueba en la autoridad.
- Subir el TTL cuando todo esté validado.
Consejo práctico
Mantener una ficha con la lista de los CAA publicados. Anotar la fecha, el TTL y la razón del cambio. Conservar la prueba de las pruebas de emisión exitosas.
Publicar una única etiqueta issue. Verificar que todos los servicios pasen por esta autoridad.
Agregar issuewild para la misma autoridad. Mantener issue para los certificados no wildcard.
Agregar iodef con un correo dedicado o una dirección https de recepción.
- Si la emisión falla verificar que la etiqueta issue o issuewild mencione bien la autoridad objetivo.
- Si la autoridad reclama una corrección verificar la herencia hasta el apex.
- Si el cambio no se tiene en cuenta esperar la expiración del TTL y purgar la caché del resolutor local si es posible.
En resumen, un registro CAA define quién puede emitir certificados para un dominio. Las etiquetas issue, issuewild e iodef cubren la mayoría de las necesidades. La herencia guía la decisión. Un TTL ajustado facilita la transición. La verificación pasa por una herramienta en línea luego por nslookup y por dig.
Con estas referencias la gestión permanece clara. Los cambios se desarrollan sin estrés. Los certificados se emiten según su política.