Caddy como Proxy Inverso

Caddy, cuando se configura como un proxy inverso, aprovisiona, renueva y gestiona automáticamente los certificados TLS para sus dominios utilizando proveedores ACME como Let's Encrypt o ZeroSSL, habilitando HTTPS por defecto sin intervención manual. Esta característica simplifica la implementación de servidores web seguros al eliminar la necesidad de tareas manuales de gestión de certificados.

Entendiendo el HTTPS Automático de Caddy

El principal diferenciador de Caddy es su enfoque de configuración cero para HTTPS. Cuando Caddy recibe una solicitud para un dominio, intenta obtener un certificado TLS para ese dominio si no existe uno ya o no está configurado explícitamente. Este proceso aprovecha el protocolo ACME (Automatic Certificate Management Environment).

Cómo Interactúan ACME y Caddy

1. Resolución de Dominio: Caddy identifica el nombre de dominio asociado con la solicitud entrante.
2. Verificación de Certificado: Comprueba en su almacenamiento local si existe un certificado válido para ese dominio.
3. Desafío ACME: Si no se encuentra un certificado válido, Caddy inicia un desafío ACME con un proveedor ACME configurado (por defecto Let's Encrypt, con ZeroSSL como respaldo). Los tipos de desafío más comunes son HTTP-01 y DNS-01.
   • Desafío HTTP-01: Caddy crea un archivo temporal en una ruta específica (/.well-known/acme-challenge/) en el servidor. El proveedor ACME intenta acceder a este archivo a través de HTTP en el puerto 80 para verificar la propiedad del dominio. Esto requiere que Caddy sea accesible públicamente en el puerto 80.
   • Desafío DNS-01: Caddy instruye al proveedor ACME para que verifique la propiedad del dominio buscando un registro TXT específico en la zona DNS del dominio. Este método es necesario para certificados wildcard y puede usarse cuando el puerto 80 no está disponible. Requiere que Caddy tenga credenciales para un proveedor de DNS compatible.
4. Emisión de Certificado: Una vez completado el desafío con éxito, el proveedor ACME emite un certificado TLS para el dominio.
5. Almacenamiento de Certificado: Caddy almacena el certificado y su clave privada de forma segura en el disco.
6. Renovación Automática: Caddy monitorea las fechas de vencimiento de los certificados y los renueva automáticamente con mucha antelación (típicamente 30 días antes del vencimiento) utilizando el mismo proceso de desafío ACME.
7. OCSP Stapling: Caddy también obtiene y "grapa" automáticamente las respuestas OCSP a los certificados, mejorando el rendimiento y la privacidad del cliente al permitir que los clientes verifiquen el estado de revocación del certificado sin contactar directamente a la Autoridad de Certificación.

Configuración Básica de Proxy Inverso con HTTPS Automático

Una configuración mínima de Caddyfile para un proxy inverso habilita implícitamente HTTPS automático.

Ejemplo Simple de Proxy Inverso

yourdomain.com {
    reverse_proxy localhost:8080
}

En este ejemplo:
* yourdomain.com: Esta es la etiqueta del sitio. Caddy escuchará las solicitudes a este dominio tanto en el puerto 80 (para redirecciones HTTP y desafíos ACME) como en el 443 (para HTTPS).
* reverse_proxy localhost:8080: Esta directiva reenvía todas las solicitudes entrantes para yourdomain.com a una aplicación upstream que se ejecuta en localhost en el puerto 8080.

Cuando Caddy se inicia con esta configuración, realiza los siguientes pasos automáticamente:
1. Intenta obtener un certificado TLS para yourdomain.com de un proveedor ACME.
2. Configura redirecciones de HTTP a HTTPS para todo el tráfico en el puerto 80.
3. Sirve yourdomain.com a través de HTTPS utilizando el certificado obtenido.

Ejecutando Caddy

Para ejecutar Caddy con esta configuración:

1. Guarde el contenido anterior como Caddyfile en su directorio deseado.
2. Navegue a ese directorio en su terminal.
3. Ejecute: caddy run

Para entornos de producción, se recomienda ejecutar Caddy como un servicio systemd o dentro de un contenedor Docker.

Configuraciones Avanzadas de HTTPS

Certificados Personalizados

Si tiene certificados TLS preexistentes (por ejemplo, de una CA empresarial o certificados wildcard obtenidos manualmente), Caddy puede configurarse para usarlos en lugar de aprovisionarlos automáticamente.

yourdomain.com {
    tls /path/to/your/cert.pem /path/to/your/key.pem
    reverse_proxy localhost:8080
}

• tls /path/to/your/cert.pem /path/to/your/key.pem: Especifica el archivo de certificado de cadena completa y el archivo de clave privada. Caddy utilizará estos archivos y no intentará aprovisionar un certificado para yourdomain.com.

Certificados Wildcard con Desafío DNS-01

Los certificados wildcard (*.yourdomain.com) requieren el desafío ACME DNS-01 porque el desafío HTTP-01 no puede probar la propiedad de subdominios arbitrarios. Esto requiere configurar Caddy con credenciales para su proveedor de DNS.

*.yourdomain.com {
    tls {
        dns cloudflare {
            api_token "YOUR_CLOUDFLARE_API_TOKEN"
        }
    }
    reverse_proxy localhost:8080
}

• tls { dns cloudflare { ... } }: Este bloque le dice a Caddy que use el desafío DNS-01 con el proveedor de DNS Cloudflare.
• api_token "YOUR_CLOUDFLARE_API_TOKEN": Reemplace esto con su token API real de Cloudflare. Caddy admite numerosos proveedores de DNS a través de plugins. Consulte la documentación de Caddy para configuraciones específicas de proveedores.

Múltiples Dominios y Bloques de Sitio

Caddy puede servir múltiples dominios, cada uno con su propio HTTPS automático.

yourdomain.com {
    reverse_proxy localhost:8080
}

anotherdomain.org {
    reverse_proxy localhost:8081
}

Caddy aprovisionará y gestionará certificados de forma independiente para yourdomain.com y anotherdomain.org.

Comparación de Desafíos HTTP-01 vs. DNS-01

Proveedores ACME

Caddy utiliza por defecto Let's Encrypt para el aprovisionamiento de certificados. ZeroSSL se usa como respaldo. Puede configurar explícitamente qué proveedor ACME usar.

yourdomain.com {
    tls your_email@example.com {
        ca https://acme-v02.api.letsencrypt.org/directory
    }
    reverse_proxy localhost:8080
}

• ca https://acme-v02.api.letsencrypt.org/directory: Especifica la URL de la CA ACME.
• your_email@example.com: Se recomienda proporcionar una dirección de correo electrónico para el registro de la cuenta ACME y notificaciones importantes de la CA.

Gestión de Certificados

Caddy gestiona los certificados automáticamente, pero comprender su almacenamiento y las opciones manuales puede ser útil.

Almacenamiento de Certificados

Por defecto, Caddy almacena los certificados, las claves privadas y la información de la cuenta ACME en un directorio de datos. La ubicación exacta depende del sistema operativo y de cómo se ejecute Caddy:
* Linux: /var/lib/caddy/.local/share/caddy (cuando se ejecuta como root a través de systemd) o $HOME/.local/share/caddy (cuando se ejecuta como usuario).
* Docker: Dentro del volumen /data del contenedor.

Este directorio debe ser persistente (por ejemplo, un volumen montado en Docker) para evitar el reaprovisionamiento de certificados en los reinicios.

Renovación y Revocación Manual

Aunque Caddy automatiza la renovación, rara vez es necesaria la interacción directa con el almacén de certificados.
* Renovación: Si se requiere una renovación inmediata (por ejemplo, después de un compromiso de certificado), puede eliminar los archivos de certificado específicos del directorio de datos de Caddy. Caddy intentará entonces aprovisionar uno nuevo en el siguiente inicio o solicitud.
* Revocación: La revocación de certificados es una operación avanzada, típicamente realizada si una clave privada se ve comprometida. Caddy no proporciona una utilidad de línea de comandos directa para la revocación. Esto se haría normalmente a través de la API del proveedor ACME o un cliente dedicado si fuera necesario.

Solución de Problemas Comunes de HTTPS

Configuración del Firewall

Asegúrese de que los puertos 80 y 443 estén abiertos al tráfico entrante en su servidor Caddy. El puerto 80 es crucial para el desafío ACME HTTP-01 y para las redirecciones de HTTP a HTTPS.

Propagación de DNS

Si utiliza el desafío DNS-01, verifique que sus registros DNS (específicamente el registro TXT para el desafío) se hayan propagado correctamente. Utilice herramientas como dig o servicios de búsqueda de DNS en línea. Una propagación de DNS incorrecta o lenta puede impedir la emisión del certificado.

Límites de Tasa de ACME

Los proveedores ACME como Let's Encrypt tienen límites de tasa en la emisión de certificados. Los intentos fallidos repetidos pueden llevar a bloqueos temporales.
* Entorno de Staging: Utilice el entorno de staging de ACME para realizar pruebas y evitar alcanzar los límites de tasa de producción.
caddyfile yourdomain.com { tls your_email@example.com { ca https://acme-staging-v02.api.letsencrypt.org/directory } reverse_proxy localhost:8080 }
* Consolidar Dominios: Si sirve muchos subdominios, considere un certificado wildcard para reducir el número de solicitudes de certificados individuales.

Registros de Caddy

Los registros de Caddy proporcionan información detallada sobre los intentos de aprovisionamiento de certificados, las renovaciones y cualquier error. Revise los registros para ver mensajes de error específicos si HTTPS no funciona como se espera.
* Ubicación de Registro por Defecto: Los registros se escriben típicamente en la salida estándar (stdout) o en un archivo de registro configurado.
* Registro Detallado: Puede aumentar la verbosidad del registro para obtener más información de diagnóstico.

{
    log {
        output file /var/log/caddy/caddy.log
        level DEBUG
    }
}

yourdomain.com {
    reverse_proxy localhost:8080
}

Consideraciones de Implementación

Docker

Al implementar Caddy en Docker, asegúrese de que el directorio de datos esté mapeado a un volumen persistente.

version: '3.8'
services:
  caddy:
    image: caddy:latest
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data # Almacenamiento persistente para certificados
      - caddy_config:/config
  myapp:
    image: myapp:latest
    restart: unless-stopped
    expose:
      - "8080" # Puerto interno, no expuesto externamente

volumes:
  caddy_data:
  caddy_config:

Servicio Systemd

Para implementaciones en hardware físico o máquinas virtuales, ejecutar Caddy como un servicio systemd es una práctica estándar. La documentación oficial de Caddy proporciona ejemplos de archivos caddy.service que configuran Caddy para ejecutarse como un usuario dedicado y gestionar su directorio de datos correctamente.

Uso de Recursos

Caddy es ligero. Las operaciones de gestión de certificados consumen recursos mínimos y típicamente ocurren en segundo plano. El consumo principal de recursos estará relacionado con el tráfico de proxy.

Mejores Prácticas de Seguridad

El HTTPS automático de Caddy maneja muchos aspectos de seguridad por defecto:
* Cifrados TLS Fuertes: Caddy utiliza suites de cifrado TLS modernas y seguras.
* HTTP Strict Transport Security (HSTS): Caddy puede añadir automáticamente el encabezado Strict-Transport-Security, instruyendo a los navegadores a conectarse siempre a través de HTTPS.
* OCSP Stapling: Reduce la latencia y mejora la privacidad.

Aunque Caddy maneja gran parte de la complejidad de TLS, las prácticas generales de seguridad siguen siendo relevantes:
* Mantener Caddy Actualizado: Actualice regularmente Caddy a la última versión para beneficiarse de parches de seguridad y nuevas características.
* Menor Privilegio: Ejecute Caddy con los permisos mínimos necesarios. Los archivos de servicio systemd oficiales configuran Caddy para ejecutarse como un usuario no root.
* Firewall: Restrinja el acceso a sus aplicaciones upstream (por ejemplo, localhost:8080) para que solo sean accesibles desde la instancia de Caddy.
* Control de Acceso: Implemente control de acceso o autenticación adicionales si es necesario para rutas o aplicaciones específicas detrás del proxy.