Hvad sker der, når du udskifter en VPN-certifikatmyndighed

At udskifte en VPN-certifikatmyndighed er ikke en filudskiftning. I det øjeblik den nye CA signerer sit første certifikat, skal enhver validator, der stadig kun stoler på den gamle, træffe en beslutning, og værter, der aldrig modtager det nye anker, afviser fortsat gode peere. Jeg har set det gå galt begge veje: gatewayen lærte den nye CA, mens klienterne ikke gjorde, så nye forbindelser fejlede, mens tunneler, der allerede var oppe, blev oppe og fik afbrydelsen til at ligne et routingproblem. Her er, hvad der ændrer sig, i den rækkefølge fejlene viser sig.

Én udskiftning, to adskilte ændringer

En certifikatmyndighed er et navn, en offentlig nøgle og den private nøgle, der signerer. Validatorer stoler aldrig på „CA'en“ i abstrakt form. De stoler på ét bestemt certifikat, der allerede ligger i et tillidslager, og de accepterer kun en udsteder, hvis en kæde af signaturer når hen til den gemte kopi. Udskiftning af CA'en ændrer derfor to ting, der fejler uafhængigt: hvilke ankere der accepteres, og hvilke peer-identiteter der blev udstedt under dem.

De fleste VPN-installationer validerer i begge retninger. Klienten autentificerer gatewayens certifikat, og gatewayen autentificerer klientens certifikat. En overgang, der kun opdaterer klientbundtet, efterlader serveren med at afvise enhver klient, der stadig fremviser en identitet fra den gamle CA, og det omvendte er lige så almindeligt. Kortlæg først håndhævelsespunkterne: klienternes tillidslagre, gatewayens ca-fil, enhver TLS-afsluttende proxy foran den og den probe, der tjekker endepunktet udefra.

Hvad en validator kontrollerer, i rækkefølge

Stivalidering klatrer fra peer-certifikatet gennem mellemled, indtil den når et betroet anker. Ved hvert trin verificerer den signaturen, kontrollerer at hvert certifikat er inden for sin gyldighedsperiode, og bekræfter at grundlæggende begrænsninger og nøglebrug tillader udstederen at signere. Først derefter ser applikationen på bladcertifikatet: subject alternative names skal dække det navn, der blev kaldt, og nøglebrugen skal tillade server- eller klientautentificering.

For at gentage den tur offline skal du pege -CAfile på præcis det bundt, du vil udrulle, og ikke på systemlageret. Ellers tester du værten, ikke ændringen:

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

Den kommando virker kun mod en almindelig TLS-lytter som gatewayens HTTPS-administrationsside; OpenVPNs kontrolkanal kommer før TLS, så s_client kan ikke inspicere tunnelens håndtryk.

Reglerne for stiopbygning bag disse fejl står i RFC 5280 afsnit 6. De forklarer de fejl, der ellers virker vilkårlige: et udløbet mellemled, som ingen huskede, et certifikat hvis nøglebrug forbyder signering, eller en navnebegrænsning, der udelukker den vært, du tester.

Hvorfor den gamle tunnel bliver ved med at virke

TLS og OpenVPN holder begge en etableret session i live, efter håndtrykket er færdigt. Intet genvaliderer peer-certifikatet per pakke, så en klient, der blev forbundet før ændringen, fortsætter med at sende trafik, indtil den forhandler igen, genopretter forbindelsen, eller tunnelen falder. Netop det hul er grunden til, at en CA-udskiftning kan se fin ud i en time og derefter fejle på det værst tænkelige tidspunkt: en bærbar vågner fra dvale, en NAT-tilknytning udløber, en gateway genstarter.

Sessionsgenoptagelse strækker illusionen yderligere. En TLS-sessionsbillet lader klienten vende tilbage uden at gensende certifikater, og genoptagelsen springer stivalidering over, fordi det første håndtryk allerede gjorde det. Så den ærlige test er et fuldt håndtryk i en ny proces. Genstart klienten i stedet for at genoprette tunnelen, og overvej på en testprofil at deaktivere billetter, så genoptagelsesvejen ikke kan skjule en brudt kæde.

Hold det statiske nøglelag adskilt fra dette. tls-auth tilføjer en HMAC til kontrolkanalen, tls-crypt krypterer og autentificerer den, og ingen af dem bærer certifikatmateriale, så rotation af en af dem er en separat ændring med sin egen fejltilstand. Installationer, der blander de to, ender med en klient, hvis statiske nøgle er i orden, hvis certifikat er forældet, og hvis fejlmeddelelse ikke nævner nogen af dem.

Fælden ved at genbruge subject-navnet

Det er fristende at genbruge forgængerens distinguished name, så intet længere nede skal ændres. Det holder udstederlinjen stabil i brugergrænsefladen og ødelægger det ene signal, du har brug for. To certifikater med identiske subjects og forskellige nøgler kan ikke skelnes på navn, så et bundt med begge ankere giver validatoren to kandidater og ingen regel for at vælge.

Så kan stiopbygningen vælge den forkerte, rapportere „kan ikke hente lokalt udsteder-certifikat“, mens det korrekte anker er til stede, eller lykkes på én vært og fejle på en anden med samme bundt, fordi kandidatrekkefølgen var forskellig. Hvis navnet skal genbruges, skal du holde begge ankere i separate filer i overgangsperioden og indlæse dem eksplicit, og først sammenlægge dem, når hver peer fremviser den nye udsteder. Ellers giv erstatningen et distinkt fællesnavn — et generations- eller datostempel er nok — så logfiler og fejltekster siger, under hvilken myndighed en fejlende peer blev udstedt.

En overgang, der ikke tager netværket ned

Til en planlagt udskiftning skal du acceptere begge ankere i et afgrænset vindue i stedet for at skifte på én gang. Udsted den nye CA og dens mellemled, læg det nye anker i hver validators bundt ved siden af det gamle, og begynd først derefter at udstede peer-certifikater fra den. Peers med gamle identiteter validerer mod det gamle anker; nye virker mod det nye anker.

Gjort i den rækkefølge er hvert skridt reversibelt. Den fejl, du undgår, er det samtidige skift, hvor en klient, der gik glip af bundtopdateringen, møder en gateway, der allerede har pensioneret det gamle anker, håndtrykket dør, og ingen af logfilerne siger, hvilken side der er forældet.

Pensioner i den modsatte retning. Genudsted hver identitet, der skal overleve, bekræft at hver især fremviser den nye kæde, og fjern derefter det gamle anker fra bundterne. Tag den gamle CAs private nøgle ud af drift, for en udsteder, der stadig kan signere, betyder, at overgangen ikke er færdig. Gem certifikater og udstedelsesregistre til revision. En tabt udsteder gendannes til samme tillid; en eksponering kræver nye identiteter og ingen tilbagevenden til det gamle anker.

Bekræft resultatet, ikke fillisten

En tillidsfil i det forventede bibliotek beviser lille. Applikationen kan læse en anden sti, et andet format eller en kopi inde i en pakke, som en opgradering erstatter. Kontroller adfærden i begge ender, ikke at der findes en fil.

Bekræft, at en ny forbindelse med en ny identitet lykkes, og bekræft derefter, at en identitet udstedt af den pensionerede CA afvises. Den anden test er den, folk springer over, og den eneste, der viser, at den gamle myndighed ikke længere giver adgang. Hvor installationen er afhængig af CRL eller OCSP, skal du kontrollere, at distributionspunkterne i de nye certifikater kan slås op, og at svareren kan nås fra de peers, der spørger den.

Slut med en klient, der aldrig har været forbundet: ryd dens profiltilstand, opret forbindelse, og læs den forhandlede kæde. En peer, der genoptager en cachet session, vil muntert rapportere, at migreringen virkede, uden at have valideret noget som helst.