Hva som skjer når du bytter ut en VPN-sertifiseringsinstans

Å bytte ut en VPN-sertifiseringsinstans er ikke en filutbytting. I det øyeblikket den nye CA-en signerer sitt første sertifikat, må enhver validator som fortsatt bare stoler på den gamle ta en beslutning, og verter som aldri mottar det nye ankeret, fortsetter å avvise gode parter. Jeg har sett det gå galt begge veier: gatewayen lærte den nye CA-en og klientene gjorde det ikke, så nye tilkoblinger feilet, mens tunneler som allerede var oppe ble stående og fikk avbruddet til å se ut som et rutingsproblem. Her er hva som endres, i den rekkefølgen feilene dukker opp.

Én utbytting, to atskilte endringer

En sertifiseringsinstans er et navn, en offentlig nøkkel og den private nøkkelen som signerer. Validatorer stoler aldri på «CA-en» i abstrakt forstand. De stoler på ett bestemt sertifikat som allerede ligger i et tillitslager, og de godtar en utsteder bare hvis en kjede av signaturer når frem til den lagrede kopien. Å bytte ut CA-en endrer derfor to ting som feiler uavhengig av hverandre: hvilke ankere som godtas, og hvilke partidentiteter som ble utstedt under dem.

De fleste VPN-installasjoner validerer i begge retninger. Klienten autentiserer gatewayens sertifikat, og gatewayen autentiserer klientens. En overgang som bare oppdaterer klientpakken, lar serveren avvise enhver klient som fortsatt presenterer en identitet fra den gamle CA-en, og det motsatte er like vanlig. Kartlegg først håndhevelsespunktene: klientenes tillitslagre, gatewayens ca-fil, enhver TLS-avsluttende proxy foran den, og sonden som sjekker endepunktet utenfra.

Hva en validator sjekker, i rekkefølge

Stivalidering klatrer fra partens sertifikat gjennom eventuelle mellomnivåer til den når et klarert anker. Ved hvert steg verifiserer den signaturen, kontrollerer at hvert sertifikat er innenfor sin gyldighetsperiode, og bekrefter at grunnleggende begrensninger og nøkkelbruk tillater utstederen å signere. Først da ser applikasjonen på bladsertifikatet: subjektets alternative navn må dekke navnet som ble ringt, og den utvidede nøkkelbruken må tillate server- eller klientautentisering.

For å gjenta den gjennomgangen offline, pek -CAfile mot nøyaktig den pakken du skal rulle ut, ikke mot systemlageret. Ellers tester du verten, ikke endringen:

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 kommandoen virker bare mot en enkel TLS-lytter som gatewayens HTTPS-administrasjonsside; OpenVPNs kontrollkanal kommer før TLS, så s_client kan ikke inspisere tunnelens håndtrykk.

Stioppbyggingsreglene bak disse feilene står i RFC 5280 seksjon 6. De forklarer feilene som ellers virker vilkårlige: et utløpt mellomnivå som ingen husket, et sertifikat der nøkkelbruken forbyr signering, eller en navnebegrensning som utelukker verten du tester.

Hvorfor den gamle tunnelen fortsetter å virke

TLS og OpenVPN holder begge en etablert sesjon i live etter at håndtrykket er ferdig. Ingenting revaliderer partens sertifikat per pakke, så en klient som koblet til før endringen, fortsetter å slippe gjennom trafikk til den forhandler på nytt, kobler til på nytt eller tunnelen faller. Akkurat dette gapet gjør at en CA-utbytting kan se fin ut i en time og deretter feile på det verste tidspunktet: en bærbar PC våkner fra dvale, en NAT-tilordning utløper, en gateway starter på nytt.

Sesjonsgjenopptakelse strekker illusjonen enda lenger. En TLS-sesjonsbillett lar klienten komme tilbake uten å sende sertifikater på nytt, og gjenopptakelsen hopper over stivalidering fordi det første håndtrykket allerede gjorde det. Så den ærlige testen er et fullt håndtrykk i en ny prosess. Start klienten på nytt i stedet for å koble tunnelen til på nytt, og vurder å slå av billetter på en testprofil, slik at gjenopptakelsesveien ikke kan skjule en brutt kjede.

Hold det statiske nøkkellaget atskilt fra dette. tls-auth legger til en HMAC på kontrollkanalen, tls-crypt krypterer og autentiserer den, og ingen av dem bærer sertifikatmateriale, så rotasjon av en av dem er en egen endring med sin egen feilmodus. Installasjoner som blander de to, ender med en klient der den statiske nøkkelen er i orden, sertifikatet er utdatert og feilmeldingen ikke nevner noen av dem.

Fellen med å gjenbruke subjektnavnet

Det er fristende å gjenbruke forgjengerens distinguerte navn slik at ingenting lenger ned må endres. Det holder utstederlinjen stabil i grensesnittet og ødelegger det ene signalet du trenger. To sertifikater med identiske subjekter og ulike nøkler kan ikke skilles på navn, så en pakke med begge ankrene gir validatoren to kandidater og ingen regel for å velge.

Stioppbyggingen kan da velge den gale, rapportere «kan ikke hente lokalt utstedersertifikat» mens det riktige ankeret er til stede, eller lykkes på én vert og feile på en annen med samme pakke, fordi kandidatrekkefølgen var forskjellig. Hvis navnet må gjenbrukes, hold begge ankrene i separate filer i overgangen og last dem eksplisitt, og slå dem sammen først når hver part presenterer den nye utstederen. Ellers gi erstatningen et eget vanlig navn — et generasjons- eller datosuffiks er nok — slik at logger og feiltekster sier hvilken myndighet en feilende part ble utstedt under.

En overgang som ikke tar ned nettverket

For en planlagt utbytting, godta begge ankrene i et begrenset vindu i stedet for å bytte i ett steg. Utsted den nye CA-en og mellomnivåene, legg det nye ankeret i hver validators pakke ved siden av det gamle, og begynn først deretter å utstede partssertifikater fra den. Parter med gamle identiteter valideres mot det gamle ankeret; nye virker mot det nye.

Gjort i den rekkefølgen er hvert steg reversibelt. Feilen du unngår, er den samtidige byttingen, der en klient som gikk glipp av pakkeoppdateringen møter en gateway som allerede har pensjonert det gamle ankeret, håndtrykket dør, og ingen logg sier hvilken side som er utdatert.

Pensjoner i motsatt retning. Utsted på nytt hver identitet som må overleve, bekreft at hver av dem presenterer den nye kjeden, og fjern deretter det gamle ankeret fra pakkene. Ta den gamle CA-ens private nøkkel ut av drift, for en utsteder som fortsatt kan signere betyr at overgangen ikke er ferdig. Ta vare på sertifikatene og utstedelsesregistrene for revisjon. En tapt utsteder gjenopprettes til samme tillit; en eksponering krever nye identiteter og ingen tilbakevending til det gamle ankeret.

Verifiser resultatet, ikke fillisten

En tillitsfil i forventet katalog beviser lite. Applikasjonen kan lese en annen sti, et annet format eller en kopi inne i en pakke som en oppgradering erstatter. Kontroller atferden i begge ender, ikke at en fil finnes.

Bekreft at en ny tilkobling med en ny identitet lykkes, og bekreft deretter at en identitet utstedt av den pensjonerte CA-en avvises. Den andre testen er den folk hopper over, og den eneste som viser at den gamle myndigheten ikke lenger gir tilgang. Der installasjonen er avhengig av CRL eller OCSP, kontroller at distribusjonspunktene i de nye sertifikatene løses opp og at svareren er nåbar fra partene som spør den.

Avslutt med en klient som aldri har vært tilkoblet: slett profiltilstanden, koble til og les den forhandlede kjeden. En part som gjenopptar en bufret sesjon, vil muntert rapportere at migreringen virket, uten å ha validert noe som helst.