Configuración de certificados SSL: renovación automática con Let's Encrypt y gestión multi-dominio

Un correo de alerta despertó a todo el equipo. El sitio no cargaba y las llamadas de queja inundaban atención al cliente. Abrimos el navegador: página roja de advertencia — «El certificado de seguridad de este sitio ha caducado». Mal asunto.

Nos conectamos al servidor y el certificado SSL había caducado anoche. La renovación manual nos tuvo hasta las cinco; dormimos dos horas y al día siguiente, a trabajar.

Después de eso pensamos: ¿se puede evitar por completo que caduquen los certificados? Con Let’s Encrypt descubrimos que la renovación automática gratuita ya está madura. Solo que muchos desarrolladores —nosotros incluidos— seguían en el modo manual.

Este artículo resuelve algo concreto: que los certificados SSL no caduquen nunca y que la gestión multi-dominio deje de ser un caos. Tanto para un blog personal como para servicios de empresa, al terminar podrás configurarlo directamente.

¿Qué es Let’s Encrypt? Entiende primero el principio

Mucha gente usa Let’s Encrypt sin entender cómo funciona. Conocer el principio te ayuda a localizar problemas rápido.

El papel de la autoridad de certificación (CA)

Let’s Encrypt es una autoridad de certificación, o CA. Su enfoque es claro: gratuito, automatizado y abierto. Desde su lanzamiento en 2016 impulsó HTTPS en pocos años —hoy más de 200 millones de certificados activos y confianza del 100 % en los navegadores globales.

Las CA tradicionales (DigiCert, GeoTrust, etc.) son caras, lentas y con revisión manual. Let’s Encrypt es distinto: todo automatizado —solicitas, valida y emite. Validez de 90 días; parece corto, pero con renovación automática es más seguro. ¿Por qué? Cuanto más corto el certificado, menor el riesgo de exposición.

Protocolo ACME: el núcleo de la automatización

Let’s Encrypt usa el protocolo ACME (Automated Certificate Management Environment), estándar RFC 8555. Define cómo validar automáticamente la propiedad del dominio y emitir certificados.

Hay tres formas de validación:

1. HTTP-01: la más usada. La CA visita una ruta concreta bajo tu dominio (/.well-known/acme-challenge/) y comprueba el token de validación. Demuestra que controlas el dominio.
2. DNS-01: obligatoria para wildcard. La CA comprueba un registro TXT en DNS con el token. No requiere servidor web, pero sí permisos de API DNS.
3. TLS-ALPN-01: menos común, para escenarios especiales.

HTTP-01 es la más simple si el puerto 80 es accesible. DNS-01 es flexible, ideal para servicios internos o wildcard.

Certbot: el cliente recomendado oficialmente

Certbot es la herramienta cliente recomendada por Let’s Encrypt. Cubre todo el flujo: solicitar certificado, configurar el servidor web y programar la renovación automática.

Capacidades principales de Certbot:

• Varias formas de validación
• Modifica automáticamente Nginx/Apache (mediante plugins)
• Configura systemd timer o cron job
• Comando de prueba de renovación (dry-run)

Con estos conceptos claros, cuando algo falle en la configuración sabrás dónde mirar.

Certificado SSL para un solo dominio: desde cero

Empecemos por lo más simple: un dominio, un servidor. Con el flujo básico dominado, el multi-dominio encaja solo.

Instalar Certbot

La instalación varía según el sistema. En Ubuntu/Debian lo más sencillo es Snap —también lo recomienda la documentación oficial, con versiones actualizadas.

Ubuntu/Debian (Snap):

# Instalar Snap (si aún no lo tienes)
sudo apt update
sudo apt install snapd

# Instalar Certbot
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

CentOS/RHEL:

sudo yum install certbot
# o
sudo dnf install certbot

Tras instalar, comprueba:

certbot --version
# Debería mostrar algo como: certbot 2.11.0

Obtener el certificado: tres métodos

Certbot ofrece tres formas de obtener el certificado, según tu caso.

Método 1: plugin Nginx con configuración automática (recomendado para principiantes)

Lo más cómodo. Certbot modifica Nginx, solicita el certificado, configura HTTPS y la redirección —todo en un comando:

sudo certbot --nginx -d example.com -d www.example.com

Te preguntará:

• Correo electrónico (avisos urgentes)
• Aceptar términos de servicio
• Compartir correo (elige No)
• Redirigir HTTP a HTTPS (elige Yes, más seguro)

Al terminar, Nginx ya está configurado. Verás las rutas del certificado:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/example.com/privkey.pem

Método 2: plugin Apache con configuración automática

Igual que Nginx, cambiando el plugin:

sudo certbot --apache -d example.com -d www.example.com

Método 3: solo obtener el certificado (configuración manual)

Si no quieres que Certbot toque la configuración, o usas otro servidor (Caddy, Node.js), usa el modo certonly:

sudo certbot certonly --webroot \
  -w /var/www/html \
  -d example.com \
  -d www.example.com

-w indica la raíz web; Certbot coloca ahí los archivos de validación. Luego configuras el servidor tú mismo.

Verificar que el certificado funciona

Tras solicitarlo, confirma que todo va bien.

Revisar archivos del certificado

sudo ls -la /etc/letsencrypt/live/example.com/

Deberías ver cuatro archivos:

• cert.pem: el certificado
• chain.pem: cadena intermedia
• fullchain.pem: cadena completa (Nginx usa este)
• privkey.pem: clave privada (Nginx usa esta)

Prueba en SSL Labs

Visita https://www.ssllabs.com/ssltest/ e introduce tu dominio. La prueba da una calificación (de A+ a F). El objetivo mínimo es A.

Problemas habituales:

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

• B o C: TLS antiguo o cipher suites débiles. Más adelante veremos cómo optimizar.
• F: cadena incompleta. Comprueba que Nginx use fullchain.pem, no cert.pem.

Navegador

Abre https://example.com; el candado debe aparecer en la barra. Al pulsarlo verás los detalles; el emisor será «Let’s Encrypt».

Renovación automática: olvídate del vencimiento

Los certificados de Let’s Encrypt duran 90 días. Parece poco, pero con renovación automática es una ventaja: rotación rápida, menor riesgo.

Mecanismo de renovación automática de Certbot

Al instalar Certbot configura la renovación. El método depende del sistema:

Systemd Timer (Linux moderno):

Certbot crea certbot.timer y certbot.service. El timer corre dos veces al día y comprueba si el certificado caduca en 30 días. Si es así, dispara el service para renovar.

Comprobar el timer:

sudo systemctl list-timers | grep certbot

Salida similar:

NEXT                         LEFT          LAST                         PASSED       UNIT           ACTIVATES
Thu 2026-04-02 12:00:00 UTC  1h left       Thu 2026-04-02 00:00:00 UTC  11h ago      certbot.timer  certbot.service

Verás la próxima y la última ejecución.

Cron Job (método tradicional):

Sin systemd (CentOS antiguo), Certbot usa cron. Comprueba:

sudo crontab -l
# o
cat /etc/cron.d/certbot

Configuración típica:

0 0,12 * * * root certbot renew --quiet

Comprobación de renovación a las 0:00 y 12:00.

Verificar que la renovación automática funciona

Ver el timer o cron no basta; hay que confirmar que la renovación se ejecuta.

Prueba dry run

Certbot simula la renovación sin aplicarla de verdad:

sudo certbot renew --dry-run

Salida similar:

Processing /etc/letsencrypt/renewal/example.com.conf
Cert not due for renewal, but simulating renewal for dry run
...
The dry run was successful.

Si ves «successful», la configuración es correcta.

Archivos de configuración de renovación

Cada certificado tiene su archivo:

cat /etc/letsencrypt/renewal/example.com.conf

Guarda los parámetros de la solicitud original y el método de validación. La renovación lee este archivo.

Recargar el servidor web tras renovar

Tras renovar, el servidor sigue con el certificado antiguo en memoria. Hay que recargar la configuración.

Deploy Hook (recomendado)

Ejecuta un comando solo si la renovación tiene éxito:

sudo certbot renew --deploy-hook "systemctl reload nginx"

O en el archivo de renovación:

# Editar /etc/letsencrypt/renewal/example.com.conf
# Añadir al final:
deploy_hook = systemctl reload nginx

Post Hook (siempre se ejecuta)

Se ejecuta tras cada intento, haya éxito o no:

sudo certbot renew --post-hook "systemctl reload nginx"

La diferencia: Deploy Hook solo con renovación exitosa; Post Hook siempre. Deploy Hook suele ser más adecuado.

¿Y si falla la renovación?

No es infalible. Causas y soluciones habituales:

Problemas de resolución DNS

Cambiaste el DNS pero la CA aún ve la IP antigua. Espera la propagación (TTL) o renueva a mano:

sudo certbot renew --force-renewal

Firewall o puertos

HTTP-01 requiere el puerto 80 accesible. Revisa el firewall:

sudo ufw status
sudo iptables -L -n

Abre el puerto 80 temporalmente:

sudo ufw allow 80/tcp

Permisos

Permisos incorrectos en los archivos. Comprueba:

sudo ls -la /etc/letsencrypt/live/
sudo ls -la /etc/letsencrypt/archive/

El usuario del servidor web (p. ej. www-data) debe poder leer los certificados.

Logs de renovación

Si falla, revisa el log:

sudo tail -f /var/log/letsencrypt/letsencrypt.log

Indica la causa. Resuelve según el mensaje.

Gestión multi-dominio: estrategias unificadas y dispersas

Con varios dominios, la estrategia de certificados importa. Sin plan, es un lío: fechas de renovación distintas, archivos dispersos y errores de configuración.

Un certificado, varios dominios (modo SAN)

Lo más recomendable: un certificado con varios dominios. Al solicitar con Certbot:

sudo certbot --nginx \
  -d example.com \
  -d www.example.com \
  -d api.example.com \
  -d admin.example.com

Ventajas:

• Renovación unificada: una vez, todos los dominios actualizados
• Archivos centralizados: un solo directorio de certificado
• Configuración simple: una sola ruta en el servidor web

Extensión SAN (Subject Alternative Names): campo del certificado con la lista de dominios. El navegador comprueba que el dominio visitado esté en SAN.

Ver dominios incluidos:

sudo certbot certificates

Salida similar:

Found the following certs:
  Certificate Name: example.com
    Domains: example.com www.example.com api.example.com admin.example.com
    Expiry Date: 2026-07-01 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem

Certificado wildcard

Cubre todos los subdominios de primer nivel con *.example.com: blog.example.com, api.example.com, admin.example.com, etc.

Obligatorio DNS-01: HTTP-01 no admite wildcard. Certbot necesita API DNS para añadir registros TXT.

Configurar plugin DNS

Cada proveedor tiene su plugin. Cloudflare es muy usado:

# Instalar plugin Cloudflare
sudo snap install certbot-dns-cloudflare

# Crear archivo de credenciales
sudo nano /root/.secrets/certbot/cloudflare.ini

Contenido:

dns_cloudflare_api_token = your_cloudflare_api_token

Genera el API Token en Cloudflare con permiso «DNS:Edit».

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Solicitar certificado wildcard

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
  -d "*.example.com" \
  -d example.com

Importante: solicita *.example.com y example.com juntos. El wildcard no cubre el dominio raíz.

Limitaciones del wildcard

Solo subdominios de primer nivel: *.example.com cubre sub.example.com, no sub.sub.example.com.

Para subdominios de segundo nivel, solicita aparte:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
  -d "*.example.com" \
  -d "*.api.example.com" \
  -d example.com

Así cubres api.example.com y v1.api.example.com.

Estrategia de varios certificados

¿Cuándo un certificado multi-dominio y cuándo varios?

Agrupar por servicio (recomendado)

Grupo web: sitio principal, blog, documentación

sudo certbot --nginx -d example.com -d www.example.com -d blog.example.com -d docs.example.com

Grupo API: endpoints y panel de administración

sudo certbot --nginx -d api.example.com -d admin.example.com -d v1.api.example.com

Grupo interno: monitorización, logs, herramientas

sudo certbot certonly --dns-cloudflare -d "*.internal.example.com"

Ventajas:

• Alcance controlado de la renovación: API no afecta al web
• Permisos aislados por grupo
• Aislamiento de fallos entre servicios

Agrupar por nivel de dominio

Wildcard más dominios concretos:

# Wildcard para todos los subdominios
sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

# Subdominio especial por separado (si necesita configuración distinta)
sudo certbot --nginx -d secure.example.com

Rutas de archivos de certificados

Entender la estructura evita confusiones con varios certificados.

Directorio activo: /etc/letsencrypt/live/[nombre-certificado]/

Enlaces simbólicos al certificado más reciente. Tras cada renovación apuntan a los archivos nuevos.

sudo ls -la /etc/letsencrypt/live/example.com/
lrwxrwxrwx 1 root root  42 Apr  2 12:00 cert.pem -> ../../archive/example.com/cert2.pem
lrwxrwxrwx 1 root root  43 Apr  2 12:00 chain.pem -> ../../archive/example.com/chain2.pem
lrwxrwxrwx 1 root root  44 Apr  2 12:00 fullchain.pem -> ../../archive/example.com/fullchain2.pem
lrwxrwxrwx 1 root root  40 Apr  2 12:00 privkey.pem -> ../../archive/example.com/privkey2.pem

Archivo histórico: /etc/letsencrypt/archive/[nombre-certificado]/

Guarda cada renovación. Nombres numerados: cert1.pem, cert2.pem, etc.

Configuración de renovación: /etc/letsencrypt/renewal/[nombre-certificado].conf

Parámetros de la solicitud original. La renovación lee este archivo.

# Ver configuración de renovación
cat /etc/letsencrypt/renewal/example.com.conf

Incluye:

• Método de validación (webroot, nginx, dns-cloudflare)
• Lista original de dominios
• Deploy Hook, etc.

Configuración avanzada: equilibrio entre seguridad y rendimiento

Con lo básico listo, puedes optimizar. El objetivo: seguridad y rendimiento a la vez.

HTTP/2 y OCSP Stapling

HTTP/2 mejora el rendimiento; OCSP Stapling reduce la latencia de verificación.

HTTP/2 en Nginx

server {
    listen 443 ssl http2;  # añadir http2
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ... resto de configuración
}

http2 va tras listen. Recarga Nginx:

sudo nginx -t
sudo systemctl reload nginx

Configuración OCSP Stapling

OCSP (Online Certificate Status Protocol) comprueba el estado del certificado. Stapling precarga el resultado en el servidor; el cliente no consulta la CA por separado.

server {
    # ... configuración SSL

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
}

En SSL Labs deberías ver «OCSP Stapling: Yes».

Endurecimiento: desactivar TLS antiguo

TLS 1.0 y 1.1 ya no son seguros. Los navegadores principales los abandonaron desde 2020.

server {
    # Solo TLS 1.2 y 1.3
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher suites recomendadas (seguridad y compatibilidad)
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    ssl_prefer_server_ciphers on;

    # Caché de sesión SSL (rendimiento)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
}

Tras esto, SSL Labs debería dar A o A+.

Cabecera HSTS

HSTS (HTTP Strict Transport Security) obliga al navegador a usar solo HTTPS. Tras configurarlo, aunque el usuario escriba http://, el navegador redirige a HTTPS.

server {
    # ... configuración SSL

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}

Parámetros:

• max-age=31536000: un año (en segundos)
• includeSubDomains: incluye todos los subdominios
• preload: permite lista de precarga del navegador

Atención: con HSTS activo, si necesitas HTTP temporal (pruebas), el navegador puede bloquear el acceso. Úsalo con cuidado.

Monitorización y alertas: detectar problemas antes

La renovación automática no lo cubre todo. Si falla, conviene saberlo con tiempo. Alerta una semana antes del vencimiento y aún puedes actuar.

Script de monitorización simple

Comprueba los días restantes del certificado:

#!/bin/bash
# /usr/local/bin/check-ssl-expiry.sh

DOMAIN="example.com"
EXPIRY_DAYS=$(openssl s_client -connect $DOMAIN:443 -servername $DOMAIN 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)

EXPIRY_DATE=$(date -d "$EXPIRY_DAYS" +%s)
CURRENT_DATE=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_DATE - $CURRENT_DATE) / 86400 ))

if [ $DAYS_LEFT -lt 7 ]; then
    echo "WARNING: SSL certificate for $DOMAIN expires in $DAYS_LEFT days"
    # Enviar alerta por correo (requiere servicio de correo configurado)
    mail -s "SSL Certificate Expiry Warning" [email protected] <<< "SSL certificate for $DOMAIN expires in $DAYS_LEFT days"
fi

Añade a cron para comprobar cada día:

0 6 * * * /usr/local/bin/check-ssl-expiry.sh

Notificaciones automáticas de Certbot

Si falla la renovación, Certbot envía correo a la dirección usada al solicitar el certificado. Asegúrate de que sea correcta y recibas los mensajes.

Problemas habituales y soluciones

Durante la configuración pueden surgir varios obstáculos. Aquí los más frecuentes.

Fallo al solicitar el certificado

Causa 1: DNS del dominio no apunta al servidor

La CA debe validar la propiedad. HTTP-01 requiere acceder al dominio. Sin DNS resuelto, falla.

Comprobar DNS:

dig example.com +short
# o
nslookup example.com

Confirma que la IP es la de tu servidor.

Solución: espera la propagación DNS (TTL, de minutos a horas) y reintenta.

Causa 2: puerto 80 ocupado o bloqueado por firewall

HTTP-01 usa el puerto 80. Si otro proceso lo ocupa o el firewall bloquea, falla.

Comprobar ocupación del puerto:

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

sudo netstat -tulpn | grep :80
sudo lsof -i :80

Si no es Nginx/Apache, detén el proceso:

sudo systemctl stop servicio-que-ocupa-el-puerto

Comprobar firewall:

sudo ufw status
# o
sudo iptables -L -n

Abre los puertos:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Causa 3: permisos del directorio webroot

Con certonly --webroot, Certbot crea archivos de validación en la raíz web. Sin permisos de escritura, falla.

Comprobar permisos:

ls -la /var/www/html/.well-known/

El usuario de Certbot (normalmente root) debe poder escribir.

Crear directorio manualmente:

sudo mkdir -p /var/www/html/.well-known/acme-challenge
sudo chown -R www-data:www-data /var/www/html/.well-known

Tratamiento de fallos de renovación

La renovación automática a veces falla. Revisa logs y actúa según la causa.

Logs de Certbot

sudo tail -100 /var/log/letsencrypt/letsencrypt.log

Errores habituales:

• Connection refused: problema de puerto
• DNS problem: NXDOMAIN: problema de resolución DNS
• Rate limit exceeded: límite de solicitudes superado

Renovación manual forzada

sudo certbot renew --force-renewal

--force-renewal renueva aunque no esté por caducar.

Comprobar configuración de renovación

Un archivo corrupto también provoca fallos:

cat /etc/letsencrypt/renewal/example.com.conf

Si está dañado, elimina y vuelve a solicitar:

sudo certbot delete --cert-name example.com
sudo certbot --nginx -d example.com -d www.example.com

Conflictos entre varios certificados

Con varios certificados, el servidor web puede referenciar el incorrecto.

Ruta incorrecta en Nginx

sudo nginx -T | grep ssl_certificate

Cada bloque server debe usar la ruta correcta.

Errores habituales:

• Usar cert.pem en lugar de fullchain.pem (cadena incompleta)
• Directorio de certificado equivocado (nombre distinto del dominio)

Nombre del certificado y dominio no coinciden

Certbot usa el primer dominio como nombre. Por ejemplo:

sudo certbot --nginx -d api.example.com -d example.com

El certificado se llama api.example.com; la ruta es /etc/letsencrypt/live/api.example.com/.

Si Nginx apunta a /etc/letsencrypt/live/example.com/, no encontrará el certificado.

Ver nombre del certificado:

sudo certbot certificates

Confirma que nombre y ruta coinciden.

Limitaciones del certificado wildcard

El wildcard es práctico, pero tiene límites.

Solo subdominios de primer nivel

*.example.com cubre sub.example.com, no sub.sub.example.com.

Para subdominios de segundo nivel, certificado adicional:

# Wildcard (primer nivel)
sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

# Subdominios de segundo nivel
sudo certbot certonly --dns-cloudflare -d "*.api.example.com"

No cubre el dominio raíz

*.example.com no cubre example.com. Hay que añadir -d example.com.

Ejemplo incorrecto:

# Error: el dominio raíz no funciona
sudo certbot certonly --dns-cloudflare -d "*.example.com"

Ejemplo correcto:

# Correcto: incluir también el dominio raíz
sudo certbot certonly --dns-cloudflare -d "*.example.com" -d example.com

Resumen: de lo manual a lo automático

Gestionar certificados SSL es pasar de procesos manuales a automatización. El flujo manual de las CA tradicionales, con Let’s Encrypt, se vuelve simple y fiable.

Puntos clave:

1. Entender el principio: ACME define validación y emisión automáticas. HTTP-01 y DNS-01 cubren distintos escenarios.
2. Renovación automática: Certbot configura systemd timer o cron. Renueva 30 días antes del vencimiento, con dos comprobaciones diarias.
3. Multi-dominio: modo SAN (un certificado, varios dominios) para gestión unificada; wildcard para muchos subdominios. Agrupar por servicio es la estrategia recomendada.
4. Optimización de seguridad: HTTP/2, OCSP Stapling, desactivar TLS antiguo y HSTS pueden llevar SSL Labs a A+.
5. Monitorización: la renovación automática no basta; vigila los días restantes y detecta problemas a tiempo.

Próximos pasos:

Si gestionas muchos servidores o dominios, considera:

• Plataformas de automatización: Cert Manager (Kubernetes), Traefik (SSL automático)
• Servicios de monitorización: SSL Monitor, Uptime Robot
• Integración CI/CD: comprobar estado del certificado en cada despliegue

Una vez automatizado, los certificados dejan de preocuparte. El sitio es más seguro, los usuarios confían más y los buscadores lo valoran. Las alertas a las tres de la madrugada quedan en el pasado.