Çfarë ndodh kur zëvendësoni një autoritet certifikimi VPN

Zëvendësimi i një autoriteti certifikimi VPN nuk është ndërrim skedari. Në momentin që CA e re nënshkruan certifikatën e saj të parë, çdo validues që ende beson vetëm te ajo e vjetra duhet të vendosë, dhe hostet që nuk e marrin kurrë ankerën e re vazhdojnë të refuzojnë partnerë të mirë. E kam parë të dështojë në të dy drejtimet: porta mësoi CA-në e re dhe klientët jo, kështu që lidhjet e reja dështonin, ndërsa tunelet e ngritura tashmë mbeteshin lart dhe e bënin ndërprerjen të dukej si problem rrugëtimi. Ja çfarë ndryshon, sipas radhës që shfaqen dështimet.

Një zëvendësim, dy ndryshime të ndara

Një autoritet certifikimi është një emër, një çelës publik dhe çelësi privat që nënshkruan. Validuesit nuk besojnë kurrë «CA-në» në mënyrë abstrakte. Besojnë një certifikatë të caktuar që ndodhet tashmë në një depo besimi dhe e pranojnë një lëshues vetëm nëse një zinxhir nënshkrimesh arrin te ajo kopje e ruajtur. Prandaj zëvendësimi i CA-së ndryshon dy gjëra që dështojnë në mënyrë të pavarur: cilat ankera pranohen dhe cilat identitete partnerësh u lëshuan nën to.

Shumica e instalimeve VPN validon në të dy drejtimet. Klienti vërteton certifikatën e portës, dhe porta atë të klientit. Një rotacion që rifreskon vetëm paketën e klientit e lë serverin të refuzojë çdo klient që ende paraqet një identitet të CA-së së vjetër, dhe e kundërta është po aq e zakonshme. Së pari inventarizoni pikat e zbatimit: depot e besimit të klientëve, skedarin ca të portës, çdo përfaqësues që përfundon TLS përpara saj dhe sondën që kontrollon pikën fundore nga jashtë.

Çfarë kontrollon një validues, sipas radhës

Validimi i shtegut ngjitet nga certifikata e partnerit përmes ndërmjetësve derisa arrin një anker të besuar. Në çdo hap verifikon nënshkrimin, kontrollon që çdo certifikatë është brenda dritares së vlefshmërisë dhe konfirmon që kufizimet bazë dhe përdorimi i çelësit e lejojnë lëshuesin të nënshkruajë. Vetëm atëherë aplikacioni shikon certifikatën gjethe: emrat alternativë të subjektit duhet të mbulojnë emrin e thirrur, dhe përdorimi i zgjeruar i çelësit duhet të lejojë vërtetimin e serverit ose të klientit.

Për ta përsëritur atë ecje në linjë të shkëputur, drejtojeni -CAfile te paketa e saktë që do të vendosni, jo te depoja e sistemit. Përndryshe po testoni hostin, jo ndryshimin:

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

Ai komandim funksionon vetëm ndaj një dëgjuesi të thjeshtë TLS si faqja e administrimit HTTPS e portës; kanali i kontrollit i OpenVPN i paraprin TLS, kështu që s_client nuk mund të inspektojë shtrëngimin e duarve të tunelit.

Rregullat e ndërtimit të shtegut pas atyre gabimeve gjenden në RFC 5280 seksioni 6. Ato shpjegojnë dështimet që ndryshe duken arbitrare: një ndërmjetës i skaduar që askush nuk e mbante mend, një certifikatë përdorimi i çelësit të së cilës ndalon nënshkrimin, ose një kufizim emri që përjashton hostin që po testoni.

Pse tuneli i vjetër vazhdon të funksionojë

TLS dhe OpenVPN të dy e mbajnë gjallë një sesion të vendosur pasi mbaron shtrëngimi i duarve. Asgjë nuk e rinvalidon certifikatën e partnerit për çdo paketë, kështu që një klient i lidhur para ndryshimit vazhdon të kalojë trafik derisa të rinegociojë, të rilidhet ose tuneli të bjerë. Pikërisht kjo e çarë bën që një zëvendësim CA të duket në rregull për një orë dhe pastaj të dështojë në momentin më të keq: një laptop zgjohet nga gjumi, një hartëzim NAT skadon, një portë riniset.

Rimarrja e sesionit e zgjat edhe më shumë iluzionin. Një biletë sesioni TLS e lejon klientin të kthehet pa ridërguar certifikatat, dhe rimarrja kalon validimin e shtegut sepse shtrëngimi i parë i duarve e bëri tashmë. Pra testi i ndershëm është një shtrëngim i plotë duarsh në një proces të ri. Rinisni klientin në vend që të rilidhni tunelin, dhe në një profil testimi merrni parasysh çaktivizimin e biletave që shtegu i rimarrjes të mos mund të fshehë një zinxhir të thyer.

Mbajeni shtresën e çelësit statik veçmas nga kjo. tls-auth shton një HMAC te kanali i kontrollit, tls-crypt e kripton dhe e vërteton, dhe asnjëri nuk mbart material certifikate, kështu që rotacioni i secilit është një ndryshim i veçantë me mënyrën e vet të dështimit. Instalimet që i ngatërrojnë të dy përfundojnë me një klient, çelësi statik i të cilit është në rregull, certifikata e të cilit është e vjetruar dhe mesazhi i gabimit nuk përmend asnjë prej tyre.

Kurthi i ripërdorimit të emrit të subjektit

Është joshëse të ripërdoret emri dallues i paraardhësit që asgjë në rrjedhën e poshtme të mos ketë nevojë të ndryshojë. Kjo e mban rreshtin e lëshuesit të qëndrueshëm në ndërfaqe dhe shkatërron sinjalin e vetëm që ju nevojitet. Dy certifikata me subjekte identike dhe çelësa të ndryshëm nuk dallohen sipas emrit, kështu që një paketë me të dy ankerat i jep validuesit dy kandidatë dhe asnjë rregull për të zgjedhur.

Ndërtimi i shtegut pastaj mund të zgjedhë të gabuarin, të raportojë «certifikata e lëshuesit lokal nuk mund të merret» ndërsa ankera e saktë është e pranishme, ose të ketë sukses në një host dhe të dështojë në një tjetër me të njëjtën paketë, sepse radha e kandidatëve ndryshonte. Nëse emri duhet ripërdorur, mbajini të dy ankerat në skedarë të ndarë gjatë tranzicionit dhe ngarkojini në mënyrë eksplicite, dhe bashkojini vetëm kur çdo partner paraqet lëshuesin e re. Përndryshe jepini zëvendësimit një emër të përbashkët të dallueshëm — një prapashtesë gjenerate ose date mjafton — që regjistrat dhe tekstet e gabimeve të thonë nën cilën autoritet u lëshua partneri që dështon.

Një rotacion që nuk e rrëzon rrjetin

Për një zëvendësim të planifikuar, pranoni të dy ankerat për një dritare të kufizuar në vend që të ndërroni në një hap. Lëshoni CA-në e re dhe ndërmjetësit e saj, vendosni ankerën e re në paketën e çdo validuesi pranë asaj të vjetre, dhe vetëm pastaj filloni të lëshoni certifikata partnerësh prej saj. Partnerët me identitete të vjetra validon kundrejt ankerës së vjetër; të rejat punojnë kundrejt asaj të re.

E bërë në atë radhë, çdo hap është i kthyeshëm. Dështimi që shmangni është ndërrimi i njëkohshëm, kur një klient që humbi përditësimin e paketës takon një portë që e ka tërhequr tashmë ankerën e vjetër, shtrëngimi i duarve vdes dhe asnjë regjistër nuk thotë cila anë është e vjetruar.

Tërhiquni në drejtimin e kundërt. Rilëshoni çdo identitet që duhet të mbijetojë, konfirmoni që secili paraqet zinxhirin e re, pastaj hiqni ankerën e vjetër nga paketat. Hiqni çelësin privat të CA-së së vjetër nga shërbimi, sepse një lëshues që ende mund të nënshkruajë do të thotë që rotacioni nuk ka mbaruar. Ruani certifikatat dhe regjistrat e lëshimit për auditim. Një lëshues i humbur restaurohet në të njëjtin besim; një ekspozim kërkon identitete të reja dhe asnjë kthim te ankera e vjetër.

Verifikoni rezultatin, jo listën e skedarëve

Një skedar besimi në drejtorinë e pritur provon pak. Aplikacioni mund të lexojë një shteg tjetër, një format tjetër ose një kopje brenda një pakete që një përditësim e zëvendëson. Kontrolloni sjelljen në të dy skajet, jo ekzistencën e një skedari.

Konfirmoni që një lidhje e re me një identitet të re ka sukses, pastaj konfirmoni që një identitet i lëshuar nga CA e tërhequr refuzohet. Pikërisht testi i dytë është ai që njerëzit e kapërcejnë, dhe i vetmi që tregon se autoriteti i vjetër nuk jep më akses. Aty ku instalimi mbështetet te CRL ose OCSP, kontrolloni që pikat e shpërndarjes në certifikatat e reja zgjidhen dhe që partnerët që pyesin arrijnë te përgjigjësi.

Përfundoni me një klient që nuk është lidhur kurrë: fshini gjendjen e profilit të tij, lidheni dhe lexoni zinxhirin e negociuar. Një partner që rimerr një sesion të ruajtur në memorie do të raportojë me gëzim se migrimi funksionoi, ndërsa nuk ka validuar asgjë.