DNS-01 Challenge

El DNS-01 Challenge valida el control del dominio a través de un registro TXT en DNS, sin necesidad de servidor web accesible.

Este es el único método que permite generar certificados wildcard (*.domain.com), que funcionan automáticamente para todos los subdominios de tu dominio - sea api.domain.com, blog.domain.com, admin.domain.com o cualquier otro que crees en el futuro.

¿Cómo funciona?

Entendiendo el flujo:

El diagrama arriba muestra la comunicación entre tres componentes: el Cliente ACME (como Certbot o acme.sh), el servidor de Let's Encrypt, y el Servidor DNS de tu dominio.

Solicitud inicial: El cliente ACME (corriendo en cualquier máquina con acceso a internet) solicita un certificado para el dominio deseado
Desafío DNS: Let's Encrypt responde con un token único e instruye: "demuestra que controlas este dominio creando un registro TXT específico"
Creación del registro: El cliente ACME usa la API de tu proveedor DNS (Cloudflare, Route53, etc.) para crear automáticamente el registro TXT _acme-challenge.domain.com con el token recibido
Verificación: Let's Encrypt consulta los servidores DNS públicos para verificar si el registro TXT existe y contiene el token correcto
Emisión: Después de validación exitosa, Let's Encrypt emite el certificado y lo envía al cliente ACME
Limpieza: El registro TXT puede ser removido después de la emisión (el cliente ACME generalmente lo hace automáticamente)

Certbot corre separadamente

El cliente ACME (Certbot) no necesita correr en el mismo servidor de tus aplicaciones. Solo necesita:

Acceso a internet para comunicar con Let's Encrypt
Credenciales de la API de tu proveedor DNS para crear/remover registros TXT
Un lugar para guardar los certificados generados

Después de la emisión, distribuyes los certificados a los servidores que los necesitan (vía rsync, NFS, Kubernetes Secrets, etc.).

Ejemplo de registro DNS

# Registro TXT que necesita ser creado
_acme-challenge.domain.com. 300 IN TXT "gfj9Xq...Rg85nM"

¿Cuándo usar DNS-01?

Escenario	¿Por qué usar DNS-01?
Certificados Wildcard	Único método que soporta `*.domain.com`
Servidores internos	No requiere exposición pública en el puerto 80
Múltiples servidores	Un certificado para varios servidores
Puerto 80 bloqueado	Firewall o ISP bloquea HTTP

Automatización con DNS Providers

El mayor desafío de DNS-01 es la automatización. Crear registros TXT manualmente no escala. La solución es usar plugins que integran con la API de tu proveedor DNS.

Certbot con plugins DNS

# Cloudflare
sudo apt install python3-certbot-dns-cloudflare
certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d "*.domain.com" -d domain.com

# Route53 (AWS)
sudo apt install python3-certbot-dns-route53
certbot certonly --dns-route53 -d "*.domain.com"

# Google Cloud DNS
sudo apt install python3-certbot-dns-google
certbot certonly --dns-google \
  --dns-google-credentials ~/.secrets/google.json \
  -d "*.domain.com"

Archivo de credenciales (ejemplo Cloudflare)

# ~/.secrets/cloudflare.ini
dns_cloudflare_api_token = tu_token_aqui

# Permisos seguros
chmod 600 ~/.secrets/cloudflare.ini

acme.sh (alternativa ligera)

acme.sh es un cliente ACME en shell script puro, más ligero que Certbot.

# Ejemplo: Certificado wildcard con Cloudflare
export CF_Token="tu_token"
acme.sh --issue --dns dns_cf -d "*.domain.com" -d domain.com

# Ejemplo: Certificado wildcard con AWS Route53
export AWS_ACCESS_KEY_ID="xxx"
export AWS_SECRET_ACCESS_KEY="xxx"
acme.sh --issue --dns dns_aws -d "*.domain.com"

Seguridad de Wildcards

Un certificado wildcard comprometido afecta todos los subdominios. Considera certificados específicos para subdominios críticos (api, admin, etc).

Propagación de DNS

El DNS-01 depende de la propagación del registro TXT:

# Verificar si el registro propagó
dig TXT _acme-challenge.domain.com

# Tiempo de propagación típico
# - Cloudflare: segundos
# - Route53: 60 segundos
# - Registradores tradicionales: hasta 48 horas

Problema común: validación falla por propagación

Escenario: Certbot crea el registro TXT e inmediatamente pide a Let's Encrypt que verifique. Pero Let's Encrypt consulta servidores DNS que aún no recibieron la actualización → validación falla.

Solución: Usa --dns-cloudflare-propagation-seconds 60 para forzar a Certbot a esperar 60 segundos después de crear el registro antes de solicitar verificación. Ajusta el valor según tu proveedor DNS.

Ventajas y Desventajas

Ventajas:

Soporta certificados wildcard
Funciona con servidores internos (no expuestos a internet)
No requiere puerto 80 abierto
Un certificado puede servir múltiples servidores

Desventajas:

Requiere acceso a la API del DNS provider
Propagación de DNS puede demorar
Más complejo de configurar inicialmente
Credenciales de DNS son sensibles

Distribución para múltiples servidores

Cuando tienes varias máquinas en ambientes separados, existen diferentes estrategias para distribuir los certificados:

Por complejidad creciente

Escenario	Solución recomendada
Pocos servidores, misma red	rsync/scp con cron
Multi-cloud o redes aisladas	HashiCorp Vault o AWS Secrets Manager
Kubernetes	cert-manager (emite directo en el cluster)
CDN/Load Balancer	Terminación TLS centralizada

1. rsync/scp (simple)

# En el servidor con Certbot, después de renovación
certbot renew --deploy-hook "rsync -avz /etc/letsencrypt/ user@server2:/etc/letsencrypt/"

2. HashiCorp Vault (multi-ambiente)

# Almacena certificado en Vault
vault kv put secret/certs/wildcard \
  cert=@/etc/letsencrypt/live/domain.com/fullchain.pem \
  key=@/etc/letsencrypt/live/domain.com/privkey.pem

# Cada servidor busca de Vault
vault kv get -field=cert secret/certs/wildcard > /etc/ssl/cert.pem

3. Kubernetes cert-manager

Para Kubernetes, cert-manager es la solución estándar - emite certificados directamente en el cluster:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - dns01:
        cloudflare:
          apiTokenSecretRef:
            name: cloudflare-api-token
            key: api-token

4. Terminación TLS centralizada

El enfoque más simple para múltiples servidores: centralizar el TLS en el load balancer.

Los servidores backend no necesitan el certificado - la comunicación interna puede ser HTTP (en red privada) o mTLS.

Proveedores DNS soportados

Certbot y acme.sh soportan diversos proveedores:

Populares: Cloudflare, AWS Route53, Google Cloud DNS, DigitalOcean
Registradores: GoDaddy, Namecheap, OVH, Gandi
Otros: Azure DNS, Linode, Vultr, DNSimple

Consulta la documentación del cliente ACME para la lista completa de plugins disponibles.

¿Cómo funciona?​

Ejemplo de registro DNS​

¿Cuándo usar DNS-01?​

Automatización con DNS Providers​

Certbot con plugins DNS​

Archivo de credenciales (ejemplo Cloudflare)​

acme.sh (alternativa ligera)​

Propagación de DNS​

Ventajas y Desventajas​

Distribución para múltiples servidores​

Por complejidad creciente​

1. rsync/scp (simple)​

2. HashiCorp Vault (multi-ambiente)​

3. Kubernetes cert-manager​

4. Terminación TLS centralizada​

Proveedores DNS soportados​