Kva som skjer når du byter ut ein VPN-sertifiseringsinstans

Å bytte ut ein VPN-sertifiseringsinstans er ikkje eit filbytte. I det augeblikket den nye CA-en signerer sitt første sertifikat, må kvar validator som framleis berre stolar på den gamle ta ei avgjerd, og vertar som aldri får det nye ankeret, held fram med å avvise gode partar. Eg har sett det gå gale begge vegar: gatewayen lærte den nye CA-en og klientane gjorde det ikkje, så nye tilkoplingar feila, medan tunnelar som alt var oppe vart ståande og fekk avbrotet til å sjå ut som eit ruteproblem. Her er kva som endrar seg, i den rekkjefølgja feila dukkar opp.

Eitt utbytte, to åtskilde endringar

Ein sertifiseringsinstans er eit namn, ein offentleg nøkkel og den private nøkkelen som signerer. Validatorar stolar aldri på «CA-en» i abstrakt forstand. Dei stolar på eitt bestemt sertifikat som alt ligg i eit tillitslager, og dei godtek ein utstadar berre om ei kjede av signaturar når fram til den lagra kopien. Å bytte ut CA-en endrar derfor to ting som feilar uavhengig av kvarandre: kva anker som vert godtekne, og kva partidentitetar som vart utstade under dei.

Dei fleste VPN-installasjonar validerer i begge retningar. Klienten autentiserer sertifikatet til gatewayen, og gatewayen autentiserer sertifikatet til klienten. Ein overgang som berre oppdaterer klientpakka, lèt tenaren avvise kvar klient som framleis presenterer ein identitet frå den gamle CA-en, og det motsette er like vanleg. Kartlegg først handhevingspunkta: tillitslagera til klientane, ca-fila til gatewayen, kvar TLS-avsluttande proxy framfor han, og sonden som sjekkar endepunktet utanfrå.

Kva ein validator sjekkar, i rekkjefølgje

Stivalidering klatrar frå sertifikatet til parten gjennom eventuelle mellomledd til ho når eit klarert anker. Ved kvart steg verifiserer ho signaturen, kontrollerer at kvart sertifikat er innanfor si gyldigheitsperiode, og stadfester at grunnleggjande avgrensingar og nøkkelbruk lèt utstadaren signere. Først då ser applikasjonen på bladsertifikatet: dei alternative namna til subjektet må dekkje namnet som vart ringt, og den utvida nøkkelbruken må tillate tenar- eller klientautentisering.

For å gjenta den gjennomgangen offline, peik -CAfile mot nøyaktig den pakka du skal rulle ut, ikkje mot systemlageret. Elles testar du verten, ikkje endringa:

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 verkar berre mot ein enkel TLS-lyttar som HTTPS-administrasjonssida til gatewayen; kontrollkanalen til OpenVPN kjem før TLS, så s_client kan ikkje inspisere handtrykket i tunnelen.

Stioppbyggingsreglane bak desse feila står i RFC 5280 seksjon 6. Dei forklarer feila som elles verkar vilkårlege: eit utlope mellomledd som ingen hugsa, eit sertifikat der nøkkelbruken forbyr signering, eller ei namneavgrensing som utelèt verten du testar.

Kvifor den gamle tunnelen held fram med å verke

TLS og OpenVPN held begge ein etablert sesjon i live etter at handtrykket er ferdig. Ingenting revaliderer sertifikatet til parten per pakke, så ein klient som kopla til før endringa, held fram med å sleppe gjennom trafikk til han forhandlar på nytt, koplar til på nytt eller tunnelen fell. Akkurat dette gapet gjer at eit CA-utbytte kan sjå fint ut i ein time og så feile på det verste tidspunktet: ein berbar PC vaknar frå dvale, ei NAT-tildeling går ut, ein gateway startar på nytt.

Sesjonsgjenopptaking strekkjer illusjonen endå lenger. Ein TLS-sesjonsbillett lèt klienten kome tilbake utan å sende sertifikat på nytt, og gjenopptakinga hoppar over stivalidering fordi det første handtrykket alt gjorde det. Så den ærlege testen er eit fullt handtrykk i ein ny prosess. Start klienten på nytt i staden for å kople tunnelen til på nytt, og vurder å slå av billettar på ein testprofil, slik at gjenopptakingsvegen ikkje kan skjule ei broten kjede.

Hald laget for den statiske nøkkelen åtskilt frå dette. tls-auth legg til ein HMAC på kontrollkanalen, tls-crypt krypterer og autentiserer han, og ingen av dei ber sertifikatmateriale, så rotasjon av ein av dei er ei eiga endring med sin eigen feilmodus. Installasjonar som blandar dei to, endar med ein klient der den statiske nøkkelen er i orden, sertifikatet er utdatert og feilmeldinga ikkje nemner nokon av dei.

Fella med å bruke subjektnamnet om att

Det er freistande å bruke det distinguerte namnet til forgjengaren om att slik at ingenting lenger nede må endrast. Det held utstadarlinja stabil i grensesnittet og øydelegg det eine signalet du treng. To sertifikat med identiske subjekt og ulike nøklar kan ikkje skiljast på namn, så ei pakke med begge ankera gjev validatoren to kandidatar og inga regel for å velje.

Stioppbygginga kan då velje den gale, rapportere «kan ikkje hente lokalt utstadarsertifikat» medan det rette ankeret er til stades, eller lukkast på ein vert og feile på ein annan med same pakke, fordi kandidatrekkjefølgja var ulik. Om namnet må brukast om att, hald begge ankera i åtskilde filer i overgangen og last dei eksplisitt, og slå dei saman først når kvar part presenterer den nye utstadaren. Elles gje erstatninga eit eige vanleg namn — eit generasjons- eller datosuffiks er nok — slik at loggar og feiltekstar seier kva styresmakt ein feilande part vart utstad under.

Ein overgang som ikkje tek ned nettet

For eit planlagt utbytte, godta begge ankera i eit avgrensa vindauge i staden for å bytte i eitt steg. Utsted den nye CA-en og mellomledda, legg det nye ankeret i pakka til kvar validator ved sida av det gamle, og byrja først deretter å utstede partssertifikat frå det. Partar med gamle identitetar vert validerte mot det gamle ankeret; nye verkar mot det nye.

Gjort i den rekkjefølgja er kvart steg reversibelt. Feilen du unngår, er det samtidige byttet, der ein klient som mista pakkeoppdateringa møter ein gateway som alt har pensjonert det gamle ankeret, handtrykket døyr, og ingen logg seier kva side som er utdatert.

Pensjoner i motsett retning. Utsted på nytt kvar identitet som må overleve, stadfest at kvar av dei presenterer den nye kjeda, og fjern så det gamle ankeret frå pakkene. Ta den private nøkkelen til den gamle CA-en ut av drift, for ein utstadar som framleis kan signere betyr at overgangen ikkje er ferdig. Ta vare på sertifikata og utstedingsregistra for revisjon. Ein tapt utstadar vert gjenoppretta til same tillit; ei blottlegging krev nye identitetar og inga tilbakevending til det gamle ankeret.

Verifiser resultatet, ikkje fillista

Ei tillitsfil i forventa katalog beviser lite. Applikasjonen kan lese ein annan sti, eit anna format eller ein kopi inne i ei pakke som ein oppgradering erstattar. Kontroller åtferda i begge endar, ikkje at ei fil finst.

Stadfest at ein ny tilkopling med ein ny identitet lukkast, og stadfest så at ein identitet utstaden av den pensjonerte CA-en vert avvist. Den andre testen er den folk hoppar over, og den einaste som viser at den gamle styresmakta ikkje lenger gjev tilgang. Der installasjonen er avhengig av CRL eller OCSP, kontroller at distribusjonspunkta i dei nye sertifikata løyser seg opp og at svararen er nåbar frå partane som spør han.

Avslutt med ein klient som aldri har vore tilkopla: slett profiltilstanden, kople til og les den forhandla kjeda. Ein part som gjenopptek ein bufra sesjon, vil muntert rapportere at migreringa verka, utan å ha validert noko som helst.