Rinovimi i një certifikate VPN pa ndryshuar identitetin e saj

Një rinovim certifikate që ndryshon identitetin nuk është rinovim, është një migrim i veshur me një biletë mirëmbajtjeje. Klienti verifikon një emër, një zinxhir dhe ndonjëherë një çelës të caktuar, dhe të tre mund të ndryshojnë pa ndryshuar datën e skadimit. Përpara se të kërkoni një zëvendësim, shkruani çfarë kontrollon klienti në të vërtetë: emrin e hostit ose identitetin e partnerit, qëllimin e certifikatës, politikën e çelësave dhe zinxhirin e lëshuesit. Rinovimi është rutinë ose i koordinuar në varësi të asaj që zëvendësimi ndryshon.

Tre kushte vendosin formën e rinovimit

Tre kushtet janë nëse diçka fikson gjethen, nëse zinxhiri ndryshon dhe kush tjetër verifikon emrin. Përgjigjuni nga ana e klientit dhe jo nga komoditeti i CA-së, sepse klienti është ai që dështon në orën tre të mëngjesit.

Filloni duke inspektuar certifikatën që keni. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName shtyp subjektin, lëshuesin, dritaren e vlefshmërisë dhe emrat për të cilët certifikata është vërtet e vlefshme. Ai fusha e fundit është më e rëndësishmja dhe më e supozuara: një kërkesë rinovimi që lë jashtë një SAN nga i cili klienti varet prodhon një certifikatë teknikisht të vlefshme, por funksionalisht të gabuar. Kopjoni listën e SAN nga certifikata e vjetër në kërkesë në vend që ta shtypni përsëri nga memoria.

Kushti i parë: a fikson diçka gjethen

Nëse klientët besojnë një CA të mirëmbajtur dhe verifikojnë emrin, një rinovim gjetheje me çelës të ri është i padukshëm për ta. Nëse ndonjë klient fikson certifikatën e gjethes, gjurmën e gishtit ose çelësin publik, zëvendësimi është një ndryshim i koordinuar me kalim të ashpër, sepse fiksimi i vjetër nuk mund të verifikojë certifikatën e re.

Zbuloni në cilin rast jeni përpara se të porositni diçka. Një fiksim që askush nuk e dokumentoi mbetet fiksim kur thyhet.

Kushti i dytë: krahasoni fiksimet dhe zinxhirin

Gjurmët e gishtave e bëjnë fiksimin të verifikueshëm: openssl x509 -noout -fingerprint -sha256 -in server.crt në certifikatën e vjetër dhe të re, dhe openssl x509 -noout -pubkey për të krahasuar çelësat publikë. Nëse konfigurimi i klientit, një profil celular ose një depo besimi e një pajisjeje përmban ndonjë nga vlerat, keni një fiksim. Profilet celulare VPN janë një vend fshehjeje i zakonshëm, sepse profili shpërndahet një herë dhe nuk inspektohet më kurrë.

Nëse zëvendësimi vjen nga i njëjti ndërmjetës dhe klienti e ka tashmë ose mund ta marrë, asgjë nuk ndryshon në anën e besimit. Një ndërmjetës i ri, një lëshues tjetër ose një zinxhir i dorëzuar në rendin e gabuar e kthejnë rinovimin në një ndryshim besimi, dhe dështimi duket si një lëshues i panjohur dhe jo si një certifikatë e skaduar.

Kontrolloni zinxhirin që serveri dërgon vërtet me openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, dhe verifikojeni lokalisht me openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Ta bëni këtë përpara ndryshimit ju jep një vijë bazë për krahasim më pas.

Kushti i tretë: kush tjetër verifikon emrin

Një koncentrator VPN, një balancues ngarkese, një sondë monitorimi, një integrim RADIUS ose SAML dhe një profil celular mund të mbajnë secili kopjen e vet të emrit të pritur ose të ankorës së besimit. Rinovimi është momenti kur ato kopje ndryshojnë, sepse certifikata ndryshon dhe kopjet jo.

Listoni çdo konsumator përpara ndryshimit dhe vendosni, për secilin, nëse ka nevojë për përditësim. Ai që harroni është ai që ju telefonon.

Ka edhe një kurth kohor. Inspektoni fillimin e vlefshmërisë si dhe skadimin, sepse një certifikatë e përgatitur për aktivizim të mëvonshëm refuzohet nëse instalohet shumë herët, dhe gabimi duket si problem ore dhe jo si problem përgatitjeje. openssl x509 -noout -dates në skedarin e ri përpara se ta vendosni është një kontroll dy sekondash. Mbani gjithashtu një rrugë rikuperimi të mbështetur dhe konfigurimin e njohur si të mirë, në mënyrë që një rinovim që shkon keq të jetë i kthyeshëm duke rikthyer certifikatën dhe çelësin e mëparshëm.

Vendosni, verifikoni me një vërtetim të ri, pastaj tërhiqni

Një tunel i vendosur pasqyron verifikimin që ndodhi kur u ndërtua, kështu që mund të duket i shëndetshëm ndërsa çdo lidhje e re dështon. Testoni me një vërtetim të ri duke përdorur emrin aktual të shërbimit që përdorin klientët.

Plotësoni kontrollin në nivel aplikacioni që i intereson përdoruesit, dhe konfirmoni dorëzimin e zinxhirit nga këndvështrimi i klientit dhe jo i serverit. Mos i shtypni kontrollet e emrit ose të certifikatës për ta mbajtur tranzicionin të qetë; kjo e kthen një problem kompatibiliteti të përkohshëm në të përhershëm.

Tërhiqni materialin e vjetruar vetëm pasi vendosja të jetë verifikuar, dhe trajtojeni një çelës të komprometuar si një rast krejt tjetër: rinovimi vetëm nuk anulon asgjë, kështu që identiteti i prekur ka nevojë për procesin e anulimit dhe të menaxhimit të sesioneve të vendosjes. RFC 5280 përcakton rregullat e certifikatës dhe të verifikimit të rrugës mbi të cilat qëndron e gjithë kjo. Mbani një rinovim rutinë gjetheje të ndarë nga një zëvendësim CA, në mënyrë që klientët të mos kërkohen të besojnë një lëshues të ri pa arsye.