El 8 de mayo de 2026 a las 18:37 UTC, Let's Encrypt publicó un aviso en su página oficial de estado anunciando la suspensión inmediata de la emisión de certificados. La autoridad certificadora gratuita más usada del mundo declaró estar investigando un "potential incident" que afecta a sus componentes de producción y staging, incluyendo acme-v02.api.letsencrypt.org y el portal de gestión.
La nota oficial es escueta: "We have been made aware of a potential incident and are shutting down all issuance." En la práctica, esto significa que cualquier servidor, dispositivo o pipeline CI/CD que dependa de Let's Encrypt para renovar certificados TLS está bloqueado mientras dure la investigación. Para una infraestructura que emite más de cinco millones de certificados al día, una pausa de incluso unas horas tiene un efecto cascada considerable sobre internet.
Qué pasó con Let's Encrypt el 8 de mayo de 2026
El aviso publicado en letsencrypt.status.io es deliberadamente parco. La organización no ha revelado la naturaleza del incidente: no se sabe si se trata de una vulnerabilidad en su software CA Boulder, un compromiso de infraestructura, una emisión incorrecta detectada por un tercero, o un fallo operacional. Los componentes marcados como afectados son los cuatro endpoints principales:
- acme-v02.api.letsencrypt.org — endpoint de producción del protocolo ACME donde se solicitan los certificados.- acme-staging-v02.api.letsencrypt.org — endpoint de pruebas, normalmente usado para validar pipelines antes de pegarle a producción.- portal.letsencrypt.org — portal web de administración.- portal-staging.letsencrypt.org — portal de pruebas.
La ubicación reportada es High Assurance Datacenter 1 y High Assurance Datacenter 2, los dos centros de datos donde Let's Encrypt mantiene sus claves de firma offline. El estado oficial es INVESTIGATING: la fase inicial de un incidente público en la que el equipo aún recopila información y todavía no ha confirmado causa raíz.
El aviso oficial detuvo emisiones en producción y staging simultáneamente.
⚠️ Ojo: mientras dure la suspensión, cualquier intento de obtener un certificado nuevo o renovar uno existente vía Let's Encrypt fallará. Los certificados ya emitidos siguen siendo válidos hasta su fecha de expiración (normalmente 90 días), pero las renovaciones automáticas configuradas para los próximos días pueden romperse.
Por qué Let's Encrypt es crítico para la web
Para entender la magnitud del incidente conviene recordar qué es Let's Encrypt. Lanzado en 2015 por la Internet Security Research Group (ISRG) con el respaldo de Mozilla, EFF, Akamai y Cisco, Let's Encrypt se propuso un objetivo simple pero ambicioso: cifrar el 100% de la web ofreciendo certificados TLS gratuitos, automatizados y abiertos.
Antes de Let's Encrypt, un certificado TLS costaba entre 50 y 500 dólares anuales y requería un proceso manual de validación. Para un blog personal, una pyme latinoamericana o una startup en su primer mes, eso era una barrera real. Diez años después, la organización emite más certificados que cualquier otra autoridad del planeta y, según sus propias estadísticas, ha contribuido a que el porcentaje de páginas cargadas con HTTPS en Firefox pasara de menos del 40% a más del 90%.
Su modelo de operación lo hace particularmente sensible a este tipo de incidentes:
- Validez corta — los certificados duran 90 días, lo que obliga a renovaciones frecuentes.- Automatización vía ACME — la mayoría de los servidores los renuevan automáticamente con clientes como Certbot, acme.sh o acme-companion.- Sin contrato comercial — al ser gratuito, no hay SLA contractual que cubra una caída.
El protocolo ACME y por qué la suspensión rompe automatizaciones
ACME (Automatic Certificate Management Environment), estandarizado en el RFC 8555, es el protocolo que permite a un servidor demostrar el control sobre un dominio y obtener un certificado sin intervención humana. Un flujo típico de renovación se ve así:
sequenceDiagram
participant S as Servidor
participant A as ACME
participant D as Dominio
S->>A: solicita newOrder
A-->>S: devuelve challenge HTTP-01
S->>D: publica el reto en su web
A->>D: verifica el reto
A-->>S: validacion OK
S->>A: envia CSR
A-->>S: emite certificado
Cuando el endpoint ACME está caído, ese flujo falla en el primer paso. Los clientes reaccionan distinto: Certbot reintenta con backoff exponencial; acme.sh registra el error y vuelve en el próximo cron; Caddy y Traefik mantienen el certificado actual hasta que sea posible renovar. La buena noticia es que, salvo que tu certificado venza dentro de las próximas horas, no notarás nada inmediato.
Un ejemplo práctico de cómo podés probar manualmente si Let's Encrypt está respondiendo (Linux/macOS):
# Ver el estado del directorio ACME
curl -i https://acme-v02.api.letsencrypt.org/directory
# Forzar renovación con Certbot (modo dry-run)
sudo certbot renew --dry-run
# Listar certificados con su fecha de expiración
sudo certbot certificates
En Windows, con OpenSSL instalado vía Chocolatey o WSL:
# PowerShell con Invoke-WebRequest
Invoke-WebRequest -Uri https://acme-v02.api.letsencrypt.org/directory -UseBasicParsing
# WSL / Git Bash funciona igual que Linux
curl -i https://acme-v02.api.letsencrypt.org/directory
Si la primera llamada devuelve algo distinto de un JSON con los endpoints o falla con timeout, el problema sigue en pie. El comando certbot certificates te muestra cuáles están próximos a vencer y te ayuda a priorizar.
Datos y cifras: la escala del problema
Las cifras hacen evidente por qué este incidente es relevante:
- Let's Encrypt emite, en promedio, más de 5 millones de certificados nuevos por día entre emisiones y renovaciones.- Más de 500 millones de sitios activos usan certificados de Let's Encrypt, según las estadísticas oficiales de la organización.- La validez de cada certificado es de 90 días; muchos sistemas renuevan a los 60 días, dejando un margen de 30 días de buffer.- En 2025, Let's Encrypt comenzó a ofrecer certificados de 6 días de duración en piloto, lo que aumenta aún más la dependencia de su disponibilidad continua.- La organización opera con un equipo técnico relativamente pequeño y una infraestructura concentrada en dos centros de datos de alta seguridad. Más de 500 millones de sitios dependen de la CA gratuita más popular del mundo. ## Impacto en desarrolladores y empresas en LATAM
Para América Latina, donde una proporción altísima del hosting independiente, los proyectos de software libre y las pymes tecnológicas dependen de Let's Encrypt, el efecto puede sentirse rápido. Algunos escenarios concretos:
- Pipelines CI/CD que provisionan ambientes efímeros (preview deployments en Vercel-like, Render, Fly.io o Railway) pueden fallar al obtener certificados nuevos.- Kubernetes con cert-manager seguirá intentando renovar; los pods con certificados vencidos pueden bloquear ingress controllers y romper el tráfico interno.- Servidores hogareños o self-hosted que ejecutan Certbot semanalmente verán errores en los logs hasta que el servicio vuelva.- SaaS que emite subdominios para clientes bajo modelo wildcard y depende del DNS-01 challenge no podrá registrar nuevos clientes hasta que se restablezca el servicio.- Hosting compartido de proveedores regionales que usan Let's Encrypt como backend para certificados gratuitos del cliente pierde su capacidad de provisionar nuevos sitios HTTPS.
Cómo verificar si estás afectado y mitigar el impacto
Mientras Let's Encrypt comunica más detalles, hay tres cosas concretas que podés hacer hoy mismo:
1. Auditar tus certificados actuales
El comando openssl s_client -connect tudominio.com:443 -servername tudominio.com 2>/dev/null | openssl x509 -noout -dates te muestra la fecha de expiración. Si tenés más de 7 días de margen, podés esperar a que se restablezca el servicio sin intervenir.
2. Considerar autoridades alternativas
Si tu certificado vence en horas, la opción más rápida es cambiar a otra CA con soporte ACME. Las alternativas comunes son ZeroSSL, Buypass Go SSL y Google Trust Services. Casi todos los clientes ACME modernos permiten cambiar el endpoint con un parámetro:
# Certbot con ZeroSSL (requiere registrar cuenta primero)
sudo certbot certonly \
--server https://acme.zerossl.com/v2/DV90 \
--eab-kid TU_KID --eab-hmac-key TU_KEY \
-d ejemplo.com
# acme.sh con Buypass
acme.sh --issue --server https://api.buypass.com/acme/directory \
-d ejemplo.com -w /var/www
# Caddy: cambiar la directiva en Caddyfile
# tls user@dominio.com {
# ca https://acme.zerossl.com/v2/DV90
# }
3. Suscribirse al feed de estado
El status page de Let's Encrypt soporta RSS, email, Slack y Microsoft Teams. Para SREs en LATAM, agregar el feed RSS al canal de #ops es la forma más confiable de enterarse en tiempo real sin depender del horario de oficina norteamericano.
💡 Tip: antes de cambiar de CA en producción, probá el flujo completo en staging. Algunas CAs alternativas requieren External Account Binding (EAB), un paso extra de registro que Let's Encrypt no exige.
Antecedentes: cuando las CAs fallan
Este no es el primer incidente que afecta a una autoridad certificadora masiva. En 2020, Let's Encrypt tuvo que revocar 3 millones de certificados por un bug en la verificación CAA (Certificate Authority Authorization) que afectaba a un subset de emisiones. La revocación se ejecutó en horas, y aunque la mayoría de los sitios renovaron sin problemas, hubo cientos de incidentes operacionales reportados en foros y redes.
En 2011, la CA neerlandesa DigiNotar fue comprometida por un atacante que emitió certificados fraudulentos para Google, Mozilla y agencias gubernamentales iraníes. La empresa terminó en bancarrota y los browsers la removieron por completo de sus root stores. Es el peor escenario posible para una CA: pérdida total de confianza.
El precedente importa porque muestra que una CA puede operar correctamente durante años y caer en horas. La práctica de certificate pinning ha ido en retroceso justamente porque vincular tu sitio a una CA específica te deja sin escape en escenarios como el actual.
📌 Nota: el ecosistema TLS está diseñado para tolerar fallos de CAs individuales, pero solo si los operadores tienen un plan B preconfigurado. La mayoría no lo tiene.
Qué sigue
Por ahora, el siguiente paso pertenece a Let's Encrypt. El protocolo de incidentes públicos típicamente sigue cuatro fases: investigating → identified → monitoring → resolved. Una vez que la organización publique el post-mortem (suelen hacerlo dentro de las 72 horas en su foro de la comunidad), sabremos:
- La causa raíz exacta del incidente.- Si hubo certificados emitidos incorrectamente que requieran revocación masiva.- El timeline completo desde la detección hasta la mitigación.- Qué cambios operacionales se introducirán para evitar recurrencia.
Para los equipos de ingeniería, el aprendizaje recurrente es el mismo: la disponibilidad de tu sitio depende de servicios externos que tarde o temprano fallan. Tener un plan B documentado, certificados con margen de renovación amplio y monitoreo proactivo de fechas de expiración convierte un incidente como este en una nota a pie de página del log diario, no en una página de operaciones llena de tickets P1.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Mi sitio se va a caer si tengo certificados de Let's Encrypt?
No de forma inmediata. Los certificados ya emitidos son válidos hasta su fecha de expiración. El problema solo aparece si la renovación está programada durante el período de suspensión y el servicio no se restablece a tiempo.
¿Cómo sé cuándo expira mi certificado?
Podés correr openssl s_client -connect tudominio.com:443 -servername tudominio.com 2>/dev/null | openssl x509 -noout -dates en cualquier máquina con OpenSSL, o consultar crt.sh con tu dominio para ver toda la cadena emitida y sus fechas.
¿Tengo que cambiar de autoridad certificadora ya?
Solo si tenés vencimientos en menos de 24-48 horas. Para la mayoría de los casos, esperar a que Let's Encrypt restablezca el servicio es la opción más simple. Si manejás infraestructura crítica, vale la pena tener una CA secundaria preconfigurada como backup.
¿Qué pasa con los certificados wildcard?
Los wildcard usan el desafío DNS-01, que también pasa por la API ACME suspendida. Si dependés de wildcards para multi-tenancy, la suspensión te afecta exactamente igual que a los certificados regulares.
¿Hay diferencia entre el endpoint v2 y staging?
El staging existe para que los clientes prueben el flujo sin consumir la cuota de producción. Ambos están reportados como afectados, lo que sugiere que el problema no es de capacidad sino algo más profundo de la infraestructura compartida entre los dos ambientes.
¿Cuánto suele durar un incidente así?
Históricamente, los incidentes de emisión en Let's Encrypt han durado entre 2 y 8 horas. El de marzo de 2020 con la revocación CAA tardó 24 horas en resolverse del todo. La duración exacta depende de la complejidad del problema y de si requiere despliegue de código nuevo en producción.
Referencias
- Let's Encrypt Status — Stopping Issuance for Potential Incident — aviso oficial del incidente del 8 de mayo de 2026.- Let's Encrypt Statistics — cifras públicas actualizadas de emisión y adopción.- RFC 8555 — Automatic Certificate Management Environment (ACME) — especificación oficial del protocolo.- letsencrypt/boulder en GitHub — código fuente del software CA usado por Let's Encrypt.- crt.sh — buscador público de certificados emitidos en Certificate Transparency logs.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)