Què passa quan substituïu una autoritat de certificació VPN

Substituir una autoritat de certificació VPN no és canviar un fitxer. En el moment que la nova CA signa el seu primer certificat, cada validador que encara només confia en l'antiga ha de prendre una decisió, i els hosts que no reben mai l'àncora nova continuen rebutjant parells bons. Ho he vist fallar en les dues direccions: la passarel·la va aprendre la nova CA i els clients no, així que les connexions noves fallaven, mentre que els túnels ja aixecats es mantenien i feien que l'avaria semblés un problema d'encaminament. Aquí teniu què canvia, en l'ordre en què apareixen les fallades.

Una substitució, dos canvis separats

Una autoritat de certificació és un nom, una clau pública i la clau privada que signa. Els validadors no confien en «la CA» en abstracte. Confien en un certificat concret que ja és en un magatzem de confiança, i accepten un emissor només si una cadena de signatures arriba a aquella còpia desada. Per tant, substituir la CA canvia dues coses que fallen de manera independent: quines àncores s'accepten i quines identitats de parell s'han emès sota elles.

La majoria de desplegaments VPN validen en les dues direccions. El client autentica el certificat de la passarel·la, i la passarel·la autentica el certificat del client. Una rotació que només refresca el paquet del client deixa el servidor rebutjant cada client que encara presenta una identitat de la CA antiga, i el cas invers és igual de freqüent. Inventarieu primer els punts d'aplicació: magatzems de confiança dels clients, el fitxer ca de la passarel·la, qualsevol proxy que acabi TLS al davant i la sonda que comprova el punt final des de fora.

Què comprova un validador, per ordre

La validació de camí puja del certificat del parell pels intermediaris fins a arribar a una àncora de confiança. A cada pas verifica la signatura, comprova que cada certificat és dins la seva finestra de validesa i confirma que les restriccions bàsiques i l'ús de clau permeten a l'emissor signar. Només llavors l'aplicació mira el certificat fulla: els noms alternatius del subjecte han de cobrir el nom amb què s'ha marcat, i l'ús de clau estès ha de permetre l'autenticació de servidor o de client.

Per repetir aquest recorregut sense xarxa, apunteu -CAfile al paquet exacte que desplegareu i no al magatzem del sistema. Si no, esteu provant l'amfitrió, no el canvi:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Aquesta ordre només funciona contra un oient TLS pla com la pàgina d'administració HTTPS de la passarel·la; el canal de control d'OpenVPN precedeix TLS, així que s_client no pot inspeccionar l'apretada de mans del túnel.

Les regles de construcció de camí que hi ha darrere d'aquests errors són a RFC 5280 secció 6. Expliquen les fallades que d'altra manera semblen arbitràries: un intermediari caducat que ningú recordava, un certificat l'ús de clau del qual prohibeix signar, o una restricció de nom que exclou l'amfitrió que proveu.

Per què el túnel antic continua funcionant

TLS i OpenVPN mantenen viva una sessió establerta després que acabi l'apretada de mans. Res no revalida el certificat del parell per paquet, així que un client que es va connectar abans del canvi continua passant trànsit fins que renegocia, es reconnecta o el túnel cau. Aquest buit és la raó que una substitució de CA sembli bé durant una hora i després falli en el pitjor moment: un portàtil es desperta, un mapatge NAT caduca, una passarel·la es reinicia.

La represa de sessió allarga la il·lusió encara més. Un tiquet de sessió TLS permet al client tornar sense reenviar certificats, i la represa s'estalvia la validació de camí perquè la primera apretada de mans ja la va fer. Per tant, la prova honesta és una apretada de mans completa en un procés nou. Reinicieu el client en lloc de reconnectar el túnel, i en un perfil de prova considereu desactivar els tiquets perquè el camí de represa no pugui amagar una cadena trencada.

Manteniu la capa de clau estàtica separada d'això. tls-auth afegeix un HMAC al canal de control, tls-crypt el xifra i l'autentica, i cap dels dos no porta material de certificat, així que rotar qualsevol dels dos és un canvi separat amb el seu propi mode de fallada. Els desplegaments que confonen els dos acaben amb un client la clau estàtica del qual és correcta, el certificat del qual és obsolet i el missatge d'error del qual no esmenta cap dels dos.

El parany de reutilitzar el nom del subjecte

És temptador reutilitzar el nom distingit del predecessor perquè res de més avall no s'hagi de canviar. Això manté estable la línia de l'emissor a la interfície i destrueix l'únic senyal que necessiteu. Dos certificats amb subjectes idèntics i claus diferents no es poden distingir pel nom, així que un paquet amb les dues àncores dona al validador dos candidats i cap regla per triar.

Llavors la construcció de camí pot triar el dolent, informar «no es pot obtenir el certificat de l'emissor local» mentre l'àncora correcta hi és, o tenir èxit en un amfitrió i fallar en un altre amb el mateix paquet, perquè l'ordre dels candidats era diferent. Si el nom s'ha de reutilitzar, manteniu les dues àncores en fitxers separats durant la transició i carregueu-les explícitament, i fusioneu-les només quan cada parell presenti el nou emissor. Si no, doneu a la substitució un nom comú diferent — un sufix de generació o de data és suficient — perquè els registres i els textos d'error diguin sota quina autoritat es va emetre el parell que falla.

Una rotació que no tomba la xarxa

Per a una substitució planificada, accepteu les dues àncores durant una finestra limitada en lloc de canviar en un sol pas. Emetiu la nova CA i els seus intermediaris, poseu l'àncora nova al paquet de cada validador al costat de l'antiga, i només llavors comenceu a emetre certificats de parell a partir d'ella. Els parells amb identitats antigues validen contra l'àncora antiga; els nous funcionen contra la nova.

Fet en aquest ordre, cada pas és reversible. La fallada que eviteu és el canvi simultani, on un client que s'ha perdut l'actualització del paquet troba una passarel·la que ja ha retirat l'àncora antiga, l'apretada de mans mor i cap dels dos registres diu quin costat és obsolet.

Retireu en la direcció oposada. Reemetiu cada identitat que hagi de sobreviure, confirmeu que cadascuna presenta la cadena nova, i després traieu l'àncora antiga dels paquets. Traieu la clau privada de la CA antiga de servei, perquè un emissor que encara pot signar vol dir que la rotació no s'ha acabat. Guardeu els certificats i els registres d'emissió per a auditoria. Un emissor perdut es restaura a la mateixa confiança; una exposició requereix identitats noves i cap retorn a l'àncora antiga.

Verifiqueu el resultat, no la llista de fitxers

Un fitxer de confiança al directori esperat demostra poc. L'aplicació pot llegir un camí diferent, un format diferent o una còpia dins d'un paquet que una actualització substitueix. Comproveu el comportament als dos extrems, no que existeixi un fitxer.

Confirmeu que una connexió nova amb una identitat nova té èxit, i després confirmeu que es rebutja una identitat emesa per la CA retirada. Aquesta segona prova és la que la gent s'estalvia, i l'única que mostra que l'autoritat antiga ja no dona accés. On el desplegament depèn de CRL o OCSP, comproveu que els punts de distribució dels certificats nous es resolguin i que els parells que consulten el servidor de respostes hi puguin arribar.

Acabeu amb un client que no s'hagi connectat mai: esborreu l'estat del seu perfil, connecteu-lo i llegiu la cadena negociada. Un parell que reprèn una sessió en memòria cau informarà alegrement que la migració ha funcionat quan no ha validat res de res.