TLS: de tres años a cuarenta y siete días

No es que me despierte a las tres de la mañana pensando en la caducidad de un certificado… bueno, sí, en realidad sí me ha pasado. Pero lo que me quita el sueño no es el certificado en sí, sino la certeza de que el modelo que hemos usado durante años para gestionarlos se ha roto. Y no se ha roto por culpa nuestra. Se ha roto porque alguien decidió que tres años era demasiado tiempo para confiar en una clave pública, y que lo suyo era reducirlo. Y reducirlo. Y reducirlo un poco más.

He de reconocer que, cuando empecé con esto de los servidores, renovar un certificado era un ritual anual. Te llegaba el email del proveedor, pagabas, descargabas un ZIP, subías tres ficheros por FTP, reiniciabas Apache y cruzabas los dedos. En plano: una chapuza manual que funcionaba porque solo lo hacías una vez al año. A veces ni eso, porque comprabas certificados de dos o tres años y te olvidabas del tema.

Vamos, que el certificado era como el seguro del coche. Lo tienes, no lo miras, y cuando te avisan de que caduca entras en pánico.

El contexto: de 1.095 días a 47

Para entender dónde estamos, hay que mirar hacia atrás. No mucho. En 2015, podías comprar un certificado SSL con una vida útil de tres años. En 2018, el CA/Browser Forum (el organismo que reúne a las autoridades de certificación y los fabricantes de navegadores) decidió que tres años era excesivo y lo bajó a dos años. Luego, en 2020, lo redujeron a 398 días, que es el máximo actual.

Pero la cosa no paró ahí.

En octubre de 2024, Apple presentó en el CA/B Forum una propuesta que sonó como una sentencia: reducir progresivamente la vida de los certificados hasta llegar a 45 días. Después de meses de discusión, la propuesta se aprobó con algunos ajustes. El calendario definitivo, tras la votación de la Ballot SC081v3, es este:

15 de marzo de 2026: vida máxima de 200 días.
15 de marzo de 2027: vida máxima de 100 días.
15 de marzo de 2029: vida máxima de 47 días.

Let’s Encrypt, por su parte, tiene su propio calendario de transición. Actualmente emiten certificados de 90 días, pero ya han anunciado que en febrero de 2027 pasarán a 64 días, y en febrero de 2028 a 45 días. Además, el periodo de reutilización de la validación de dominio (DCV) se reducirá de meses a diez días, y luego a siete horas.

Siete horas. Piénsalo. En el tiempo que tarda un tío en hacerse un café largo y leer el correo, la autorización que le has dado a Let’s Encrypt para demostrar que eres dueño de tu dominio ha caducado.

¿Por qué hacen esto?

La respuesta corta es: porque cuanto más corta sea la vida de un certificado, menos daño hace si se compromete.

Si alguien roba la clave privada de un certificado que es válido durante tres años, tiene tres años para hacerse pasar por ti. Si el certificado dura 47 días, la ventana de ataque se reduce drásticamente. Es la misma lógica que usar contraseñas temporales o tokens de doble factor: limitar el tiempo durante el cual un secreto comprometido es peligroso.

Además, la renovación frecuente obliga a mantener la infraestructura actualizada. Si tienes que renovar cada mes y medio, no puedes tener un servidor con una versión de OpenSSL de 2019 porque, tarde o temprano, el proceso de renovación te lo recordará. Es una forma elegante (y un poco cruel) de forzar la higiene digital.

No todo el mundo está de acuerdo. Hay quien argumenta que la reducción masiva genera más problemas de los que resuelve: más puntos de fallo, más tráfico hacia las CAs, más complejidad para entornos legacy donde no hay ACME. Y no les falta razón. Pero la decisión está tomada. No es una propuesta, es un calendario aprobado. Así que, como decía mi abuela: llora un rato, luego limpia y sigue adelante.

El problema real: la matemática del cansancio

Vamos a hacer números. No muchos, los justos.

Imagina que gestionas cincuenta dominios. Con certificados de un año, renuevas unos cuatro al mes. Molesto, pero gestionable. Con certificados de 100 días, renuevas uno cada dos días. Con certificados de 47 días, renuevas uno cada día. Y eso sin contar los despliegues en múltiples servidores, los fallos de validación, los rate limits, los fines de semana, las vacaciones, las resacas.

La gestión manual deja de ser una opción. Deja de ser una deuda técnica que puedes aparcar. Se convierte en un suicidio operacional.

Y aquí es donde entra el protocolo ACME.

ACME: el protocolo que nos salvó antes de que supiéramos que nos hacía falta

ACME (Automatic Certificate Management Environment) es un protocolo estandarizado en el RFC 8555 que permite a un servidor solicitar, validar, obtener y renovar certificados TLS sin que un humano tenga que tocar nada. Fue creado por Let’s Encrypt en 2016 y se ha convertido en el estándar de facto para la automatización de certificados.

El flujo es elegante:

1. El cliente ACME crea una cuenta con la CA.
2. Solicita un certificado para un dominio.
3. La CA le exige un challenge: demuestra que controlas el dominio.
4. El cliente resuelve el challenge: bien sirviendo un fichero en el servidor (HTTP-01), bien creando un registro DNS (DNS-01), bien respondiendo por TLS (TLS-ALPN-01).
5. La CA valida, firma el certificado, y el cliente lo recibe.
6. Todo esto se repite automáticamente antes de que el certificado caduque.

El ecosistema ACME es enorme. Certbot, acme.sh, Lego, win-acme, cert-manager para Kubernetes… Hay clientes para casi cualquier plataforma. Y las CAs comerciales (Sectigo, DigiCert, Google Trust Services, ZeroSSL) ya soportan ACME, muchas de ellas con External Account Binding (EAB) para vincular la cuenta ACME a una cuenta de cliente existente.

Pero ACME no es la varita mágica. Es una pieza del puzzle. La otra pieza es: ¿qué haces con el certificado una vez lo tienes?

Recoger y publicar: las dos mitades del problema

Hay dos operaciones distintas que hay que automatizar, y confundirlas es un error clásico.

Recoger es obtener el certificado: generarlo, renovarlo, descargarlo. Ya sea por ACME, por API de un proveedor comercial, por HTTP, o incluso por FTP si vives en el pasado pero con buena conexión.

Publicar es llevar ese certificado al servidor donde realmente sirve tráfico TLS: el Nginx, el Apache, el HAProxy, el Proxmox, el servidor de correo. Y no basta con copiar los ficheros. Hay que recargar el servicio, verificar que funciona, y tener un plan para cuando algo falla.

Muchas herramientas ACME hacen la primera parte bien pero la segunda de forma acoplada y rígida. Certbot tiene plugins para Nginx y Apache, pero si tu infraestructura usa un panel propio, o si tienes certificados en un lugar y servidores en otro, te encuentras rápidamente en un callejón sin salida. Necesitas algo que separe claramente el origen del destino, y que te permita mezclar y combinar.

Lo que están haciendo las plataformas

La industria se está moviendo en varias direcciones a la vez, algunas más elegantes que otras.

Las CAs comerciales están integrando ACME a marchas forzadas. DigiCert, Sectigo, SSL.com, Certigna… todas tienen soporte ACME, aunque algunas lo venden como un valor añadido cuando en realidad es una supervivencia. Si tu CA no tiene ACME en 2027, es que está muerta y no lo sabe.

Los proveedores de hosting están ocultando el problema al usuario final. Si usas un hosting gestionado, probablemente ni te enteres de la reducción a 47 días porque ellos lo gestionan por debajo. Pero si gestionas tu propia infraestructura (VPS, dedicados, Proxmox, clusters) el problema es tuyo y solo tuyo.

Los sistemas de gestión de certificados (CLM, Certificate Lifecycle Management) están floreciendo como setas. Empresas como AppViewX, KeyTalk, Venafi o soluciones open source como Cert Warden ofrecen paneles centralizados. Pero muchas son cajas negras caras, o no encajan en flujos de trabajo específicos como el nuestro.

Y luego está el mundo Kubernetes, donde cert-manager ya gestiona certificados ACME de forma nativa. Pero no todo el mundo vive en Kubernetes. Algunos todavía tenemos servidores con systemd, ficheros de configuración que editamos a mano, y la sensación de que un contenedor no es la respuesta a todos los males.

Qué estamos construyendo en ROBOTSTXT

He de decir que llevaba tiempo queriendo atacar este problema de forma seria. No con un script de cron que funciona a medias, no con un Certbot que toca ficheros que no quiero que toque, sino con algo integrado en el panel que ya usamos para gestionar la infraestructura.

La idea es sencilla en el papel: una sección en el panel de control de ROBOTSTXT que permita recoger certificados de varios sitios y publicarlos en los servidores, todo de forma automatizada.

La parte de publicar es, en cierto modo, la más fácil. Ya tenemos acceso SSH a todas las máquinas. Sabemos dónde viven los ficheros de cada servidor web. Sabemos cómo recargar Nginx sin cortar conexiones, cómo validar la configuración de Apache antes de aplicarla, cómo reiniciar Proxmox sin que el panel se vaya al traste. Tenemos la red, tenemos las credenciales, tenemos el know-how. Subir un .pem y un .key y hacer un systemctl reload no es rocket science.

El verdadero reto es la recogida.

Orígenes: de dónde vienen los certificados

Hemos diseñado el sistema para soportar varios orígenes, porque no todos los certificados se gestionan igual.

DonDominio ya está integrado en nuestro panel. De ahí obtenemos certificados comerciales (algunos con validación OV, otros wildcard) y tenemos acceso directo a los ficheros .pem, .crt y .key vía API. Para estos, la recogida es lectura de base de datos y poco más.

ACME es donde reside la complejidad. Estamos construyendo un cliente ACME completo, compatible con RFC 8555, que pueda hablar con Let’s Encrypt, ZeroSSL, Google Trust Services, y también con CAs comerciales que requieren External Account Binding como Sectigo o DigiCert. El challenge por defecto será DNS-01, porque nos permite emitir wildcards y porque ya controlamos la gestión DNS a través de la propia integración con los sistemas DNS que usamos. Pero también soportaremos HTTP-01 para casos más simples.

HTTP y FTP/SFTP cubren los casos edge. A veces un proveedor externo expone certificados en un endpoint REST. A veces un sistema legacy los deja en un servidor SFTP. No podemos ignorar esos escenarios, por muy feos que sean. El panel permitirá configurar una URL o una conexión FTP, descargar los ficheros, validarlos, y meterlos en el almacén.

El almacén: un vault centralizado

Todos los certificados recogidos van a parar a un almacén central en el panel. No es solo una carpeta con ficheros. Es una base de datos que guarda la metadata completa: dominio, SANs, fechas de validez, emisor, tipo de certificado, origen, historial de renovaciones. Y las claves privadas se cifran con AES-256-GCM antes de tocar disco.

La validación es obligatoria antes de almacenar: comprobamos que el certificado parsea correctamente, que las fechas son coherentes, que la cadena intermedia firma el certificado, y que la clave privada corresponde realmente al certificado. No queremos descubrir a las tres de la mañana que hemos desplegado un .key que no casa con el .crt.

Despliegue: del vault al servidor

Una vez el certificado está en el almacén, el panel puede desplegarlo en cualquier servidor configurado como destino. El flujo es:

1. Backup del certificado actual en el servidor destino.
2. Subida de los nuevos ficheros por SCP/SFTP/SSH.
3. Ajuste de permisos (0600 para la key, 0644 para el cert).
4. Validación de la configuración del servidor web (nginx -t, apachectl configtest).
5. Recarga graceful del servicio.
6. Health check: conectamos al servidor y verificamos que presenta el certificado nuevo, con las fechas correctas.
7. Si algo falla, rollback automático al backup.

Soportamos Angie, Nginx, Apache, HAProxy, Proxmox… y dejamos una opción «custom» para lo que se nos ocurra. Porque si algo he aprendido en veinticinco años de esto, es que siempre hay un servidor raro que nadie quiere tocar pero todo el mundo necesita.

Renovación automática y alertas

El motor de renovación revisa periódicamente los certificados y programa renovaciones antes de que caduquen. Los umbrales se adaptan automáticamente a la vida útil del certificado: si dura 398 días, renovamos con 30 días de margen; si dura 47 días, renovamos cuando haya consumido el 70% de su vida, es decir, a los 33 días, dejando dos semanas de margen.

Las alertas se integran con el sistema de monitorización que ya tenemos: Netdata en cada máquina, alertas en el panel para certificados por caducar, notificaciones por email cuando algo falla. No queremos sorpresas. Las sorpresas en infraestructura son como las sorpresas en dentistas: nunca son buenas.

La deuda técnica que no queremos acumular

He de reconocer que una parte de mí mira todo esto y piensa: «¿No podríamos simplemente usar Certbot y olvidarnos?». Y la respuesta es que sí, podríamos. Pero sería otra deuda técnica. Otro sistema externo que no controlamos, que toca ficheros que no queremos que toque, que no se integra con nuestro panel, que no sabe dónde están nuestros servidores, que no puede desplegar en Proxmox o en un servidor de correo.

Vamos, que sería la solución fácil para el problema fácil, pero no para nuestro problema. Y nuestro problema es que gestionamos docenas de dominios en docenas de servidores, con clientes que a veces miran el panel y a veces no, y necesitamos que todo funcione sin que nadie tenga que acordarse de nada.

La reducción a 47 días no es una amenaza si tienes automatización. Es una amenaza si sigues renovando a mano. Y yo, sinceramente, estoy demasiado cansado para seguir renovando certificados a mano.

Cierre

El certificado TLS ha pasado de ser un trámite anual a convertirse en un proceso continuo. Como el agua que entra en una embarcación: si tienes una bomba automática, navegas tranquilo; si tienes un cubo y ánimo, te hundes.

Las plataformas que no se pongan al día con ACME, con la automatización de la recogida y el despliegue, y con la monitorización proactiva, van a sufrir. No es una predicción, es una consecuencia matemática. Cuarenta y siete días son poco más de un mes y medio. Sin automatización, es imposible.

En ROBOTSTXT estamos construyendo esa bomba automática. No porque sea divertido (aunque, en este momento, lo es) sino porque no hay otra opción. Y porque, si he de elegir entre una alerta a las tres de la mañana o dormir tranquilo, ya sabes cuál prefiero.

¿Y tú? ¿Sigues con el cubo, o ya estás buscando la bomba?