Kas notiek, ja nomaina VPN sertifikācijas iestādi

Nomainīt VPN sertifikācijas iestādi nav faila nomaiņa. Tajā brīdī, kad jaunā CA paraksta savu pirmo sertifikātu, katram validatoram, kas joprojām uzticas tikai vecajai, ir jāpieņem lēmums, un resursdatori, kas nekad nesaņem jauno enkuru, turpina noraidīt labus partnerus. Esmu redzējis, kā tas sabrūk abos virzienos: vārteja iemācījās jauno CA, bet klienti ne, tāpēc jaunie savienojumi neizdevās, kamēr jau paceltie tuneļi palika un lika pārtraukumam izskatīties kā maršrutēšanas problēmai. Lūk, kas mainās, tādā secībā, kādā parādās atteices.

Viena nomaiņa, divas atsevišķas izmaiņas

Sertifikācijas iestāde ir nosaukums, publiskā atslēga un parakstošā privātā atslēga. Validatori nekad neuzticas „CA“ abstrakti. Viņi uzticas vienam konkrētam sertifikātam, kas jau atrodas uzticības krātuvē, un izdevēju pieņem tikai tad, ja parakstu ķēde sasniedz šo saglabāto kopiju. Tāpēc CA nomaiņa maina divas lietas, kas sabrūk neatkarīgi: kuri enkuri tiek pieņemti un kuras partneru identitātes tika izsniegtas to pakļautībā.

Lielākā daļa VPN ieviešanu validē abos virzienos. Klients autentificē vārtejas sertifikātu, un vārteja autentificē klienta sertifikātu. Rotācija, kas atsvaidzina tikai klienta paketi, liek serverim noraidīt katru klientu, kurš joprojām uzrāda vecās CA identitāti, un pretējais ir tikpat izplatīts. Vispirms uzskaitiet izpildes punktus: klientu uzticības krātuves, vārtejas ca failu, jebkuru TLS izbeidzošo starpniekserveri tās priekšā un zondi, kas pārbauda galapunktu no ārpuses.

Ko validators pārbauda, secībā

Ceļa validācija kāpj no partnera sertifikāta cauri starpposma sertifikātiem, līdz sasniedz uzticamu enkuru. Katrā solī tā pārbauda parakstu, pārliecinās, ka katrs sertifikāts ir tā derīguma logā, un apstiprina, ka pamatierobežojumi un atslēgas lietojums ļauj izdevējam parakstīt. Tikai tad lietotne skatās uz lapas sertifikātu: subjekta alternatīvajiem nosaukumiem jāaptver izsauktais nosaukums, un paplašinātajam atslēgas lietojumam jāatļauj servera vai klienta autentifikācija.

Lai atkārtotu šo gājienu bezsaistē, vērsiet -CAfile uz tieši to paketi, kuru izvietosiet, nevis uz sistēmas krātuvi. Citādi jūs pārbaudāt resursdatoru, nevis izmaiņas:

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

Šī komanda darbojas tikai pret vienkāršu TLS klausītāju, piemēram, vārtejas HTTPS administrēšanas lapu; OpenVPN vadības kanāls ir pirms TLS, tāpēc s_client nevar pārbaudīt tuneļa rokasspiedienu.

Ceļa veidošanas noteikumi aiz šīm kļūdām ir atrodami RFC 5280 sadaļā 6. Tie izskaidro atteices, kas citādi šķiet patvaļīgas: beidzies starpposma sertifikāts, kuru neviens neatcerējās, sertifikāts, kura atslēgas lietojums aizliedz parakstīšanu, vai nosaukuma ierobežojums, kas izslēdz pārbaudāmo resursdatoru.

Kāpēc vecais tunelis turpina darboties

TLS un OpenVPN abi uztur izveidoto sesiju dzīvu pēc rokasspiediena beigām. Nekas atkārtoti nevalidē partnera sertifikātu katram paketei, tāpēc klients, kas savienojās pirms izmaiņām, turpina laist satiksmi, līdz vēlreiz pārrunā, pieslēdzas no jauna vai tunelis nokrīt. Tieši šī plaisa ļauj CA nomaiņai stundu izskatīties labi un pēc tam neizdoties sliktākajā brīdī: klēpjdators pamostas no miega, NAT kartējums beidzas, vārteja pārstartējas.

Sesijas atsākšana vēl vairāk stiepj ilūziju. TLS sesijas biļete ļauj klientam atgriezties, nenosūtot sertifikātus no jauna, un atsākšana izlaiž ceļa validāciju, jo pirmais rokasspiediens to jau izdarīja. Tāpēc godīgā pārbaude ir pilns rokasspiediens jaunā procesā. Pārstartējiet klientu, nevis pievienojiet tuneli no jauna, un testa profilā apsveriet biļešu atslēgšanu, lai atsākšanas ceļš nevarētu noslēpt salauztu ķēdi.

Turiet statiskās atslēgas slāni atsevišķi no šī. tls-auth pievieno HMAC vadības kanālam, tls-crypt to šifrē un autentificē, un neviens no tiem nenes sertifikāta materiālu, tāpēc jebkura no tiem rotācija ir atsevišķa izmaiņa ar savu atteices režīmu. Izvietojumi, kas sajauc abus, nonāk pie klienta, kuram statiskā atslēga ir kārtībā, sertifikāts ir novecojis un kļūdas ziņojums nepiemin nevienu.

Subjekta nosaukuma atkārtotas izmantošanas slazds

Kārdinoši ir atkārtoti izmantot priekšteča atšķirīgo nosaukumu, lai zemāk nekas nav jāmaina. Tas notur izdevēja rindu saskarnē stabilu un iznīcina vienīgo signālu, kas jums vajadzīgs. Divus sertifikātus ar identiskiem subjektiem un atšķirīgām atslēgām nevar atšķirt pēc nosaukuma, tāpēc pakete ar abiem enkuriem dod validatoram divus kandidātus un nekādu izvēles noteikumu.

Tad ceļa veidošana var izvēlēties nepareizo, paziņot „nevar iegūt vietējā izdevēja sertifikātu“, kamēr pareizais enkurs ir klāt, vai gūt panākumus vienā resursdatorā un neizdoties citā ar to pašu paketi, jo kandidātu secība atšķīrās. Ja nosaukums ir jāizmanto atkārtoti, pārejas laikā turiet abus enkurus atsevišķos failos un ielādējiet tos skaidri, un apvienojiet tos tikai tad, kad katrs partneris uzrāda jauno izdevēju. Citādi piešķiriet aizvietotājam atšķirīgu vispārīgo nosaukumu — paaudzes vai datuma piedēklis ir pietiekams —, lai žurnāli un kļūdu teksti pateiktu, kuras iestādes pakļautībā tika izsniegts nespējīgais partneris.

Rotācija, kas nenomet tīklu

Plānotai nomaiņai pieņemiet abus enkurus ierobežotā laika posmā, nevis pārslēdzieties vienā solī. Izsniegiet jauno CA un tā starpposma sertifikātus, ievietojiet jauno enkuru katra validatora paketē blakus vecajam, un tikai pēc tam sāciet no tā izsniegt partneru sertifikātus. Partneri ar vecajām identitātēm validējas pret veco enkuru; jaunie darbojas pret jauno.

Šādā secībā veicot, katrs solis ir atgriežams. Atteice, no kuras izvairāties, ir vienlaicīga pārslēgšanās, kad klients, kurš palaidis garām paketes atjauninājumu, sastop vārteju, kas jau ir izņēmusi veco enkuru, rokasspiediens mirst, un neviens žurnāls nepasaka, kura puse ir novecojusi.

Izņemiet pretējā virzienā. Izsniedziet no jauna katru identitāti, kurai jāizdzīvo, apstipriniet, ka katra uzrāda jauno ķēdi, un pēc tam noņemiet veco enkuru no paketēm. Izņemiet vecās CA privāto atslēgu no ekspluatācijas, jo izdevējs, kas vēl var parakstīt, nozīmē, ka rotācija nav pabeigta. Saglabājiet sertifikātus un izsniegšanas ierakstus auditam. Pazaudēts izdevējs tiek atjaunots tajā pašā uzticībā; noplūde prasa jaunas identitātes un nekādu atgriešanos pie vecā enkura.

Pārbaudiet rezultātu, nevis failu sarakstu

Uzticības fails gaidītajā mapē pierāda maz. Lietotne var lasīt citu ceļu, citu formātu vai kopiju paketē, ko aizstāj atjauninājums. Pārbaudiet uzvedību abos galos, nevis to, vai fails pastāv.

Apstipriniet, ka jauns savienojums ar jaunu identitāti izdodas, pēc tam apstipriniet, ka identitāte, ko izsniegusi izņemtā CA, tiek noraidīta. Tieši otro testu cilvēki izlaiž, un tas ir vienīgais, kas parāda, ka vecā iestāde vairs nepiešķir piekļuvi. Kur izvietojums balstās uz CRL vai OCSP, pārbaudiet, ka jaunajos sertifikātos norādītie izplatīšanas punkti tiek atrisināti un ka atbildētājs ir sasniedzams no partneriem, kas to jautā.

Beidziet ar klientu, kas nekad nav savienojies: notīriet tā profila stāvokli, pievienojieties un izlasiet saskaņoto ķēdi. Partneris, kas atsāk kešatmiņā saglabātu sesiju, priecīgi ziņos, ka migrācija izdevās, lai gan neko nav validējis.