Si ponemos Caddy detrás de un proxy inverso o de un CDN como Cloudflare, no debe intentar emitir certificados públicos automáticamente.

En este escenario:

• El certificado público lo gestiona el proxy o el CDN.
• Caddy no está expuesto directamente a Internet.
• Los challenges ACME pueden fallar.
• No necesitamos Let's Encrypt en Caddy.

Por eso debemos añadir:

tls internal

Esto hace que Caddy:

• Use su propia CA interna.
• Genere certificados internos automáticamente.
• Permita cifrado TLS entre el proxy/CDN y Caddy.
• Evite problemas con validaciones externas.

Ejemplo completo de configuración

Configuración típica para un WordPress o sitio PHP detrás de proxy/CDN:

www.midominio.com, midominio.com {        
# Ruta del sitio web
        root * /var/www/midominio        
# TLS interno (IMPORTANTE si está detrás de proxy/CDN)
        tls internal        
# Servidor de archivos estáticos
        file_server        
# Compresión
        encode gzip        
# PHP-FPM
        php_fastcgi unix//run/php/php8.4-fpm.sock
}

¿Por qué es necesario?

Si no ponemos tls internal:

• Caddy intentará solicitar certificados públicos.
• Fallará si está detrás de Cloudflare en modo proxy.
• Puede generar errores 502 o fallos SSL.
• Complica el despliegue sin necesidad.

Si el proxy frontal ya hace la terminación TLS pública, Caddy solo necesita cifrado interno o, como mínimo, no debe gestionar certificados públicos.

Resumen rápido

Si Caddy está:

• Detrás de Nginx
• Detrás de HAProxy
• Detrás de Cloudflare
• Detrás de cualquier CDN

Añade siempre:

tls internal

Es simple, limpio y evita problemas de certificados en arquitecturas con proxy inverso.

Juan José Fernández Durán

Arquitecto IT & Consultor IT

See author's posts