El certificado que ACME no renueva es el que te deja sin VPN

Haz la suma: 15 de marzo de 2026, el día en que entró en vigor el techo de 200 días para los certificados TLS públicos, más 200 días. Sale el 1 de octubre de 2026. Hoy. Los primeros certificados emitidos con la regla nueva empiezan a vencer esta semana, y con ellos se acaba la parte del calendario en la que esto era un asunto de 2029.

Somos operador con red propia: llevamos BGP, tránsito y peering, túneles entre sedes con WireGuard, SD-WAN multi-sede y la documentación de todo eso en NetBox. Y por eso la conversación sobre certificados cortos nos interesa desde un ángulo distinto al habitual. Casi todo lo que se ha escrito sobre los 47 días habla de páginas web, y en las webs esto está resuelto desde hace años y se renueva solo. Los certificados que dan guerra están en otra parte del armario: el portal de administración del cortafuegos, la pasarela de VPN por la que entra la gente de fuera, el RADIUS que firma el EAP-TLS de la wifi corporativa, el balanceador. Ésos los renueva una persona, a mano, con un recordatorio en el calendario.

Las cuatro fechas, puestas en fila

El calendario lo fijó el CA/Browser Forum —el organismo donde las autoridades de certificación y los fabricantes de navegadores acuerdan las reglas de la confianza pública— con la papeleta SC-081v3, aprobada el 11 de abril de 2025. Dos columnas, no una: cuánto puede durar el certificado y cuánto puede reutilizarse la validación del dominio.

El 47 es una suma, y conviene conocerla porque explica el diseño: 31 días (un mes de los largos) más 15 (medio mes de los cortos) más 1 de margen. Está calculado para que quepa una renovación mensual con sitio para que un intento falle y se repita. El 200 se construye igual con seis meses: 184 más 15 más 1. La votación fue 25 autoridades a favor, ninguna en contra, cinco abstenciones; y los cuatro consumidores de certificados —Apple, Google, Microsoft y Mozilla— a favor. Esto no se negocia con tu proveedor, porque tu proveedor también votó a favor o se abstuvo.

2029 no es tu fecha. El 15 de marzo de 2027 tampoco, exactamente

Faltan 165 días para que el techo baje a 100. Y hay un detalle que cambia cómo hay que planificarlo: los Baseline Requirements están redactados por fecha de emisión, de modo que los escalones no son retroactivos. Cada uno se aplica a los certificados emitidos a partir de su fecha; los anteriores conservan su duración hasta que caducan. Un certificado emitido el 14 de marzo de 2027 nace con 200 días legítimos y llega vivo hasta el 30 de septiembre de ese año.

Suena a buena noticia. Es lo contrario. Si el 15 de marzo de 2027 todo se rompiera a la vez, tendrías una fecha en el calendario y un comité decidiendo qué hacer antes de ella. Lo que va a pasar es que la presión entra de forma escalonada y sin un día señalado: cada certificado cambia de régimen cuando le toca renovarse, repartido a lo largo de 2027, y cada uno es individualmente tan pequeño que no justifica una reunión. Luego los cambios sin fecha se quedan sin dueño, y en marzo de 2027 no habrá nada en el calendario de nadie.

La cuenta, con los supuestos encima de la mesa

Pongamos un parque modesto y declaremos el supuesto: 14 certificados públicos. No es una cifra de ningún cliente, es un número de ejemplo, y en una empresa de 40 personas con dos sedes se alcanza sin esfuerzo entre web corporativa, correo, portal de clientes, dos proxys inversos, la pasarela de VPN, el portal del cortafuegos, el RADIUS, el entorno de pruebas y algún aparato más. Dividiendo 365 entre cada duración:

Y eso suponiendo que renuevas el último día, lo cual nadie hace: los clientes automáticos renuevan con antelación para tener margen si falla, así que la cifra real es más alta. Lo que interesa de la cuenta es dónde se rompe el modelo. Trece al año se llevan con un recordatorio. Cincuenta y una, no — y no porque sean muchas horas, que renovar es rápido. El coste de una tarea recurrente está en acordarse, en que quien se acuerda esté ese día y en que nadie suponga que lo hizo otro.

Por qué ACME no llega al cortafuegos: porque hiciste bien la segmentación

Ésta es la parte que decide tu trabajo de los próximos tres años. La respuesta estándar es «automatiza con ACME», y es correcta: hay documentación de sobra, y los fabricantes de cortafuegos llevan años publicando la suya. La pregunta que esa documentación no se hace es dónde se puede automatizar.

Para que una autoridad te emita un certificado tiene que comprobar que controlas el dominio, y los dos métodos cómodos lo comprueban desde fuera: http-01 pide alcanzar tu puerto 80 desde Internet, tls-alpn-01 el 443. Un servidor web los pasa sin pensar, porque estar publicado es literalmente su función. Ahora dilo del portal de administración de tu cortafuegos. Ese equipo no está alcanzable desde Internet a propósito: que no lo esté es el resultado de haber hecho las cosas bien, y es de lo primero que mira cualquier revisión de red seria.

De ahí sale una conclusión incómoda y, creemos, verdadera: cuanto mejor segmentada está tu red, peor es tu situación de cara al calendario de certificados. La empresa que lo tiene todo colgado de un reverse proxy público automatiza en una tarde. La que ha separado el plano de administración, lo ha metido detrás de una VPN y no publica nada que no tenga que estar publicado, se encuentra con que su propia buena práctica es la que le impide validar por el camino fácil. Antes de que alguien lo lea al revés: la salida no es publicar el cortafuegos. Es asumir que el trabajo que tienes delante no se parece al que describen las guías.

El camino que queda, y el riesgo nuevo que trae

Para esos equipos queda dns-01: la validación se hace publicando un registro TXT en _acme-challenge de tu zona, y funciona aunque el aparato no esté alcanzable desde ningún sitio. Es el método correcto y es el que hay que usar. Y tiene una segunda mitad que las guías mencionan de pasada: significa dar a un script credenciales para escribir en tu DNS público. Has resuelto un problema de renovación creando una llave que, si se filtra, permite reescribir a dónde apunta tu dominio. En una escala de cosas que no quieres perder, un token con escritura en la zona está por encima del propio certificado.

La respuesta a eso no es precaución, es alcance, y la práctica recomendada lleva años documentada: delegar _acme-challenge con un CNAME a una zona aparte dedicada sólo a eso, y dar al renovador un token con permiso sobre esa zona y nada más. Si se filtra, alguien puede emitir certificados para ese nombre —grave, sí— pero no mover los registros MX ni el A. Lo que casi nunca se hace es la otra mitad: anotar qué token tiene permiso sobre qué zona en el mismo sitio que el resto de la verdad de la red, en vez de en la cabeza de quien lo montó. Ya escribimos sobre por qué una red necesita una única fuente de verdad y el Excel miente; un token de DNS con permisos de escritura es exactamente la clase de objeto que acaba sin dueño documentado.

Hay dos cosas más que el párrafo anterior se ha dejado fuera, y ninguna es menor. La primera: ACME no sólo necesita que te alcancen, necesita que el equipo salga hacia el servidor de la autoridad. Un plano de administración bien aislado tampoco tiene ese camino abierto, así que a la lista de trabajo se añade decidir por dónde sale ese tráfico y dejarlo escrito. La segunda: varios clientes ACME embarcados de fabricante no implementan dns-01. El de los cortafuegos de Cisco, por ejemplo, sólo documenta http-01 — y la solución que propone el propio fabricante dice mucho del tamaño del problema: el equipo abre el puerto 80 durante el reto y lo cierra cuando la emisión termina. Es decir, la respuesta de Cisco a «mi cortafuegos no está publicado» es publicarlo un rato. Quien no quiera hacer eso tiene que emitir el certificado fuera y empujárselo al aparato, y entonces el camino cómodo tampoco está disponible.

Y después de todo eso todavía queda instalarlo, que es un paso aparte y el que separa a los equipos que tienen esto resuelto de los que creen que lo tienen. En un servidor web se copia el fichero y se recarga el servicio. En un aparato de red hay que entrar por su API, subirlo, asociarlo al servicio correcto y, en algunos, reiniciar el demonio — con el detalle encantador de que eso a veces corta las sesiones de administración activas, incluida la tuya. Es un desarrollo por cada marca de equipo que tengas. Se hace una vez y queda hecho, pero hay que hacerlo.

Media lista no tendría que estar en la cadena pública

Y aquí va la parte contraria a lo que se escribe estos meses. Todo este calendario aplica a los certificados de confianza pública: los que un navegador cualquiera acepta sin que nadie le haya enseñado nada. El portal de administración interno de un cortafuegos, que abren cuatro personas desde una red de gestión, no necesita eso. Una CA propia no tiene techo de 47 días, no lo ha tenido nunca y no va a tenerlo, porque las reglas del CA/Browser Forum no la alcanzan.

Así que para una parte del inventario la respuesta correcta no es «automatiza más rápido», es sacarlo del reloj: menos certificados sometidos al calendario y los que queden, automatizados de verdad. Dicho con la pega por delante, porque si no esto parece una receta gratis: una CA propia no es gratis. Te conviertes en responsable de distribuir y rotar la raíz en todos los equipos que tienen que confiar en ella, y eso es un trabajo con su propia forma de fallar el día que un portátil nuevo no la tiene. La regla que usamos para decidir es sencilla: si lo abre un navegador que no controlas —un cliente, un proveedor, un móvil de alguien—, confianza pública y ACME. Si lo abre sólo gente tuya desde equipos tuyos, CA propia y te quitas el reloj de encima.

Lo que no se puede esquivar: la validación cae a 10 días

La columna de la derecha de la tabla conviene leerla con cuidado porque se malinterpreta fácil. El plazo de reutilización no obliga a revalidar cada 10 días: dice que la validación con la que emites no puede tener más de 10 días de antigüedad. Las validaciones al año siguen siendo tantas como emisiones —con certificados de 47 días, unas ocho por nombre—, así que el número no es el problema.

Lo que muere es otra cosa, y es más sutil: el patrón de validar una vez y luego emitir durante meses sin volver a tocar la validación. Hoy, con 200 días de reutilización, puedes validar en marzo y emitir en septiembre —al añadir un nombre, al rotar una clave, al reponer un certificado que alguien borró— sin que el camino de validación tenga que estar operativo ese día. Desde 2029 ya no: toda emisión, incluida la de emergencia a las dos de la madrugada, exige una validación de menos de 10 días. Lo que cambia de naturaleza es el camino de validación, que pasa de ser algo que montaste una vez a una dependencia de producción que tiene que funcionar el día malo. Si el registro TXT se publica a mano, ese día no hay certificado.

Hay una pieza del estándar que apunta en la misma dirección y conviene conocer. El IETF publicó en junio de 2025 el RFC 9773, la extensión ACME Renewal Information: el servidor de la autoridad le indica al cliente cuándo le conviene renovar, en lugar de que cada cliente lo decida por su cuenta con un porcentaje fijo. Sirve para repartir la carga, y también para que una autoridad que tiene que revocar en masa pueda pedir renovación anticipada a toda su base a la vez. Es un detalle de ingeniería, pero dice hacia dónde va esto: el cliente deja de llevar el calendario.

El fallo más predecible de toda la informática

Nosotros repetimos mucho una idea: el fallo es inevitable, la avería es una decisión de diseño. Un certificado que caduca es el caso extremo de eso, porque aquí el fallo no es ni siquiera inevitable: está programado. La fecha exacta viene escrita dentro del propio certificado, en un campo legible por máquina, meses antes, y cualquiera la puede leer con una línea de openssl desde el otro lado de Internet. No existe en toda la informática un fallo mejor anunciado.

Y tumba empresas todos los meses. Eso no es un problema de certificados, es un diagnóstico: si tu organización no gestiona bien un fallo cuyo instante exacto está publicado de antemano, la conversación sobre los fallos imprevisibles llega pronto. El mecanismo es el mismo que contábamos con la redundancia que supone que el repuesto llega mañana: lo que falla no es el componente, es el supuesto que nadie escribió. Aquí el supuesto es «alguien se acordará».

Dicho esto, la alerta de caducidad tiene una trampa que vale la pena nombrar: con 47 días, un aviso «a 30 días» se dispara antes de que el cliente automático haya intentado renovar siquiera, y lo que entrena a tu equipo es a ignorarla. Si vas a medir esto, mide lo que importa —que la renovación automática ocurrió— y no el calendario. Es exactamente el problema de la fatiga de alertas y de la monitorización que sí avisa, con los umbrales heredados de cuando los certificados duraban un año.

Cuatro columnas, no veinte pasos

Lo único que hace falta antes de marzo no es un proyecto. Es una tabla con los certificados públicos que tienes y cuatro columnas, porque las cuatro juntas deciden solas qué hay que hacer con cada línea:

La tabla se llena en una mañana y no hay que comprar nada para hacerla. Lo incómodo llega al terminar, cuando normalmente sobran líneas en la columna 2 que no tenían que estar en la cadena pública, y hay dos o tres en la columna 3 que dicen el nombre de alguien que está de vacaciones en agosto.

Los límites de lo que acabamos de decir

El 1 de octubre no es una fecha del calendario oficial: es el resultado de sumar 200 días al 15 de marzo de 2026, y sólo afecta a quien emitió ese día con la duración máxima. Si emitiste en abril, tu fecha es otra; la cuenta es la misma y la hace tu openssl, no este post. Las 14 líneas del ejemplo son un supuesto declarado, no un dato de nadie. Y el calendario de SC-081v3 es lo que estaba publicado el 1 de octubre de 2026: el CA/Browser Forum vota de forma continua y lo que manda es el texto vigente de los Baseline Requirements, no un artículo.

Tampoco estamos en contra del cambio, que es lo que suele esperarse de quien escribe esto desde el lado de quien opera. Los certificados cortos son buenos: una clave comprometida deja de servir en semanas en vez de en trece meses, y la revocación nunca ha funcionado bien en la práctica, así que acortar la vida es la única palanca que de verdad funciona. Lo que criticamos no es el calendario: es que se cuente como si el único sitio donde vive un certificado fuese un servidor web.

Y el conflicto de interés, por delante: operar la red de alguien y llevar ese inventario es trabajo que facturamos. Si en tu empresa esa tabla ya existe, está fechada y ninguna línea de la columna 3 dice el nombre de una persona, no nos necesitas para esto.

Fuentes (verificadas el 1 de octubre de 2026): la papeleta, su resultado (25 autoridades a favor, 0 en contra, 5 abstenciones; Apple, Google, Microsoft y Mozilla a favor) y el alcance del cambio — Ballot SC081v3 del CA/Browser Forum; el calendario completo de duración (398 / 200 / 100 / 47) y de reutilización de la validación (398 / 200 / 100 / 10) con sus fechas, la descomposición del 47 como 31 + 15 + 1 y la del 200 como 184 + 15 + 1 — DigiCert, autoridad de certificación y participante en la votación; que los escalones están redactados por fecha de emisión (y por tanto no son retroactivos) — el texto vigente de los TLS Baseline Requirements, §6.3.2 (validez) y §4.2.1 (reutilización de datos de validación); que el primer lote de 200 días vence a principios de octubre de 2026 — Sectigo; que el cliente ACME de los cortafuegos de Cisco sólo valida por http-01 y abre el puerto 80 durante el reto — documentación de Cisco Secure Firewall Management Center; la extensión que permite a la autoridad indicar cuándo renovar — RFC 9773, ACME Renewal Information (IETF, junio de 2025). Los métodos de validación http-01, tls-alpn-01 y dns-01 y sus requisitos de alcanzabilidad son los del protocolo ACME; la delegación de _acme-challenge por CNAME y el criterio de confianza pública frente a CA propia son nuestra práctica, no una recomendación del Forum.