Emitir un certificado SSL suele ser sencillo. El verdadero problema aparece semanas después, cuando toca renovarlo y el sistema falla sin avisar claramente.

Herramientas como Caddy, Nginx o Apache HTTP Server dependen del mismo mecanismo: ACME con Let's Encrypt.

Y si hay un proxy como Cloudflare, los fallos de renovación siguen exactamente las mismas reglas que la emisión inicial.

Cómo funciona realmente la renovación

Un punto clave que muchos pasan por alto:

La renovación no reutiliza el certificado anterior, sino que repite el proceso completo de validación.

Es decir:

  • Se vuelve a ejecutar HTTP-01 o DNS-01
  • Se vuelve a comprobar el dominio desde cero

Por tanto, cualquier cambio en DNS, proxy o red puede romper la renovación aunque todo funcionara antes.

Síntomas típicos de fallo

En producción, los errores suelen manifestarse así:

  • Certificado caducado inesperadamente
  • Errores TLS intermitentes
  • Logs con mensajes tipo:
    • “challenge failed”
    • “no valid IP addresses”
    • “connection refused”
    • “NXDOMAIN” o errores DNS

Diagnóstico paso a paso

1. Comprobar resolución DNS

 
dig tudominio.com
 

Verifica que apunta al servidor correcto.

Si hay CNAME (por ejemplo a otro dominio), asegúrate de seguir la cadena completa.

2. Detectar si hay proxy de Cloudflare

 
curl -I https://tudominio.com
 

Si aparecen cabeceras como:

 
cf-ray
server: cloudflare
 

Entonces el tráfico está pasando por Cloudflare.

3. Verificar acceso directo al servidor

Para HTTP-01:

 
curl http://tudominio.com/.well-known/acme-challenge/test
 

Si no llega al servidor o devuelve contenido inesperado, HTTP-01 fallará.

4. Revisar logs del servidor

En Caddy:

 
journalctl -u caddy -f
 

Buscar errores relacionados con ACME o challenges.

En Nginx/Apache con Certbot, revisar logs de Certbot.

Problemas reales y su causa

Caso 1: Funcionaba y dejó de funcionar

Causa frecuente:

  • Se activó Cloudflare proxy después de emitir el certificado

Resultado:

  • HTTP-01 deja de funcionar en la renovación

Caso 2: Dominio de cliente con Cloudflare propio

  • Proxy activo
  • Sin acceso a su DNS

Resultado:

  • HTTP-01 falla
  • DNS-01 imposible

Caso 3: Cambio de DNS provider

  • Antes estaba en Cloudflare
  • Ahora en otro proveedor

Resultado:

  • DNS-01 deja de funcionar si no se actualiza la configuración

Estrategias de mitigación

Usar múltiples métodos de challenge

En sistemas avanzados:

  • Intentar HTTP-01 primero
  • Usar DNS-01 como fallback

Esto cubre la mayoría de escenarios, pero no todos.

Monitorizar expiración de certificados

No confiar únicamente en la renovación automática.

Comprobar manualmente:

 
openssl s_client -connect tudominio.com:443 -servername tudominio.com | openssl x509 -noout -dates
 

Detectar Cloudflare automáticamente

A nivel de arquitectura, se puede:

  • Detectar cabeceras cf-ray
  • Inferir si hay proxy activo
  • Ajustar estrategia de challenge

Diferencias entre Caddy, Nginx y Apache

Aunque el problema es el mismo, hay diferencias operativas:

Caddy

  • Automatiza completamente ACME
  • Maneja múltiples issuers y fallback
  • Ideal para entornos dinámicos

Nginx

  • Necesita herramientas externas como Certbot
  • Más control manual
  • Más propenso a errores de configuración

Apache

  • Similar a Nginx
  • Integración clásica con Certbot
  • Menos flexible en automatización avanzada

Buenas prácticas en entornos reales

  • Mantener control sobre el DNS siempre que sea posible
  • Evitar depender de cuentas externas sin acceso
  • Documentar qué dominios usan proxy
  • Diseñar políticas de fallback (HTTP-01 + DNS-01)
  • Monitorizar certificados activamente

Conclusión

Los fallos de renovación no son aleatorios. Siempre responden a una de estas causas:

  • El tráfico no llega al servidor (HTTP-01 roto)
  • No hay acceso al DNS (DNS-01 imposible)
  • El entorno ha cambiado desde la emisión inicial

 

La clave está en entender que ACME valida el dominio cada vez desde cero, y cualquier cambio en la infraestructura afecta directamente al resultado.