Comparativa: Certbot vs acme.sh para la automatización de Let's Encrypt en entornos Docker con múltiples dominios — pros y contras

Por Kevin Marcondes · Publicado el 28/10/2026 · 8 min de lectura

Comparativa: Certbot vs acme.sh para automatizar Let's Encrypt en entornos Docker con múltiples dominios. Esta guía explica cuándo conviene cada cliente ACME, cómo integrarlo detrás de un proxy inverso y cómo organizar volúmenes, hooks y renovaciones en Compose. Incluye arquitecturas típicas y ejemplos prácticos para tu decisión técnica.

Escenario: múltiples contenedores y dominios en Docker

Los entornos con varios servicios y dominios requieren renovación automática, zero downtime y almacenamiento consistente de los certificados. El cliente ACME debe funcionar detrás de proxies, soportar SAN (múltiples -d) y, con frecuencia, wildcard vía DNS-01. Puedes centralizar la emisión en un contenedor y compartir certificados por volumen, o emitir por servicio según la topología.

Si estás empezando con certificados, consulta conceptos generales en Cómo generar SSL gratis con Let's Encrypt.

• Objetivos típicos: *.dominio.com y dominios adicionales en SAN.
• Renovación automática sin interrumpir Nginx/HAProxy/Traefik.
• Almacenamiento seguro de las claves privadas y backup de la account key.
• Compatibilidad con HTTP-01 detrás de proxy y DNS-01 con el proveedor.

Arquitecturas de automatización en Docker

Hay dos patrones comunes para integrar Certbot o acme.sh en Docker. La elección condiciona cómo montas volúmenes, actualizas certificados y recargas procesos. Define un único “punto de emisión” y un plan de reload controlado para evitar ventanas sin TLS.

• Emisor centralizado: un contenedor gestiona todos los dominios, guarda en un volumen dedicado y el resto de servicios monta los certificados en modo solo lectura.
• Por servicio: cada app contiene el cliente ACME y emite sus propios certificados; útil para equipos independientes, pero con más credenciales y puntos de fallo.
• En HTTP-01, usa webroot compartido con el proxy. En DNS-01, inyecta tokens del proveedor DNS en el emisor.

Recursos lado a lado: qué cambia en la práctica

A continuación, una visión comparativa de los criterios que más pesan en entornos Docker con muchos dominios y necesidad de automatización continua.

Automatización de múltiples dominios y wildcard

Para reducir el número de certificados, combina dominios con SAN. Esto simplifica la gestión, pero un error afecta a más hosts. Prefiere wildcard (*.dominio.com) cuando los subdominios cambian con frecuencia y controlas el DNS-01. En Docker, mantiene un volumen exclusivo para certificados y permisos restrictivos.

Certbot y acme.sh manejan bien SAN y wildcard. acme.sh suele ser directo al configurar DNS-01 con tokens de proveedores. Certbot destaca cuando reutilizas webroot y ya tienes automatizaciones de reload en marcha.

• Consolida SAN cuando la cadencia de cambios sea similar entre dominios.
• Wildcard reduce reemisiones al añadir subdominios nuevos.
• Separa certificados por dominio crítico para aislar fallos.
• Centraliza el almacenamiento y versionado de configuraciones.

HTTP-01 vs DNS-01 detrás de proxy inverso

En HTTP-01, el tráfico a /.well-known/acme-challenge debe llegar al emisor o a un webroot compartido. Esto exige configuración en el proxy inverso. En DNS-01, el desafío se valida por registros TXT, ideal para wildcard y clusters sin puerto 80 expuesto.

Si usas proxies modernos con ACME incorporado, compara las aproximaciones en Comparativa: Traefik vs Caddy. Para un ejemplo con balanceador tradicional, consulta el Tutorial: HAProxy con Let's Encrypt. Y, para elegir proxy, revisa Traefik vs Nginx como proxy inverso.

• HTTP-01: simple con webroot, depende de un enrutamiento correcto en el proxy.
• DNS-01: ideal para wildcard y multi-host, requiere tokens de API del proveedor DNS.
• En ambos casos, planifica el reload sin interrupciones del servicio.

Operación continua, seguridad y rendimiento

Minimiza el alcance de credenciales y monta certificados en modo solo lectura. Prefiere ECDSA P-256 por claves más pequeñas y handshakes más rápidos, cuando los clientes lo soporten. Diseña la recarga del proxy (SIGHUP o endpoint de reload) para evitar reinicios completos.

Usa el modo staging al validar automatizaciones para no alcanzar los rate limits. Haz backup de la account key y de los directorios de certificados. Nunca expongas tokens DNS en repositorios; emplea secrets y controles de acceso por entorno.

Criterios rápidos de elección en Docker:

- Prefiere Certbot cuando dependes de webroot/HTTP-01, ya tienes automatizaciones con hooks de Certbot, o quieres alinearte con el cliente oficial.

- Prefiere acme.sh cuando necesitas DNS-01/wildcard en muchos proveedores, imágenes ligeras y scripts shell sencillos para integrar en CI/CD.

Ejemplo Compose: Certbot con webroot compartido (HTTP-01)

Estructura mínima usando webroot compartido con Nginx. Certbot escribe el desafío en el volumen y Nginx lo sirve en /.well-known/acme-challenge. Tras emitir, los certificados quedan en un volumen dedicado. Revisa permisos y planifica el reload de Nginx.

version: '3.8'
services:
  nginx:
    image: nginx:alpine
    volumes:
      - challenge:/var/www/certbot:ro
      - certs:/etc/letsencrypt:ro
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    ports:
      - "80:80"
      - "443:443"

  certbot:
    image: certbot/certbot
    volumes:
      - challenge:/var/www/certbot
      - certs:/etc/letsencrypt
    entrypoint: ["sh","-c"]
    command: >-
      "certbot certonly --webroot -w /var/www/certbot \
      -d example.com -d www.example.com \
      --email [email protected] --agree-tos --no-eff-email --non-interactive && \
      echo 'Emissão concluída. Configure um mecanismo de reload do Nginx.'"

volumes:
  challenge:
  certs:

Ejemplo Compose: acme.sh con DNS-01 y varios dominios

Flujo típico para wildcard vía DNS-01. acme.sh escribe certificados en un volumen dedicado. Los servicios consumidores montan ese volumen como solo lectura. Almacena tokens DNS en Docker secrets o en variables protegidas y activa staging antes de pasar a producción.

version: '3.8'
services:
  acme:
    image: your-acme-sh-image
    environment:
      - ACME_SERVER=letsencrypt
      # Exemplo Cloudflare (use secrets na prática):
      - CF_Token=${CF_TOKEN}
      - CF_Zone_ID=${CF_ZONE_ID}
    volumes:
      - certs:/acme
    entrypoint: ["sh","-c"]
    command: >-
      "acme.sh --issue --dns dns_cf \
      -d example.com -d *.example.com \
      --keylength ec-256 --server letsencrypt && \
      acme.sh --install-cert -d example.com \
      --fullchain-file /acme/example.com/fullchain.pem \
      --key-file /acme/example.com/privkey.pem && \
      echo 'Certificados prontos no volume. Programe renovações.'"

volumes:
  certs:

Preguntas frecuentes

¿Cuál es mejor para múltiples dominios y wildcard en Docker?

Ambos funcionan bien. Para DNS-01 y wildcard, acme.sh suele ser más directo por su integración con diversos proveedores vía variables de entorno. Para HTTP-01 con webroot ya establecido en el proxy, Certbot es una elección sólida y bien documentada.

¿Puedo usarlo con Traefik, Nginx o HAProxy detrás de Docker?

Sí. En HTTP-01, dirige /.well-known/acme-challenge al webroot compartido o al emisor. En DNS-01 no hay tráfico HTTP; solo necesitas acceso a la API del DNS. Programa una recarga limpia del proxy tras la renovación.

¿Cómo evitar alcanzar los rate limits de Let's Encrypt durante pruebas?

Usa el modo staging en ambos clientes. Permite validar el flujo de emisión y renovación sin consumir límites de producción. Cuando termines las pruebas, cambia al servidor de producción y conserva márgenes de renovación.

¿Dónde almacenar certificados y cómo recargar sin downtime?

Almacena en un volumen dedicado, montado como solo lectura para los servicios que consumen el certificado. Realiza reload por señal o endpoint del proxy (ej.: SIGHUP en Nginx) tras la renovación. Evita reiniciar contenedores innecesariamente.

¿Es seguro guardar tokens del proveedor DNS en variables de entorno?

Es común, pero exige precauciones. Prefiere Docker secrets o gestores de secretos del orquestador. Restringe el alcance y permisos en el proveedor DNS, rota las credenciales periódicamente y nunca comitees secretos en el repositorio.

Ver también

• Comparativo: ZFS vs LVM+LUKS en VPS con bases de datos — snapshots, rendimiento y recuperación tras fallos
• Análisis práctico — comparativa: Nginx Unit vs PHP‑FPM vs RoadRunner para ejecutar monolitos PHP en contenedores — latencia, throughput y consumo de memoria
• Comparativa: Flyway vs Liquibase vs Sqitch para versionado de base de datos en proyectos PHP/Laravel
• Comparativa: ZFS vs Btrfs para snapshots, replicación y retención incremental en VPS con contenedores Docker — pros y contras prácticos