Por qué los certificados se acortan
El CA/B Forum, el organismo que reúne a autoridades de certificación y fabricantes de navegadores, adoptó en abril de 2025 la votación SC-081v3. Esta organiza la reducción progresiva de dos plazos: la validez de los certificados y el periodo durante el cual puede reutilizarse una validación de dominio. Apple, Google, Microsoft y Mozilla votaron a favor. El objetivo es doble: limitar la exposición de una clave comprometida o de un certificado emitido por error, y obligar a las infraestructuras a renovar a menudo, es decir, a automatizar. Un certificado válido durante un año rara vez se revoca a tiempo cuando su clave se filtra; un certificado de seis semanas caduca por sí solo antes de causar mucho daño. El sector sigue el movimiento: en 2026, AWS Certificate Manager abrió un punto de acceso ACME que emite certificados públicos de 45 días. Acortar la vida útil solo reduce la superficie de ataque con una condición: que la renovación sea fiable, automática y supervisada. Es lo que esta guía pone en marcha.
Los riesgos concretos de la renovación manual
- Caducidad silenciosa — un certificado renovado a mano depende de una alerta de calendario o de un recordatorio humano, dos mecanismos que fallan con regularidad en periodos de carga o en cambios de equipo.
- Alertas tardías — las herramientas de monitorización clásicas avisan a 30 días de la caducidad, un umbral pensado para certificados de un año; en un certificado de 64 días, la alerta llega cuando ya ha consumido más de la mitad de su vida.
- Sin recordatorios por correo — Let's Encrypt dejó de enviar sus correos de aviso de caducidad el 4 de junio de 2025; si nada supervisa sus certificados, ya nadie le avisa.
- Parámetros criptográficos congelados — la renovación manual invita a repetir la misma configuración; la automatización impone en cambio una política de claves aplicada siempre.
- Impacto en los compromisos de servicio — una interrupción causada por un certificado caducado compromete la responsabilidad contractual y daña la reputación de la plataforma.
- Carga operativa creciente — renovando a dos tercios de la vida útil, un certificado de 64 días se renueva unas ocho veces al año, y una docena de veces a 45 días, sin ningún valor añadido para el equipo.
El calendario del CA/B Forum: 200, 100 y luego 47 días
Los Baseline Requirements fijan la validez máxima de un certificado de servidor público, sea cual sea la autoridad que lo emita. Desde el 15 de marzo de 2026 es de 200 días, frente a 398 antes. El 15 de marzo de 2027 bajará a 100 días. El 15 de marzo de 2029 llegará a 47 días. El periodo durante el cual una autoridad puede reutilizar una validación de dominio ya realizada sigue la misma pendiente: 200 días, luego 100 días y después solo 10 días. Esta segunda curva es la menos comentada y la más exigente: significa que su cliente ACME tendrá que demostrar el control del dominio casi en cada renovación. Si su validación depende de un registro DNS añadido a mano, o de un puerto 80 abierto solo de vez en cuando, es lo primero que fallará. Los certificados comerciales comprados hoy ya están limitados a 200 días: el cambio no está por llegar, ya ha empezado.
Let's Encrypt pasa a 64 días: las fechas que importan
Let's Encrypt anunció el 7 de octubre de 2026 un calendario más rápido que el límite reglamentario. Desde el 14 de octubre de 2026, su entorno de staging emite certificados de 64 días para que pueda hacer pruebas. El 10 de febrero de 2027, todo certificado emitido o renovado en producción con el perfil por defecto, classic, tendrá una validez de 64 días, y la reutilización de autorizaciones pasará de 30 a 10 días. Se espera que el último certificado de 90 días caduque hacia el 11 de mayo de 2027. El 16 de febrero de 2028, el perfil por defecto pasará a 45 días, con una reutilización de autorizaciones reducida a 7 horas. Ya existen perfiles opcionales: tlsserver emite certificados de 45 días y shortlived certificados de unos seis días. Let's Encrypt precisa que los certificados válidos no se revocarán, que los límites de tasa no cambian y que los puntos de acceso ACME y las cadenas de emisión siguen iguales.
Tabla de referencia: qué cambia y cuándo
Desplace la tabla
| Fecha | Cambio | Qué debe comprobar |
|---|---|---|
| 15 de marzo de 2026 | Límite del CA/B Forum en 200 días | Sus certificados comerciales anuales ya están limitados |
| 14 de octubre de 2026 | Staging de Let's Encrypt en 64 días | Su cadena de renovación funciona contra staging |
| 10 de febrero de 2027 | Perfil `classic` en 64 días, autorizaciones reutilizables 10 días | Ningún plazo fijado en 60, 80 u 83 días |
| 15 de marzo de 2027 | Límite del CA/B Forum en 100 días | Renovación automatizada con todas sus autoridades |
| 11 de mayo de 2027 | Caducidad prevista del último certificado Let's Encrypt de 90 días | Ningún certificado de 90 días en el inventario |
| 16 de febrero de 2028 | Perfil `classic` en 45 días, autorizaciones reutilizables 7 horas | Validación de dominio correcta en cada renovación |
| 15 de marzo de 2029 | Límite del CA/B Forum en 47 días, validación reutilizable 10 días | Supervisión de la caducidad en todo el parque |
Qué cambia en la lógica de renovación
La regla que hay que recordar es sencilla: renueve a dos tercios de la vida útil, nunca a un número fijo de días. Con 64 días, eso supone renovar hacia el día 43, con tres semanas de margen para corregir un fallo. Una tarea cron configurada para «renovar cada 60 días» dejaría solo cuatro días de margen, y con un certificado de 45 días llegaría después de la caducidad. Let's Encrypt recomienda buscar en sus crontabs, scripts y procedimientos valores fijos como 60, 80 u 83. La segunda palanca se llama ARI, por ACME Renewal Information, estandarizada en la RFC 9773: la propia autoridad indica a su cliente una ventana de renovación. Si su cliente la admite, sigue automáticamente las nuevas duraciones y renueva antes si la autoridad tiene que revocar certificados de forma masiva. Es la configuración que recomienda Let's Encrypt: con ARI activo, el anuncio de los 64 días no requiere ninguna acción por su parte.
Checklist de automatización, cliente por cliente
Inventariar los certificados existentes
Enumere cada certificado activo: dominios cubiertos, autoridad emisora, fecha de caducidad, método de validación (HTTP-01, DNS-01, TLS-ALPN-01) y cliente que lo renueva.
certbot certificateslista los que gestiona certbot. Para los demás,echo | openssl s_client -connect your-domain.com:443 -servername your-domain.com 2>/dev/null | openssl x509 -noout -issuer -datesmuestra el emisor y las fechas de validez. Anote también los certificados copiados a mano a un balanceador de carga, un NAS o un equipo de red: son los que caducan en silencio.Comprobar que su cliente admite ARI
certbot admite ARI desde la versión 4.1.0, y
acme.shdesde la versión 3.1.4, donde está activo por defecto. Caddy lo integra desde la versión 2.8. Compruebe la versión instalada concertbot --versionoacme.sh --version. Una distribución antigua puede incluir un certbot anterior: en ese caso instale el paquete snap que recomienda la EFF, o un entorno Python dedicado, en lugar de conservar una versión que ignora la ventana propuesta por la autoridad.certbot: eliminar los plazos fijos
Desde la versión 4.0.0, certbot renueva por defecto cuando queda un tercio de la vida útil, y ARI puede adelantar esa fecha. Abra
/etc/letsencrypt/renewal/your-domain.com.confy elimine un valorrenew_before_expirydemasiado corto heredado de un tutorial antiguo: sin él, se aplica la regla del tercio. Compruebe que el planificador funciona consystemctl list-timers | grep certbot. Para pasar ya a 45 días, la opción--preferred-profile tlsserversolicita ese perfil en la emisión.acme.sh: dejar que decida ARI
Desde la versión 3.1.4,
acme.shsigue la ventana ARI de la autoridad y su tarea cron se ejecuta cada seis horas;acme.sh --install-cronjobla reinstala si ha desaparecido. Cuidado con la trampa contraria: desde la versión 3.1.5, una opción--dayso--valid-toexplícita prevalece sobre ARI. Un antiguo comando de emisión con--days 60forzaría por tanto una renovación el día 60 de un certificado de 64 días. Elimínela y compruebe la próxima renovación prevista conacme.sh --list.Caddy: comprobar el almacenamiento y los puertos
Caddy gestiona ACME de forma nativa y combina ARI, la vida útil real del certificado y su estado de revocación para decidir cuándo renovar: no hace falta ninguna configuración para absorber 64 y luego 45 días. Los dos puntos que hay que vigilar están en otra parte. El directorio de datos de Caddy debe ser persistente; de lo contrario, cada recreación del contenedor vuelve a pedir certificados y acaba chocando con un límite de tasa. Y el puerto 80, o el 443 para TLS-ALPN-01, debe seguir accesible desde Internet para la validación.
Traefik: no falsear certificatesDuration
Traefik planifica sus renovaciones a partir de la opción
certificatesDuration, expresada en horas. Su valor por defecto,2160(90 días), lanza una renovación 30 días antes de la caducidad: con un certificado de 64 días, eso cae hacia el día 34, con un margen cómodo. No copie un valor encontrado en un tutorial antiguo: según la documentación, una duración declarada de entre 7 y 30 días solo lanza la renovación un día antes de la caducidad. Por último, guardeacme.jsonen un volumen persistente, con modo600.nginx: automatizar la recarga
nginx no vuelve a leer un certificado renovado hasta que se recarga: una renovación correcta puede dejar en servicio el certificado antiguo hasta que caduque. Con certbot, coloque en
/etc/letsencrypt/renewal-hooks/deploy/un script ejecutable que contenganginx -t && systemctl reload nginx, o pase--deploy-hook "systemctl reload nginx"en la emisión. Conacme.sh, la opción--reloadcmd "systemctl reload nginx"de--install-certguarda el comando para las renovaciones siguientes. NGINX también ofrece un módulo ACME nativo,ngx_http_acme_module.Probar contra staging
Ejecute su cadena contra el entorno de staging, que ya emite certificados de 64 días y tiene límites de tasa mucho más amplios. Con certbot,
certbot renew --dry-runpasa por staging sin tocar sus certificados; este modo no consulta ARI. Para obtener un certificado de prueba real, use--test-certen un dominio no crítico. Conacme.sh, añada--staging. Con Caddy o Traefik, apunte la autoridad ahttps://acme-staging-v02.api.letsencrypt.org/directoryy compruebe la duración conopenssl x509 -noout -dates -in cert.pem.Supervisar la caducidad y conectar el resto del parque
Una renovación automatizada que falla sin avisar es peor que una manual. Añada un hook de despliegue que notifique a un canal de alertas cada renovación correcta, y una sonda independiente que mida cada día los días restantes del certificado realmente servido. Configure la alerta sobre una fracción de la vida útil, por ejemplo menos de un cuarto de validez restante, en lugar de 30 días fijos. Para la puesta en marcha inicial en un VPS, nuestra guía sobre certificados SSL con Let's Encrypt detalla HTTP-01, DNS-01 y los wildcards.
No dé nunca por hecho que una configuración de renovación funciona sin haberla visto funcionar. Varias semanas antes del 10 de febrero de 2027, ejecute certbot renew --force-renewal --cert-name your-domain.com en un dominio no crítico y compruebe con openssl s_client que el servidor sirve realmente el nuevo certificado. La prueba cuesta unos minutos y elimina el fallo más frecuente: un certificado renovado en disco que nadie ha recargado.
Solución de problemas: los mensajes de error más frecuentes
Timeout during connect (likely firewall problem)— la autoridad no pudo llegar a su servidor por el puerto 80 (HTTP-01) o 443 (TLS-ALPN-01). Revise el cortafuegos conufw status, las reglas de red de su proveedor y el registro AAAA: una dirección IPv6 publicada pero no servida basta para que falle la validación.Invalid response from http://your-domain.com/.well-known/acme-challenge/…: 404— el archivo del desafío no se sirve. Una redirección mal colocada, un bloquelocationdemasiado amplio o un reverse proxy que lo envía todo a la aplicación son la causa habitual; excluya/.well-known/acme-challenge/de esas reglas.CAA record for your-domain.com prevents issuance— un registro DNS CAA no autoriza a esta autoridad. Añada0 issue "letsencrypt.org"a la zona, o el nombre de la autoridad que realmente utiliza.too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s— un script que fuerza la renovación en bucle ha alcanzado el límite de cinco certificados idénticos por semana. Espere a la hora indicada trasretry aftery haga sus pruebas en staging.- El navegador sigue mostrando la fecha de caducidad antigua — el certificado se renovó en disco, pero el servidor web no se recargó. Revise el hook de despliegue y compare
openssl x509 -noout -enddateen el archivo y en la conexión real.
Para ir más lejos
El paso a 64 días no es un acontecimiento que se prepara una sola vez: es un peldaño de una escalera que baja hasta 45 días en Let's Encrypt y 47 días en todas las autoridades. Una infraestructura que renueva a dos tercios, escucha ARI, recarga sus servicios y supervisa el certificado realmente servido subirá cada peldaño sin intervención. Si empieza con Let's Encrypt en un VPS, nuestro artículo sobre certificados SSL con Let's Encrypt detalla la puesta en marcha inicial y los casos particulares de los wildcards. Para las nuevas infraestructuras, Caddy merece una atención especial: su soporte nativo de ACME elimina por completo la capa de gestión de certificados. Por último, si su validación se basa en DNS-01, limite el token de la API DNS a la única zona afectada: con una validación reutilizable solo diez días, ese token se usará casi en cada renovación.
