Kas atsitinka, kai pakeičiate VPN sertifikatų instituciją

Pakeisti VPN sertifikatų instituciją nėra failo pakeitimas. Tą akimirką, kai naujoji CA pasirašo pirmąjį sertifikatą, kiekvienas validuotojas, kuris vis dar pasitiki tik senąja, turi priimti sprendimą, o mazgai, kurie niekada negauna naujo inkaro, toliau atmeta gerus partnerius. Mačiau, kaip tai lūžta abiem kryptimis: tinklų sietuvas išmoko naująją CA, o klientai ne, todėl nauji ryšiai žlugo, o jau pakelti tuneliai liko stovėti ir privertė gedimą atrodyti kaip maršrutizavimo problema. Štai kas keičiasi, ta tvarka, kuria pasirodo gedimai.

Vienas pakeitimas, du atskiri pokyčiai

Sertifikatų institucija yra vardas, viešasis raktas ir pasirašantis privatusis raktas. Validuotojai niekada nepasitiki „CA“ abstrakčiai. Jie pasitiki vienu konkrečiu sertifikatu, kuris jau yra pasitikėjimo saugykloje, ir priima išdavėją tik tada, kai parašų grandinė pasiekia tą saugomą kopiją. Todėl CA pakeitimas keičia du dalykus, kurie žlunga nepriklausomai: kurie inkaro sertifikatai priimami ir kurios partnerių tapatybės buvo išduotos jų pagrindu.

Dauguma VPN diegimų tikrina abiem kryptimis. Klientas autentifikuoja tinklų sietuvo sertifikatą, o sietuvas – kliento sertifikatą. Rotacija, kuri atnaujina tik kliento paketą, palieka serverį atmetinėti kiekvieną klientą, kuris vis dar pateikia senosios CA tapatybę, ir atvirkščiai yra taip pat įprasta. Pirmiausia surašykite vykdymo taškus: klientų pasitikėjimo saugyklas, sietuvo ca failą, bet kokį TLS užbaigiantį tarpinį serverį prieš jį ir zondą, kuris tikrina galinį tašką iš išorės.

Ką tikrina validuotojas, iš eilės

Kelio validacija kyla nuo partnerio sertifikato per tarpinius, kol pasiekia patikimą inkarą. Kiekviename žingsnyje ji tikrina parašą, nustato, ar kiekvienas sertifikatas yra galiojimo laikotarpyje, ir patvirtina, kad pagrindiniai apribojimai ir rakto paskirtis leidžia išdavėjui pasirašyti. Tik tada programa žiūri į lapo sertifikatą: subjekto alternatyvūs vardai turi apimti surinktą vardą, o išplėstinė rakto paskirtis turi leisti serverio arba kliento autentifikaciją.

Norėdami pakartoti tą kelią neprisijungę, nukreipkite -CAfile į tiksliai tą paketą, kurį diegsite, o ne į sistemos saugyklą. Priešingu atveju testuojate mazgą, o ne pokytį:

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 komanda veikia tik prieš paprastą TLS klausytoją, pavyzdžiui, sietuvo HTTPS administravimo puslapį; OpenVPN valdymo kanalas eina prieš TLS, todėl s_client negali patikrinti tunelio rankos paspaudimo.

Kelio kūrimo taisyklės, slypinčios už tų klaidų, yra RFC 5280 6 skyriuje. Jos paaiškina gedimus, kurie kitaip atrodo savavališki: pasibaigęs tarpinis sertifikatas, kurio niekas neatsiminė, sertifikatas, kurio rakto paskirtis draudžia pasirašyti, arba vardo apribojimas, išskiriantis testuojamą mazgą.

Kodėl senas tunelis veikia toliau

TLS ir OpenVPN abu palaiko nusistovėjusią sesiją gyvą po to, kai rankos paspaudimas baigiasi. Niekas iš naujo netikrina partnerio sertifikato kiekvienam paketui, todėl klientas, prisijungęs prieš pokytį, toliau praleidžia srautą, kol iš naujo derasi, prisijungia arba tunelis nukrenta. Būtent šis tarpas leidžia CA pakeitimui valandą atrodyti gerai, o paskui sugesti pačiu blogiausiu momentu: nešiojamasis kompiuteris pabunda iš miego, NAT susiejimas baigiasi, sietuvas persikrauna.

Sesijos atnaujinimas dar labiau ištempia iliuziją. TLS sesijos bilietas leidžia klientui grįžti nepersiunčiant sertifikatų, o atnaujinimas praleidžia kelio validaciją, nes pirmasis rankos paspaudimas jau tai padarė. Taigi sąžiningas testas yra pilnas rankos paspaudimas naujame procese. Perkraukite klientą, o ne prijunkite tunelį iš naujo, ir bandomajame profilyje apsvarstykite galimybę išjungti bilietus, kad atnaujinimo kelias negalėtų paslėpti sudužusios grandinės.

Laikykite statinio rakto sluoksnį atskirai nuo to. tls-auth prideda HMAC prie valdymo kanalo, tls-crypt jį šifruoja ir autentifikuoja, ir nė vienas iš jų neneša sertifikato medžiagos, todėl bet kurio iš jų rotacija yra atskiras pokytis su savo gedimo režimu. Diegimai, kurie sumaišo abu, baigiasi klientu, kurio statinis raktas tvarkingas, sertifikatas pasenęs, o klaidos pranešimas nemini nė vieno.

Subjekto vardo pakartotinio naudojimo spąstai

Vilioja pakartotinai naudoti pirmtako skiriamąjį vardą, kad nieko žemiau nereikėtų keisti. Tai palaiko išdavėjo eilutę stabilią sąsajoje ir sunaikina vienintelį signalą, kurio jums reikia. Du sertifikatai su identiškais subjektais ir skirtingais raktais negali būti atskirti pagal vardą, todėl paketas su abiem inkarais duoda validuotojui du kandidatus ir jokios taisyklės pasirinkti.

Tada kelio kūrimas gali pasirinkti netinkamą, pranešti „nepavyko gauti vietinio išdavėjo sertifikato“, nors teisingas inkaras yra, arba pavykti viename mazge ir nepavykti kitame su tuo pačiu paketu, nes kandidatų tvarka skyrėsi. Jei vardą reikia naudoti pakartotinai, pereinamuoju laikotarpiu laikykite abu inkarus atskiruose failuose ir įkelkite juos aiškiai, o sujunkite tik tada, kai kiekvienas partneris pateikia naują išdavėją. Kitu atveju suteikite keitiniui atskirą bendrinį vardą – kartos ar datos priesagos pakanka –, kad žurnalai ir klaidų tekstai pasakytų, pagal kokią instituciją buvo išduotas nepavykstantis partneris.

Rotacija, kuri nenugriauna tinklo

Planuojamam pakeitimui priimkite abu inkarus ribotą laikotarpį, o ne perjunkite vienu žingsniu. Išduokite naują CA ir jo tarpinius, įdėkite naują inkarą į kiekvieno validuotojo paketą šalia senojo ir tik tada pradėkite iš jo išduoti partnerių sertifikatus. Partneriai su senomis tapatybėmis validuojami pagal senąjį inkarą; naujieji veikia pagal naująjį.

Atlikus ta tvarka, kiekvienas žingsnis yra grįžtamas. Gedimas, kurio išvengiate, yra vienalaikis perjungimas, kai klientas, praleidęs paketo atnaujinimą, sutinka sietuvą, kuris jau išėmė senąjį inkarą, rankos paspaudimas miršta, ir nė vienas žurnalas nepasako, kuri pusė pasenusi.

Išimkite priešinga kryptimi. Išduokite iš naujo kiekvieną tapatybę, kuri turi išlikti, patvirtinkite, kad kiekviena pateikia naują grandinę, ir tada pašalinkite senąjį inkarą iš paketų. Išimkite senosios CA privatųjį raktą iš naudojimo, nes išdavėjas, kuris dar gali pasirašyti, reiškia, kad rotacija nebaigta. Saugokite sertifikatus ir išdavimo įrašus auditui. Prarastas išdavėjas atkuriamas į tą patį pasitikėjimą; atskleidimas reikalauja naujų tapatybių ir jokio grįžimo prie senojo inkaro.

Tikrinkite rezultatą, o ne failų sąrašą

Pasitikėjimo failas laukiamame kataloge mažai ką įrodo. Programa gali skaityti kitą kelią, kitą formatą arba kopiją pakete, kurį pakeičia naujinimas. Tikrinkite elgesį abiejuose galuose, o ne tai, ar failas egzistuoja.

Patvirtinkite, kad naujas ryšys su nauja tapatybe pavyksta, tada patvirtinkite, kad tapatybė, išduota išimtos CA, atmetama. Būtent antrąjį testą žmonės praleidžia, ir jis vienintelis parodo, kad senoji institucija nebesuteikia prieigos. Kai diegimas remiasi CRL arba OCSP, patikrinkite, ar naujuose sertifikatuose nurodyti paskirstymo taškai išsprendžiami ir ar atsakiklis pasiekiamas iš jį klausiančių partnerių.

Baigkite klientu, kuris niekada nebuvo prisijungęs: ištrinkite jo profilio būseną, prisijunkite ir perskaitykite suderėtą grandinę. Partneris, atnaujinantis podėlyje saugomą sesiją, linksmai praneš, kad migracija pavyko, nors nieko nepatikrino.