El certificat que l'ACME no renova és el que et deixa sense VPN

Fes la suma: 15 de març del 2026, el dia en què va entrar en vigor el sostre de 200 dies per als certificats TLS públics, més 200 dies. Surt l'1 d'octubre del 2026. Avui. Els primers certificats emesos amb la regla nova comencen a vèncer aquesta setmana, i amb ells s'acaba la part del calendari en què això era un assumpte del 2029.

Som operador amb xarxa pròpia: portem BGP, trànsit i peering, túnels entre seus amb WireGuard, SD-WAN multiseu i la documentació de tot això a NetBox. I per això la conversa sobre certificats curts ens interessa des d'un angle diferent de l'habitual. Gairebé tot el que s'ha escrit sobre els 47 dies parla de pàgines web, i a les webs això està resolt des de fa anys i es renova sol. Els certificats que donen guerra són en una altra part de l'armari: el portal d'administració del tallafocs, la passarel·la de VPN per on entra la gent de fora, el RADIUS que signa l'EAP-TLS de la wifi corporativa, el balancejador. Aquests els renova una persona, a mà, amb un recordatori al calendari.

Les quatre dates, posades en fila

El calendari el va fixar el CA/Browser Forum —l'organisme on les autoritats de certificació i els fabricants de navegadors acorden les regles de la confiança pública— amb la papereta SC-081v3, aprovada l'11 d'abril del 2025. Dues columnes, no una: quant pot durar el certificat i quant pot reutilitzar-se la validació del domini.

El 47 és una suma, i convé conèixer-la perquè explica el disseny: 31 dies (un mes dels llargs) més 15 (mig mes dels curts) més 1 de marge. Està calculat perquè hi càpiga una renovació mensual amb lloc perquè un intent falli i es repeteixi. El 200 es construeix igual amb sis mesos: 184 més 15 més 1. La votació va ser 25 autoritats a favor, cap en contra, cinc abstencions; i els quatre consumidors de certificats —Apple, Google, Microsoft i Mozilla— a favor. Això no es negocia amb el teu proveïdor, perquè el teu proveïdor també va votar a favor o es va abstenir.

2029 no és la teva data. El 15 de març del 2027 tampoc, exactament

Falten 165 dies perquè el sostre baixi a 100. I hi ha un detall que canvia com cal planificar-ho: els Baseline Requirements estan redactats per data d'emissió, de manera que els escalons no són retroactius. Cadascun s'aplica als certificats emesos a partir de la seva data; els anteriors conserven la seva durada fins que caduquen. Un certificat emès el 14 de març del 2027 neix amb 200 dies legítims i arriba viu fins al 30 de setembre d'aquell any.

Sona a bona notícia. És el contrari. Si el 15 de març del 2027 tot es trencés alhora, tindries una data al calendari i un comitè decidint què fer abans d'ella. El que passarà és que la pressió entra de manera esglaonada i sense un dia assenyalat: cada certificat canvia de règim quan li toca renovar-se, repartit al llarg del 2027, i cadascun és individualment tan petit que no justifica una reunió. Després els canvis sense data es queden sense amo, i el març del 2027 no hi haurà res al calendari de ningú.

El càlcul, amb els supòsits sobre la taula

Posem un parc modest i declarem el supòsit: 14 certificats públics. No és una xifra de cap client, és un número d'exemple, i en una empresa de 40 persones amb dues seus s'assoleix sense esforç entre web corporativa, correu, portal de clients, dos proxys inversos, la passarel·la de VPN, el portal del tallafocs, el RADIUS, l'entorn de proves i algun aparell més. Dividint 365 entre cada durada:

I això suposant que renoves l'últim dia, cosa que ningú fa: els clients automàtics renoven amb antelació per tenir marge si falla, així que la xifra real és més alta. L'important del càlcul no és el número final, és on es trenca el model. Tretze l'any es porten amb un recordatori. Cinquanta-una, no. No perquè siguin moltes hores —renovar és ràpid— sinó perquè el cost d'una tasca recurrent no és fer-la: és recordar-se'n, que qui se'n recorda hi sigui aquell dia, i que ningú no suposi que ho va fer un altre.

Per què l'ACME no arriba al tallafocs: perquè vas fer bé la segmentació

Aquesta és la part que decideix la teva feina dels pròxims tres anys. La resposta estàndard és «automatitza amb ACME», i és correcta: hi ha documentació de sobres, i els fabricants de tallafocs fa anys que publiquen la seva. La pregunta que aquella documentació no es fa és on es pot automatitzar.

Perquè una autoritat t'emeti un certificat ha de comprovar que controles el domini, i els dos mètodes còmodes ho comproven des de fora: http-01 demana arribar al teu port 80 des d'Internet, tls-alpn-01 el 443. Un servidor web els passa sense pensar, perquè estar publicat és literalment la seva funció. Ara digues-ho del portal d'administració del teu tallafocs. Aquell equip no és accessible des d'Internet a propòsit: que no ho sigui és el resultat d'haver fet les coses bé, i és de les primeres coses que mira qualsevol revisió de xarxa seriosa.

D'aquí surt una conclusió incòmoda i, creiem, verdadera: com millor segmentada està la teva xarxa, pitjor és la teva situació de cara al calendari de certificats. L'empresa que ho té tot penjat d'un reverse proxy públic automatitza en una tarda. La que ha separat el pla d'administració, l'ha posat darrere d'una VPN i no publica res que no hagi d'estar publicat, es troba que la seva pròpia bona pràctica és la que li impedeix validar pel camí fàcil. Abans que algú ho llegeixi al revés: la sortida no és publicar el tallafocs. És assumir que la feina que tens al davant no s'assembla a la que descriuen les guies.

El camí que queda, i el risc nou que porta

Per a aquests equips queda dns-01: la validació es fa publicant un registre TXT a _acme-challenge de la teva zona, i funciona encara que l'aparell no sigui accessible des d'enlloc. És el mètode correcte i és el que cal fer servir. I té una segona meitat que les guies esmenten de passada: significa donar a un script credencials per escriure al teu DNS públic. Has resolt un problema de renovació creant una clau que, si es filtra, permet reescriure on apunta el teu domini. En una escala de coses que no vols perdre, un token amb escriptura a la zona està per damunt del certificat mateix.

La resposta a això no és precaució, és abast, i la pràctica recomanada fa anys que està documentada: delegar _acme-challenge amb un CNAME a una zona a part dedicada només a això, i donar al renovador un token amb permís sobre aquesta zona i res més. Si es filtra, algú pot emetre certificats per a aquest nom —greu, sí— però no moure els registres MX ni l'A. El que gairebé mai es fa és l'altra meitat: anotar quin token té permís sobre quina zona al mateix lloc que la resta de la veritat de la xarxa, en lloc del cap de qui ho va muntar. Ja vam escriure sobre per què una xarxa necessita una única font de veritat i l'Excel menteix; un token de DNS amb permisos d'escriptura és exactament la mena d'objecte que acaba sense amo documentat.

Hi ha dues coses més que el paràgraf anterior s'ha deixat fora, i cap no és menor. La primera: l'ACME no només necessita que t'arribin, necessita que l'equip surti cap al servidor de l'autoritat. Un pla d'administració ben aïllat tampoc té aquest camí obert, així que a la llista de feina s'afegeix decidir per on surt aquest trànsit i deixar-ho escrit. La segona: diversos clients ACME encastats de fabricant no implementen dns-01. El dels tallafocs de Cisco, per exemple, només documenta http-01 — i la solució que proposa el fabricant mateix diu molt de la mida del problema: l'equip obre el port 80 durant el repte i el tanca quan l'emissió acaba. És a dir, la resposta de Cisco a «el meu tallafocs no està publicat» és publicar-lo una estona. Qui no vulgui fer això ha d'emetre el certificat fora i empènyer-l'hi a l'aparell, i aleshores el camí còmode tampoc no està disponible.

I després de tot això encara queda instal·lar-lo, que és un pas a part i el que separa els equips que tenen això resolt dels que creuen que ho tenen. En un servidor web es copia el fitxer i es recarrega el servei. En un aparell de xarxa cal entrar per la seva API, pujar-lo, associar-lo al servei correcte i, en alguns, reiniciar el dimoni — amb el detall encantador que això de vegades talla les sessions d'administració actives, inclosa la teva. És un desenvolupament per cada marca d'equip que tinguis. Es fa una vegada i queda fet, però cal fer-ho.

Mitja llista no hauria d'estar a la cadena pública

I aquí va la part contrària al que s'escriu aquests mesos. Tot aquest calendari s'aplica als certificats de confiança pública: els que un navegador qualsevol accepta sense que ningú li hagi ensenyat res. El portal d'administració intern d'un tallafocs, que obren quatre persones des d'una xarxa de gestió, no necessita això. Una CA pròpia no té sostre de 47 dies, no l'ha tingut mai i no el tindrà, perquè les regles del CA/Browser Forum no l'abasten.

Així que per a una part de l'inventari la resposta correcta no és «automatitza més ràpid», és treure-ho del rellotge: menys certificats sotmesos al calendari i els que quedin, automatitzats de debò. Dit amb la pega per davant, perquè si no això sembla una recepta gratis: una CA pròpia no és gratis. Et converteixes en responsable de distribuir i rotar l'arrel en tots els equips que han de confiar-hi, i això és una feina amb la seva pròpia manera de fallar el dia que un portàtil nou no la té. La regla que fem servir per decidir és senzilla: si ho obre un navegador que no controles —un client, un proveïdor, un mòbil d'algú—, confiança pública i ACME. Si ho obre només gent teva des d'equips teus, CA pròpia i et treus el rellotge del damunt.

El que no es pot esquivar: la validació cau a 10 dies

La columna de la dreta de la taula convé llegir-la amb cura perquè es malinterpreta fàcil. El termini de reutilització no obliga a revalidar cada 10 dies: diu que la validació amb què emets no pot tenir més de 10 dies d'antiguitat. Les validacions l'any continuen sent tantes com emissions —amb certificats de 47 dies, unes vuit per nom—, així que el número no és el problema.

El que mor és una altra cosa, i és més subtil: el patró de validar una vegada i després emetre durant mesos sense tornar a tocar la validació. Avui, amb 200 dies de reutilització, pots validar al març i emetre al setembre —en afegir un nom, en rotar una clau, en reposar un certificat que algú va esborrar— sense que el camí de validació hagi d'estar operatiu aquell dia. Des del 2029 ja no: tota emissió, inclosa la d'emergència a les dues de la matinada, exigeix una validació de menys de 10 dies. El que canvia de naturalesa és el camí de validació, que passa de ser una cosa que vas muntar una vegada a una dependència de producció que ha de funcionar el dia dolent. Si el registre TXT es publica a mà, aquell dia no hi ha certificat.

Hi ha una peça de l'estàndard que apunta en la mateixa direcció i convé conèixer. L'IETF va publicar el juny del 2025 el RFC 9773, l'extensió ACME Renewal Information: el servidor de l'autoritat indica al client quan li convé renovar, en lloc que cada client ho decideixi pel seu compte amb un percentatge fix. Serveix per repartir la càrrega, i també perquè una autoritat que ha de revocar en massa pugui demanar renovació anticipada a tota la seva base alhora. És un detall d'enginyeria, però diu cap a on va això: el client deixa de portar el calendari.

La fallada més predictible de tota la informàtica

Nosaltres repetim molt una idea: la fallada és inevitable, l'avaria és una decisió de disseny. Un certificat que caduca és el cas extrem d'això, perquè aquí la fallada no és ni tan sols inevitable: està programada. La data exacta ve escrita dins del propi certificat, en un camp llegible per màquina, mesos abans, i qualsevol la pot llegir amb una línia d'openssl des de l'altre costat d'Internet. No existeix en tota la informàtica una fallada millor anunciada.

I tomba empreses tots els mesos. Això no és un problema de certificats, és un diagnòstic: si la teva organització no gestiona bé una fallada l'instant exacte de la qual està publicat per endavant, la conversa sobre les fallades imprevisibles arriba aviat. El mecanisme és el mateix que explicàvem amb la redundància que suposa que el recanvi arriba demà: el que falla no és el component, és el supòsit que ningú va escriure. Aquí el supòsit és «algú se'n recordarà».

Dit això, l'alerta de caducitat té una trampa que val la pena anomenar: amb 47 dies, un avís «a 30 dies» es dispara abans que el client automàtic hagi intentat renovar ni tan sols, i el que entrena el teu equip és a ignorar-la. Si vas a mesurar això, mesura el que importa —que la renovació automàtica va passar— i no el calendari. És exactament el problema de la fatiga d'alertes i del monitoratge que sí avisa, amb els llindars heretats de quan els certificats duraven un any.

Quatre columnes, no vint passos

L'únic que cal abans de març no és un projecte. És una taula amb els certificats públics que tens i quatre columnes, perquè les quatre juntes decideixen soles què cal fer amb cada línia:

La taula s'omple en un matí i no cal comprar res per fer-la. L'incòmode no és omplir-la: és que en acabar normalment sobren línies a la columna 2 que no havien d'estar a la cadena pública, i n'hi ha dues o tres a la columna 3 que diuen el nom d'algú que està de vacances a l'agost.

Els límits del que acabem de dir

L'1 d'octubre no és una data del calendari oficial: és el resultat de sumar 200 dies al 15 de març del 2026, i només afecta qui va emetre aquell dia amb la durada màxima. Si vas emetre a l'abril, la teva data és una altra; el càlcul és el mateix i el fa el teu openssl, no aquest post. Les 14 línies de l'exemple són un supòsit declarat, no una dada de ningú. I el calendari de l'SC-081v3 és el que estava publicat l'1 d'octubre del 2026: el CA/Browser Forum vota de manera contínua i el que mana és el text vigent dels Baseline Requirements, no un article.

Tampoc no estem en contra del canvi, que és el que se sol esperar de qui escriu això des del costat de qui opera. Els certificats curts són bons: una clau compromesa deixa de servir en setmanes en lloc d'en tretze mesos, i la revocació no ha funcionat mai bé a la pràctica, així que escurçar la vida és l'única palanca que de debò funciona. El que critiquem no és el calendari: és que s'expliqui com si l'únic lloc on viu un certificat fos un servidor web.

I el conflicte d'interès, per davant: operar la xarxa d'algú i portar aquest inventari és feina que facturem. Si a la teva empresa aquesta taula ja existeix, està datada i cap línia de la columna 3 diu el nom d'una persona, no ens necessites per a això.

Fonts (verificades l'1 d'octubre del 2026): la papereta, el seu resultat (25 autoritats a favor, 0 en contra, 5 abstencions; Apple, Google, Microsoft i Mozilla a favor) i l'abast del canvi — Ballot SC081v3 del CA/Browser Forum; el calendari complet de durada (398 / 200 / 100 / 47) i de reutilització de la validació (398 / 200 / 100 / 10) amb les seves dates, la descomposició del 47 com 31 + 15 + 1 i la del 200 com 184 + 15 + 1 — DigiCert, autoritat de certificació i participant en la votació; que els escalons estan redactats per data d'emissió (i per tant no són retroactius) — el text vigent dels TLS Baseline Requirements, §6.3.2 (validesa) i §4.2.1 (reutilització de dades de validació); que el primer lot de 200 dies venç a principis d'octubre del 2026 — Sectigo; que el client ACME dels tallafocs de Cisco només valida per http-01 i obre el port 80 durant el repte — documentació del Cisco Secure Firewall Management Center; l'extensió que permet a l'autoritat indicar quan renovar — RFC 9773, ACME Renewal Information (IETF, juny del 2025). Els mètodes de validació http-01, tls-alpn-01 i dns-01 i els seus requisits d'accessibilitat són els del protocol ACME; la delegació de _acme-challenge per CNAME i el criteri de confiança pública enfront de CA pròpia són la nostra pràctica, no una recomanació del Forum.