Let's Encrypt es una autoridad de certificación gratuita y automatizada; Certbot es el cliente oficial de la Electronic Frontier Foundation (EFF) para pedir, instalar y renovar sus certificados. Esta guía no repite cómo poner HTTPS en Nginx: para eso ya están Nginx como reverse proxy con HTTPS y SSL/TLS y certificados: cómo funciona HTTPS. Acá vas a encontrar lo que esas guías no cubren: los plugins de Apache, standalone y webroot; los desafíos del protocolo ACME (Automatic Certificate Management Environment) —HTTP-01 y DNS-01— y por qué solo uno sirve para comodines; los límites de emisión; y cómo funciona de verdad la renovación automática, y por qué puede fallar en silencio si nadie la monitorea.
Ver índice de contenidos
Qué es Certbot y qué cubre esta guía
Certbot es el cliente ACME (el protocolo que automatiza la emisión de certificados TLS) que mantiene la Electronic Frontier Foundation (EFF). Detecta el servidor web instalado, resuelve el desafío que exige la autoridad certificadora, obtiene el certificado y —si el plugin lo permite— edita la configuración para servirlo, todo con un solo comando.
El portal ya tiene tres guías con Certbot y Nginx paso a paso: Nginx como reverse proxy con HTTPS muestra el flujo completo certbot --nginx, Configurar un servidor web en Linux lo integra en la puesta a punto de un servidor, y SSL/TLS y certificados: cómo funciona HTTPS explica el protocolo ACME y la vigencia de 90 días. Si buscás eso, son la referencia.
Esta guía es distinta: es la referencia de Certbot como herramienta. Cubre los plugins que no son Nginx, los dos desafíos ACME, los límites de emisión que ninguna otra guía del portal menciona, y el mecanismo real de la renovación automática, la parte que más falla en producción.
Certbot más allá de Nginx: Apache, standalone y webroot
Certbot resuelve dos tareas con plugins separables: un autenticador, que responde al desafío de validación, y un instalador, que edita la configuración del servidor para que sirva el certificado. El plugin de Nginx hace ambas cosas en un solo paso; para otros escenarios hacen falta otros plugins.
| Plugin | Comando | Cuándo conviene |
|---|---|---|
| Apache | sudo certbot --apache -d dominio.com | Servidores con Apache HTTP Server |
| Standalone | sudo certbot certonly --standalone -d dominio.com | Sin servidor web corriendo, o se puede detener un momento |
| Webroot | sudo certbot certonly --webroot -w /var/www/html -d dominio.com | Servidor activo, sin reiniciarlo ni plugin propio |
# Apache: obtiene y configura automáticamente
sudo certbot --apache -d dominio.com
# Standalone: servidor temporal en el puerto 80
sudo certbot certonly --standalone -d dominio.com
# Webroot: usa un servidor que ya está corriendo
sudo certbot certonly --webroot -w /var/www/html -d dominio.comcertonly (usado en standalone y webroot) solo obtiene y guarda el certificado: no edita ninguna configuración de servidor, porque no tiene plugin instalador. Con standalone y webroot hay que apuntar manualmente el servidor web a los archivos resultantes, en /etc/letsencrypt/live/dominio.com/.
Levanta su propio servidor temporal para resolver el desafío HTTP-01 y necesita el puerto 80 libre mientras lo hace. Si ya hay un Nginx o un Apache escuchando ahí, hay que detenerlo un instante, o usar webroot en su lugar, que no compite por el puerto.
Los desafíos ACME: HTTP-01 y DNS-01
Todo certificado de Let's Encrypt exige antes un desafío: una prueba de que quien lo pide controla el dominio. Certbot resuelve dos tipos.
El desafío HTTP-01 publica un archivo en una ruta fija dentro de tu propio dominio, algo como http://dominio.com/.well-known/acme-challenge/<token>. La autoridad se conecta por el puerto 80 y, si encuentra el archivo esperado, da el control por probado. Es el más simple, y el que usan por defecto los plugins de Nginx y Apache. Su límite: no sirve para certificados comodín (wildcard), porque no existe una sola ruta HTTP que cubra a la vez todos los subdominios de *.dominio.com.
El desafío DNS-01 pide crear un registro TXT en _acme-challenge.dominio.com. La autoridad lo verifica consultando el DNS, sin conectarse al servidor. Es el único que permite certificados comodín, porque el registro TXT cubre el dominio completo de una vez, y la única opción cuando el servidor no tiene el puerto 80 expuesto a internet, algo habitual en servicios internos.
Límites de emisión
Let's Encrypt aplica límites de emisión (rate limits), que casi nunca afectan a un sitio en producción pero sí a quien prueba una configuración repetidamente. Ninguna otra guía del portal los menciona. Según la documentación oficial, consultada el 29 de julio de 2026:
| Límite | Valor |
|---|---|
| Certificados por dominio registrado | 50 cada 7 días |
| Certificados duplicados (mismo conjunto de nombres) | 5 cada 7 días |
| Fallos de validación | 5 por identificador y por hora |
| Cuentas nuevas por dirección IP | 10 cada 3 horas |
| Órdenes nuevas por cuenta | 300 cada 3 horas |
El que más sorprende en la práctica es el de fallos de validación por hora: repetir el mismo pedido mientras depurás una configuración puede dejarte bloqueado un rato. Para eso existe un entorno de staging, con límites mucho más altos y certificados que los navegadores no reconocen, pensado para probar la configuración antes de pedir el certificado real. Estas cifras pueden cambiar; la página oficial de límites es la referencia siempre actualizada.
Cómo funciona la renovación automática
Este es el punto que más importa de toda la guía, porque es el que falla en producción sin que nadie lo note.
Al instalar Certbot con el gestor de paquetes del sistema, el propio paquete deja programada la renovación, sin configurar nada a mano. En sistemas con systemd suele ser un timer (certbot.timer, o snap.certbot.renew.timer si se instaló como snap); en sistemas más viejos, una entrada en /etc/cron.d/certbot. Ambos ejecutan, normalmente dos veces al día, el comando certbot renew, que reutiliza el mismo plugin y las mismas opciones con que se emitió cada certificado, y solo renueva los que tienen menos de un tercio de su vigencia restante —unos 30 días en uno de 90—. Los demás quedan intactos hasta que les toque.
# Ver si el timer de systemd existe y cuándo corre de nuevo
systemctl list-timers | grep certbot
# En un sistema con cron en lugar de systemd
cat /etc/cron.d/certbotUn cambio de firewall que cierra de nuevo el puerto 80, un registro DNS mal actualizado, un disco lleno, un paquete retenido: cualquiera de estos rompe la renovación sin aviso visible, hasta el día en que el certificado vence. En enero de 2022, Let's Encrypt tuvo que revocar una gran cantidad de certificados en apenas dos días por un error de validación TLS-ALPN-01, según cubrió el blog de Underc0de: un recordatorio de que conviene monitorear el vencimiento desde afuera, sin depender del mismo servidor que puede estar fallando. También sirve revisar después la configuración TLS con una herramienta externa, como testssl.sh, comentada en el foro de Underc0de.
Subcomandos de referencia
Más allá de certonly y de los plugins --nginx o --apache ya mencionados, estos subcomandos cubren casi todo el mantenimiento del día a día.
# Renueva los certificados que están por vencer
sudo certbot renew
# Simula la renovación sin gastar cupo de los límites
sudo certbot renew --dry-run
# Lista certificados, archivos y fecha de vencimiento
sudo certbot certificates
# Revoca un certificado (si se filtró la clave, por ejemplo)
sudo certbot revoke --cert-name dominio.com
# Borra un certificado del sistema
sudo certbot delete --cert-name dominio.comrenew es lo que ejecuta el timer o el cron automáticamente. --dry-run es la forma recomendada de comprobar que la renovación va a funcionar, sin gastar cupo de los límites ni tocar el certificado real. revoke y delete son distintos: revocar invalida el certificado ante los navegadores antes de que expire por su cuenta; borrar solo lo quita del sistema local.
Errores frecuentes
- Pensar que Certbot solo funciona con Nginx. Tiene plugin propio para Apache y modos que no dependen de ningún servidor web.
- Ejecutar
certbot --nginxesperando un comodín. Falla: los comodines exigen el desafío DNS-01 y un plugin de DNS. - Confiar en que «algo» renueva solo sin comprobarlo. Verificar el timer o el cron con
systemctl list-timers. - No monitorear el vencimiento desde afuera. La renovación automática puede fallar en silencio durante meses.
- Repetir pedidos fallidos sin usar el entorno de staging. Se agota el límite de fallos de validación por hora y queda bloqueado el dominio.
- Usar standalone con otro servicio ya escuchando en el puerto 80. El desafío HTTP-01 no puede resolverse si el puerto está ocupado.
Preguntas frecuentes
¿Certbot solo sirve para Nginx?
No. Certbot es un cliente ACME de propósito general con distintos plugins: uno para Nginx, uno para Apache HTTP Server, un modo standalone que levanta su propio servidor temporal para resolver el desafío sin depender de ningún servidor web instalado, y un modo webroot que escribe el archivo de validación dentro de un servidor que ya está corriendo, sin reiniciarlo. El plugin de Nginx es el más citado porque es el escenario más común al publicar con reverse proxy, pero no es una limitación de Certbot: la misma herramienta emite y renueva certificados para Apache, para servicios sin servidor web propio, y para dominios que no exponen el puerto 80, con el desafío por DNS.
¿Qué diferencia hay entre el desafío HTTP-01 y el DNS-01?
Ambos demuestran que controlás el dominio, pero de formas distintas. HTTP-01 le pide a tu servidor que publique un archivo en una ruta fija de tu propio dominio (http://tudominio.com/.well-known/acme-challenge/token); la autoridad se conecta por el puerto 80 y, si lo encuentra, da el control por probado. DNS-01 pide crear un registro TXT en _acme-challenge.tudominio.com, y la autoridad lo verifica consultando el DNS en vez de conectarse al servidor. La diferencia clave: HTTP-01 no sirve para certificados comodín (*.tudominio.com), porque no hay un archivo válido para todos los subdominios a la vez; DNS-01 sí, porque el registro TXT cubre el dominio completo, y es la única opción cuando el servidor no tiene el puerto 80 accesible desde internet.
¿Cómo emito un certificado comodín?
Un certificado comodín (wildcard) cubre un dominio y todos sus subdominios con un solo certificado, por ejemplo *.tudominio.com además de tudominio.com. Certbot obliga a usar el desafío DNS-01, el único que prueba el control sobre un conjunto de subdominios en vez de uno solo. En la práctica hace falta un plugin de DNS del proveedor donde esté alojado el dominio, para que Certbot cree automáticamente el registro TXT necesario, o resolverlo a mano si no existe ese plugin. Sin un plugin de DNS automatizado, la renovación de un comodín deja de ser desatendida: alguien tiene que recrear el registro TXT cada vez que el certificado esté por vencer.
¿Dónde queda configurada la renovación automática y cómo la compruebo?
Al instalar Certbot con el gestor de paquetes, el propio paquete deja programada la renovación sin configurar nada a mano: en sistemas con systemd suele ser un timer (certbot.timer), y en sistemas más viejos, una entrada en /etc/cron.d/certbot. Ambos ejecutan, dos veces al día, el comando certbot renew, que revisa todos los certificados y solo renueva los que tienen menos de un tercio de su vigencia restante, unos 30 días en uno de 90. Para comprobarlo, systemctl list-timers muestra la próxima ejecución; con cron alcanza con mirar /etc/cron.d/certbot. Esto es justo lo que hay que revisar cuando un certificado vence sin aviso: casi siempre el problema no es Let's Encrypt, sino que esa tarea dejó de correr, y puede hacerlo en silencio durante meses si nadie la controla.
¿Cuántos certificados puedo pedir sin toparme con los límites?
Let's Encrypt aplica límites de emisión pensados para uso normal, que rara vez afectan a producción pero sí a quien prueba configuraciones repetidamente. Según la documentación oficial vigente al 29 de julio de 2026: 50 certificados por dominio registrado cada 7 días, 5 duplicados con el mismo conjunto de nombres cada 7 días, 5 fallos de validación por identificador y hora, 10 cuentas nuevas por IP cada 3 horas, y 300 órdenes nuevas por cuenta cada 3 horas. El que más sorprende es el de fallos de validación por hora: repetir el mismo pedido mientras se depura una configuración puede bloquearte un rato. Para eso existe un entorno de staging, con límites más altos y certificados que los navegadores no reconocen.
¿Qué hago si mi servidor no tiene el puerto 80 expuesto?
Si tu servidor no expone el puerto 80, ni HTTP-01 ni el modo standalone van a funcionar, porque ambos necesitan que la autoridad se conecte por ese puerto para verificar el archivo de validación. La alternativa es DNS-01, que no necesita ningún puerto abierto: la validación se hace consultando un registro TXT en el DNS, independientemente de si el servidor es accesible desde internet. Es la opción indicada para servidores internos o detrás de un firewall estricto. Hace falta un plugin de DNS del proveedor donde esté alojado el dominio para crear y borrar el registro TXT en cada renovación; sin ese plugin, se resuelve a mano, pero la renovación deja de ser automática.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 29 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, blog. Let's Encrypt está revocando muchos certificados SSL en dos días, por Dragora, 26 de enero de 2022. Base del argumento sobre monitorear la renovación desde afuera.
- Underc0de, foro. Test SSL, sección Hacking Tools. Sobre testssl.sh, para verificar la configuración TLS tras emitir el certificado.
- Underc0de, foro. Los certificados SSL y la confianza, por AXCESS, 25 de septiembre de 2019. Antecedente de la comunidad; afirma que el navegador muestra un candado verde con el nombre de la empresa en los certificados EV, distinción que los navegadores eliminaron después y que ya no es vigente.
Documentación oficial
- EFF. Certbot: Using / Renewing certificates. Plugins, subcomandos y el mecanismo de renovación citados en esta guía.
- EFF. Certbot instructions. Selector oficial de instrucciones por sistema operativo y servidor web.
- Let's Encrypt. How It Works. Descripción general del protocolo ACME.
- Let's Encrypt. Challenge Types. Definición oficial de HTTP-01 y DNS-01 usada en esta guía.
- Let's Encrypt. Rate Limits. Los límites de emisión citados, vigentes a la fecha de consulta.