Mis juhtub, kui vahetate VPN-i sertifitseerimisasutuse

VPN-i sertifitseerimisasutuse vahetamine ei ole faili vahetamine. Hetkest, mil uus CA allkirjastab oma esimese sertifikaadi, peab iga valideerija, kes usaldab endiselt ainult vana, otsuse tegema, ja hostid, kes uut ankrut kunagi ei saa, jätkavad heade partnerite tagasilükkamist. Olen näinud seda mõlemas suunas nurjumist: lüüs õppis uue CA ära, kliendid mitte, nii et uued ühendused ebaõnnestusid, samas kui juba püsti olevad tunnelid jäid püsti ja panid katkestuse nägema marsruutimisprobleemina. Siin on, mis muutub, selles järjekorras, nagu tõrked ilmuvad.

Üks vahetus, kaks eraldi muutust

Sertifitseerimisasutus on nimi, avalik võti ja privaatvõti, mis allkirjastab. Valideerijad ei usalda kunagi „CA-d“ abstraktselt. Nad usaldavad ühte konkreetset sertifikaati, mis juba asub usaldushoidlas, ja aktsepteerivad väljaandjat ainult siis, kui allkirjade ahel jõuab selle salvestatud koopiani. Seega muudab CA vahetamine kahte asja, mis nurjuvad sõltumatult: milliseid ankrutest aktsepteeritakse ja millised partneri identiteedid nende all välja anti.

Enamik VPN-i juurutusi valideerib mõlemas suunas. Klient autendib lüüsi sertifikaati ja lüüs kliendi sertifikaati. Üleminek, mis värskendab ainult kliendi paketti, jätab serveri tagasi lükkama iga klienti, kes esitab endiselt vana CA identiteeti, ja vastupidine on sama tavaline. Kaardistage esmalt jõustamispunktid: klientide usaldushoidlad, lüüsi ca fail, mis tahes TLS-i lõpetav puhverserver selle ees ja sond, mis kontrollib lõpp-punkti väljastpoolt.

Mida valideerija kontrollib, järjekorras

Tee valideerimine tõuseb partneri sertifikaadist läbi vahesertifikaatide, kuni jõuab usaldusväärse ankruni. Igal sammul kontrollib see allkirja, veendub, et iga sertifikaat on oma kehtivusaknas, ja kinnitab, et põhipiirangud ja võtme kasutus lubavad väljaandjal allkirjastada. Alles siis vaatab rakendus lehtsertifikaati: subjekti alternatiivsed nimed peavad katma valitud nime ja laiendatud võtme kasutus peab lubama serveri või kliendi autentimist.

Selle teekonna võrguühenduseta kordamiseks suunake -CAfile täpselt sellele paketile, mille juurutate, mitte süsteemi hoidlale. Muidu testite hosti, mitte muutust:

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

See käsk töötab ainult lihtsa TLS-i kuulaja vastu, nagu lüüsi HTTPS-i haldusleht; OpenVPN-i juhtkanal eelneb TLS-ile, seega s_client ei saa tunneli kätlust uurida.

Nende vigade taga olevad tee-ehituse reeglid on RFC 5280 jaotis 6. Need selgitavad tõrkeid, mis muidu tunduvad meelevaldsed: aegunud vahesertifikaat, mida keegi ei mäletanud, sertifikaat, mille võtme kasutus keelab allkirjastamise, või nimepiirang, mis välistab testitava hosti.

Miks vana tunnel edasi töötab

TLS ja OpenVPN hoiavad mõlemad loodud sessiooni elus pärast kätluse lõppu. Miski ei valideeri partneri sertifikaati uuesti iga paketi kohta, seega enne muutust ühendunud klient edastab liiklust edasi, kuni ta uuesti läbi räägib, uuesti ühendub või tunnel katkeb. Just see lünk teeb, et CA vahetus võib tunduda tund aega korras ja siis kõige halvemal hetkel nurjuda: sülearvuti ärkab unest, NAT-i vastendus aegub, lüüs taaskäivitub.

Sessiooni jätkamine venitab illusiooni veelgi. TLS-i sessioonipilet lubab kliendil naasta ilma sertifikaate uuesti saatmata, ja jätkamine jätab tee valideerimise vahele, sest esimene kätlus tegi selle juba ära. Seega on aus test täielik kätlus värskes protsessis. Taaskäivitage klient, mitte ärge ühendage tunnelit uuesti, ja testprofiilil kaaluge piletite keelamist, et jätkamise tee ei saaks katkist ahelat varjata.

Hoidke staatilise võtme kiht sellest eraldi. tls-auth lisab juhtkanalile HMAC-i, tls-crypt krüpteerib ja autendib selle, ja kumbki ei kanna sertifikaadi materjali, seega kummagi roteerimine on eraldi muutus oma tõrkerežiimiga. Juurutused, mis need kaks segi ajavad, jõuavad kliendini, mille staatiline võti on korras, sertifikaat vananenud ja veateade ei maini kumbagi.

Subjekti nime korduskasutuse lõks

Ahvatlev on eelkäija eristusnime uuesti kasutada, et allpool ei peaks miski muutuma. See hoiab väljaandja rea liideses stabiilsena ja hävitab ainsa signaali, mida vajate. Kahte identse subjekti ja erineva võtmega sertifikaati ei saa nime järgi eristada, seega mõlemat ankrut sisaldav pakett annab valideerijale kaks kandidaati ja mitte ühtegi valikureeglit.

Siis võib tee-ehitus valida vale, teatada „kohaliku väljaandja sertifikaati ei saa hankida“, kuigi õige ankur on olemas, või õnnestuda ühel hostil ja nurjuda teisel sama paketiga, sest kandidaatide järjekord erines. Kui nime tuleb uuesti kasutada, hoidke mõlemat ankrut ülemineku ajal eraldi failides ja laadige need selgesõnaliselt, ning ühendage need alles siis, kui iga partner esitab uue väljaandja. Muidu andke asendusele eristuv üldnimi — põlvkonna või kuupäeva järelliide on piisav —, et logid ja veatekstid ütleksid, millise asutuse all nurjuv partner välja anti.

Üleminek, mis võrku maha ei võta

Plaanilise vahetuse puhul aktsepteerige mõlemat ankrut piiratud ajaaknas, mitte ärge lülitage ühe sammuga. Andke välja uus CA ja selle vahesertifikaadid, pange uus ankur iga valideerija paketti vana kõrvale ja alles seejärel alustage sellest partneri sertifikaatide väljaandmist. Vanade identiteetidega partnerid valideeruvad vana ankru vastu; uued töötavad uue ankru vastu.

Selles järjekorras tehtuna on iga samm pööratav. Tõrge, mida väldite, on samaaegne lülitus, kus paketi värskendusest ilma jäänud klient kohtab lüüsi, mis on vana ankru juba kasutusest kõrvaldanud, kätlus sureb ja kumbki logi ei ütle, milline pool on vananenud.

Taanduge vastassuunas. Andke uuesti välja iga identiteet, mis peab püsima, kinnitage, et igaüks esitab uue ahela, ja seejärel eemaldage vana ankur pakettidest. Võtke vana CA privaatvõti kasutusest välja, sest väljaandja, kes suudab veel allkirjastada, tähendab, et üleminek ei ole lõppenud. Hoidke sertifikaadid ja väljaandmiskirjed auditi jaoks. Kaotatud väljaandja taastatakse samasse usaldusse; paljastumine nõuab uusi identiteete ja mingit tagasipöördumist vana ankru juurde.

Kontrollige tulemust, mitte failide loendit

Usaldusfail oodatud kataloogis tõestab vähe. Rakendus võib lugeda teist teed, teist vormingut või koopiat paketis, mille uuendus asendab. Kontrollige käitumist mõlemas otsas, mitte faili olemasolu.

Kinnitage, et värske ühendus uue identiteediga õnnestub, ja seejärel kinnitage, et kasutusest kõrvaldatud CA välja antud identiteet lükatakse tagasi. Teine test on see, mille inimesed vahele jätavad, ja ainus, mis näitab, et vana asutus ei anna enam juurdepääsu. Kui juurutus tugineb CRL-ile või OCSP-le, kontrollige, et uute sertifikaatide jaotuspunktid lahenevad ja vastaja on küsijatest partneritest kättesaadav.

Lõpetage kliendiga, mis pole kunagi ühendunud: kustutage selle profiili olek, ühenduge ja lugege kokku lepitud ahel. Vahemällu salvestatud sessiooni jätkav partner teatab rõõmsalt, et migratsioon õnnestus, kuigi ta ei valideerinud midagi.