Antes, HTTPS implicaba certificados caros y engorrosos. Let's Encrypt cambió eso: es gratuito, y todo el proceso —desde la emisión hasta la renovación— puede automatizarse por completo. Así funciona, desde el punto de vista de quien defiende.
Cómo funciona: probar el control del dominio, automáticamente (ACME)
Los certificados tradicionales implicaban solicitar, presentar papeleo de identidad y esperar, todo a mano. Let's Encrypt sustituye eso por ACME (Automatic Certificate Management Environment), un protocolo que convierte todo el intercambio en pasos de máquina a máquina.
El punto clave: solo verifica el control del dominio (validación de dominio, DV). No comprueba la existencia legal de una empresa, por eso el proceso es lo bastante ligero para automatizarse por completo. El cifrado en sí no es más débil que el de un certificado de pago.
La vida de 90 días existe porque la renovación debe ser automática
Los certificados de Let's Encrypt son válidos durante 90 días. La ventana corta es deliberada.
Limitar el daño de una clave filtrada
Si la clave privada de un servidor llega a filtrarse, un certificado de vida corta acorta el periodo en que se puede abusar de ella; y aunque la revocación se retrase, caduca por sí solo.
Hacer de la renovación automática lo predeterminado
Renovar a mano cada 90 días es poco práctico, así que los operadores tienen que automatizar, lo que empujó a todo el sector hacia «los certificados son algo que se rota automáticamente». En la práctica, las herramientas de renovación empiezan a intentarlo unos 30 días antes de la caducidad.
Por eso la verdadera tarea es vigilar
La renovación automática puede detenerse sin que nadie lo note: un cron roto, permisos cambiados, una comprobación de dominio que ya no pasa. Si no te das cuenta, 90 días después caduca. El hábito defensivo es vigilar el éxito de la renovación y los días restantes.
Nuestra opinión: nosotros lo hacemos así (TLS automático)
Este sitio funciona sobre el servidor web Caddy, que emite y renueva los certificados de Let's Encrypt automáticamente con solo apuntar un dominio a él (apenas hay configuración de certificados). «No tener que pensar en los certificados» es el objetivo: cuantos menos sitios toque una persona a mano, menos incidentes de caducidad por un cambio olvidado.
Si en cambio ejecutas certbot con un cron, lo prudente es vigilar si ese cron sigue funcionando de verdad, no dar por hecho que sí.
La vida útil se acorta (calendario a octubre de 2026)
Hoy el estándar son 90 días, pero Let's Encrypt ha anunciado que acortará la vida útil por etapas. El CA/Browser Forum, el organismo del sector que reúne a fabricantes de navegadores y autoridades de certificación, también ha decidido reducir por etapas la vida máxima de los certificados en los que confían los navegadores a partir de marzo de 2026, hasta llegar a 47 días en marzo de 2029.
| Cuándo | Qué cambia |
|---|---|
| A octubre de 2026 | Vida útil de 90 días |
| Desde el 13 de mayo de 2026 | El perfil opcional tlsserver ofrece certificados de 45 días |
| Desde el 10 de febrero de 2027 | El predeterminado (perfil classic) pasa a 64 días; la reutilización de la validación de dominio baja a 10 días |
| Desde el 16 de febrero de 2028 | El predeterminado pasa a 45 días; la reutilización de la validación de dominio baja a 7 horas |
Desde enero de 2026 también está disponible para todos un perfil shortlived con certificados de unos seis días (160 horas). Los certificados para direcciones IP solo se emiten como estos certificados de vida corta.
Lo práctico: no fijes en el código un intervalo de renovación como «cada 60 días». Let's Encrypt recomienda un cliente compatible con ARI (ACME Renewal Information), en el que la CA indica al cliente cuándo renovar; sin ARI, renueva cuando haya pasado dos tercios de la vida del certificado. Un cron con un número fijo de días empezará a provocar caducidades cuando la vida útil se acorte.
Lo que terminó en 2025: OCSP y los correos de caducidad
Let's Encrypt dejó de ofrecer dos cosas en 2025. Ten cuidado si sigues artículos o configuraciones antiguos.
- OCSP (comprobar en cada conexión si un certificado ha sido revocado): las URL de OCSP se eliminaron de los certificados el 7 de mayo de 2025, y los respondedores se apagaron el 6 de agosto. La comprobación de revocación depende ahora de las CRL (listas de certificados revocados). Uno de los motivos fue la privacidad: con OCSP, la CA podía saber qué dirección IP visitaba qué sitio.
- Correos de aviso de caducidad: dejaron de enviarse el 4 de junio de 2025. Antes recibías un correo al acercarse la caducidad; ahora no. Necesitas tu propia vigilancia de la caducidad.
El incidente más común: una renovación atascada y luego la caducidad
El problema más común con HTTPS no es un ataque, sino un certificado caducado. Al caducar, el navegador muestra un aviso a página completa y los visitantes casi siempre se marchan. La causa casi siempre es «la automatización de la renovación se había roto y nadie se dio cuenta».
Por eso justamente conviene tener una forma de revisar periódicamente la caducidad de tu propio certificado. La auditoría de seguridad del sitio de este sitio comprueba el certificado TLS (días restantes, caducidad, protocolos obsoletos) en un sitio que hayas verificado como tuyo, junto con las demás comprobaciones. Automatiza la renovación y luego verifica desde fuera que la automatización sigue funcionando. Juntos, estos dos hábitos evitan casi por completo los incidentes de caducidad.
Comparativa de los métodos de validación de dominio (desafíos)
ACME ofrece tres formas de demostrar que controlas un dominio. Elige la que encaje con tu configuración.
| Método | Qué colocas | Certificados comodín | Encaja bien cuando |
|---|---|---|---|
| HTTP-01 | Un archivo en una ruta fija de tu servidor web | No | Un servidor web normal accesible por el puerto 80 |
| DNS-01 | Un registro TXT en el DNS | Sí | Necesitas *.example.com, o el servidor no es accesible públicamente |
| TLS-ALPN-01 | Una respuesta en una conexión TLS al puerto 443 | No | Grandes proveedores de alojamiento y proxies inversos |
Automatizar DNS-01 implica guardar una clave de API del DNS en el servidor. Si esa clave se filtra, alguien puede cambiar los registros de tu dominio, así que elige un proveedor de DNS que permita limitar la clave a los registros TXT y guarda la clave en el menor número de sitios posible.
Cómo comprobar tu propio sitio
Comprueba el emisor y la caducidad en el navegador
Comprueba que la renovación se ejecuta de verdad
certbot certificates muestra las fechas de caducidad y certbot renew --dry-run prueba la renovación. En equipos con systemd, comprueba que aparece un temporizador de certbot en systemctl list-timers. Caddy registra la emisión y la renovación de certificados en sus logs.Busca certificados que no hayas pedido
Limita qué CA pueden emitir para ti
Vigila los días restantes desde fuera
Ejemplo: la caducidad del certificado raíz en 2021
Los certificados se verifican a través de una cadena que termina en un certificado raíz de confianza. Los certificados de Let's Encrypt eran de confianza al principio a través de la raíz de otra CA (DST Root CA X3), y esa raíz caducó el 30 de septiembre de 2021.
Desde ese día, los dispositivos y programas antiguos que no confiaban en la raíz propia de Let's Encrypt (ISRG Root X1) empezaron a mostrar avisos de certificado en los sitios que usaban Let's Encrypt (los dispositivos Android antiguos siguieron funcionando gracias a un arreglo especial). El certificado del sitio se había renovado correctamente y, aun así, los usuarios con dispositivos antiguos ya no podían conectarse.
Si gestionas API o sistemas a los que se conectan dispositivos antiguos, sigue los anuncios de Let's Encrypt y prepárate para los cambios de certificados intermedios y raíz. Let's Encrypt desaconseja fijar los certificados intermedios en la configuración; usa la cadena que recibe tu cliente ACME.
Sigue leyendo
- Aprende de un incidente: Heartbleed (un fallo de TLS/OpenSSL que puso en riesgo las claves privadas de muchos servidores)
- Revisa tu propio sitio: auditoría de seguridad del sitio (certificado TLS, cabeceras y archivos expuestos en un solo informe)
- Lo básico: la lista de comprobación de seguridad básica para desarrolladores indie
Fuentes (primarias)
- Blog oficial de Let's Encrypt (2 de diciembre de 2025, plan para acortar la vida útil a 45 días) — letsencrypt.org (fechas de los 64 y 45 días, periodos de reutilización de la validación, recomendación de ARI)
- Blog oficial de Let's Encrypt (15 de enero de 2026, disponibilidad general de los certificados de seis días y para direcciones IP) — letsencrypt.org
- Blog oficial de Let's Encrypt (5 de diciembre de 2024, fin de OCSP) — letsencrypt.org (fechas de eliminación de las URL de OCSP y de apagado de los respondedores)
- Blog oficial de Let's Encrypt (22 de enero de 2025, fin de los correos de aviso de caducidad) — letsencrypt.org
- Let's Encrypt, "Challenge Types" — letsencrypt.org
- Let's Encrypt, "Integration Guide" — letsencrypt.org (momento de la renovación, no fijar los intermedios)
- Let's Encrypt, "DST Root CA X3 Expiration (September 2021)" — letsencrypt.org
- CA/Browser Forum, "Ballot SC081v3" (aprobado el 11 de abril de 2025) — cabforum.org (la vida máxima de los certificados públicos llega a 47 días en marzo de 2029)