Šta se događa kada zamijenite VPN certifikacijsko tijelo

Zamjena VPN certifikacijskog tijela nije zamjena datoteke. U trenutku kada novi CA potpiše svoj prvi certifikat, svaki validator koji još vjeruje samo starom mora donijeti odluku, a hostovi koji nikada ne prime novi oslonac nastavljaju odbijati dobre partnere. Vidio sam da to pukne u oba smjera: gateway je naučio novi CA, a klijenti nisu, pa su nove veze padale, dok su već uspostavljeni tuneli ostali i učinili prekid sličnim problemu s rutiranjem. Evo šta se mijenja, redom kojim se kvarovi pojavljuju.

Jedna zamjena, dvije odvojene promjene

Certifikacijsko tijelo je ime, javni ključ i privatni ključ koji potpisuje. Validatori nikada ne vjeruju „CA-u“ u apstraktnom smislu. Vjeruju jednom konkretnom certifikatu koji već stoji u spremištu povjerenja, a izdavaoca prihvataju samo ako lanac potpisa stigne do te sačuvane kopije. Zato zamjena CA-a mijenja dvije stvari koje padaju nezavisno: koji se oslonci prihvataju i koji su identiteti partnera izdati pod njima.

Većina VPN implementacija validira u oba smjera. Klijent provjerava certifikat gatewaya, a gateway certifikat klijenta. Prelaz koji osvježi samo klijentski paket ostavlja server da odbija svakog klijenta koji još predstavlja identitet starog CA-a, a obrnuto je jednako često. Prvo popišite mjesta primjene: spremišta povjerenja klijenata, ca datoteku gatewaya, svaki proxy koji završava TLS ispred njega i sondu koja provjerava krajnju točku izvana.

Šta validator provjerava, po redu

Validacija puta penje se od certifikata partnera kroz posrednike dok ne stigne do pouzdanog oslonca. Na svakom koraku provjerava potpis, gleda da je svaki certifikat unutar roka važenja i potvrđuje da osnovna ograničenja i namjena ključa dopuštaju izdavaocu potpisivanje. Tek tada aplikacija gleda lisni certifikat: alternativna imena subjekta moraju pokrivati ime na koje se pozvalo, a proširena namjena ključa mora dopuštati autentikaciju poslužitelja ili klijenta.

Da biste taj hod ponovili izvan mreže, usmjerite -CAfile na točan paket koji ćete implementirati, a ne na sistemsko spremište. Inače testirate host, a ne promjenu:

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

Ta naredba radi samo prema običnom TLS slušaču, poput gatewayeve HTTPS administrativne stranice; OpenVPN-ov kontrolni kanal prethodi TLS-u, pa s_client ne može pregledati rukovanje tunela.

Pravila izgradnje puta koja stoje iza tih grešaka nalaze se u RFC 5280 odjeljak 6. Ona objašnjavaju kvarove koji inače izgledaju proizvoljno: istekao posredni certifikat kojeg se nitko nije sjetio, certifikat čija namjena ključa zabranjuje potpisivanje ili ograničenje imena koje isključuje host koji testirate.

Zašto stari tunel nastavlja raditi

TLS i OpenVPN drže uspostavljenu sesiju živom nakon završetka rukovanja. Ništa ne provjerava certifikat partnera po paketu, pa klijent koji se spojio prije promjene nastavlja propuštati promet dok ponovno ne pregovara, ne spoji se iznova ili tunel ne padne. Upravo ta praznina čini da zamjena CA-a sat vremena izgleda dobro, a zatim padne u najgorem trenutku: prijenosnik se budi iz sna, NAT mapiranje istekne, gateway se restartira.

Nastavak sesije dodatno rasteže iluziju. TLS sesijska karta dopušta klijentu da se vrati bez ponovnog slanja certifikata, a nastavak preskače validaciju puta jer ju je prvo rukovanje već obavilo. Zato je iskren test puno rukovanje u novom procesu. Restartajte klijent umjesto ponovnog spajanja tunela, a na testnom profilu razmislite o isključivanju karata kako put nastavka ne bi mogao sakriti slomljen lanac.

Držite sloj statičkog ključa odvojeno od ovoga. tls-auth dodaje HMAC kontrolnom kanalu, tls-crypt ga šifrira i autentificira, a nijedno ne nosi certifikatni materijal, pa je rotacija bilo kojeg odvojena promjena s vlastitim načinom kvara. Implementacije koje pomiješaju to dvoje završe s klijentom čiji je statički ključ ispravan, certifikat zastario, a poruka o grešci ne spominje nijedno.

Zamka ponovnog korištenja imena subjekta

Primamljivo je ponovno upotrijebiti razlikovno ime prethodnika kako se nizvodno ništa ne bi moralo mijenjati. To drži redak izdavaoca stabilnim u sučelju i uništava jedini signal koji vam treba. Dva certifikata s identičnim subjektima i različitim ključevima ne mogu se razlikovati po imenu, pa paket s oba oslonca daje validatoru dva kandidata i nikakvo pravilo za odabir.

Izgradnja puta tada može odabrati pogrešan, prijaviti „nije moguće dobiti certifikat lokalnog izdavaoca“ dok je ispravan oslonac prisutan, ili uspjeti na jednom hostu i pasti na drugom s istim paketom jer se redoslijed kandidata razlikovao. Ako se ime mora ponovno upotrijebiti, držite oba oslonca u odvojenim datotekama tijekom prijelaza i učitajte ih izričito, a spojite ih tek kada svaki partner predstavi novog izdavaoca. Inače dodijelite zamjeni različito uobičajeno ime — sufiks generacije ili datuma je dovoljan — da bi zapisnici i tekstovi grešaka rekli pod kojim je tijelom izdan partner koji pada.

Prelaz koji ne ruši mrežu

Za planiranu zamjenu prihvatite oba oslonca na ograničeno razdoblje umjesto prebacivanja u jednom koraku. Izdajte novi CA i njegove posrednike, stavite novi oslonac u paket svakog validatora uz stari i tek tada počnite izdavati certifikate partnera iz njega. Partneri sa starim identitetima validiraju se prema starom osloncu; novi rade prema novom.

Ako se radi tim redom, svaki je korak reverzibilan. Kvar koji izbjegavate jest istodobno prebacivanje, gdje klijent koji je propustio ažuriranje paketa susreće gateway koji je već umirovio stari oslonac, rukovanje umire i nijedan zapis ne kaže koja je strana zastarjela.

Umirovljavajte u suprotnom smjeru. Ponovno izdajte svaki identitet koji mora preživjeti, potvrdite da svaki predstavlja novi lanac, pa tek onda uklonite stari oslonac iz paketa. Izvadite privatni ključ starog CA-a iz upotrebe, jer izdavalac koji još može potpisivati znači da prijelaz nije završen. Čuvajte certifikate i evidenciju izdavanja za reviziju. Izgubljeni izdavalac vraća se na isto povjerenje; izloženost zahtijeva nove identitete i nikakav povratak na stari oslonac.

Provjerite ishod, a ne popis datoteka

Datoteka povjerenja u očekivanom direktoriju malo dokazuje. Aplikacija može čitati drugu putanju, drugi format ili kopiju unutar paketa koju nadogradnja zamijeni. Provjerite ponašanje na oba kraja, a ne postoji li datoteka.

Potvrdite da nova veza s novim identitetom uspijeva, zatim potvrdite da se identitet izdan od umirovljenog CA-a odbija. Taj drugi test ljudi preskaču, i jedini je koji pokazuje da staro tijelo više ne daje pristup. Gdje se implementacija oslanja na CRL ili OCSP, provjerite da se točke distribucije u novim certifikatima razrješavaju i da je odgovarač dostupan partnerima koji ga pitaju.

Završite s klijentom koji se nikada nije spojio: obrišite stanje njegovog profila, spojite se i pročitajte pregovoreni lanac. Partner koji nastavlja predmemoriranu sesiju veselo će izvijestiti da je migracija uspjela, a nije validirao ništa.