VPN sertifikato atnaujinimas nekeičiant jo tapatybės

Sertifikato atnaujinimas, kuris keičia tapatybę, nėra atnaujinimas, tai migracija, apsivilkusi priežiūros bilietą. Klientas tikrina vardą, grandinę ir kartais konkretų raktą, ir visi trys gali pasikeisti nepakeitus galiojimo datos. Prieš prašydami pakeitimo, užsirašykite, ką klientas iš tikrųjų tikrina: pagrindinio kompiuterio vardą ar partnerio tapatybę, sertifikato paskirtį, raktų politiką ir išdavėjo grandinę. Atnaujinimas yra rutininis arba suderintas priklausomai nuo to, kurią iš šių dalykų pakeičia pakeitimas.

Trys sąlygos nusprendžia atnaujinimo formą

Trys sąlygos yra: ar kas nors prisega lapą, ar keičiasi grandinė ir kas dar tikrina vardą. Atsakykite į juos iš kliento pusės, o ne dėl CA patogumo, nes klientas ir yra tai, kas sugenda trečią valandą nakties.

Pradėkite nuo turimo sertifikato patikrinimo. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName atspausdina subjektą, išdavėją, galiojimo laikotarpį ir vardus, kuriems sertifikatas iš tikrųjų galioja. Pastarasis laukas yra svarbiausias ir dažniausiai numanomas: atnaujinimo prašymas, kuriame praleidžiamas SAN, kuriuo klientas remiasi, sukuria techniškai galiojantį, bet funkciškai neteisingą sertifikatą. Nukopijuokite SAN sąrašą iš seno sertifikato į prašymą, o ne perrašykite jį iš atminties.

Pirma sąlyga: ar kas nors prisega lapą

Jei klientai pasitiki prižiūrimu CA ir tikrina vardą, lapo atnaujinimas su nauju raktu jiems yra nematomas. Jei bet kuris klientas prisega lapo sertifikatą, jo pirštų atspaudą ar jo viešąjį raktą, pakeitimas yra suderintas pokytis su griežtu perėjimu, nes senas prisegimas negali patvirtinti naujo sertifikato.

Išsiaiškinkite, kokiu atveju esate, prieš ką nors užsakydami. Prisegimas, kurio niekas neužfiksavo, vis tiek yra prisegimas, kai jis lūžta.

Antra sąlyga: palyginkite prisegimus ir grandinę

Pirštų atspaudai leidžia patikrinti prisegimą: openssl x509 -noout -fingerprint -sha256 -in server.crt sename ir naujame sertifikate, o openssl x509 -noout -pubkey viešiesiems raktams palyginti. Jei kliento konfigūracijoje, mobiliajame profilyje ar įrenginio pasitikėjimo saugykloje yra kuri nors iš šių reikšmių, turite prisegimą. Mobilieji VPN profiliai yra įprasta slėptuvė, nes profilis išplatinamas vieną kartą ir daugiau niekada netikrinamas.

Jei pakeitimas gaunamas iš to paties tarpinio sertifikato ir klientas jį jau turi arba gali gauti, pasitikėjimo pusėje niekas nesikeičia. Naujas tarpinis sertifikatas, kitas išdavėjas arba neteisinga tvarka pristatyta grandinė paverčia atnaujinimą pasitikėjimo pokyčiu, o gedimas atrodo kaip nežinomas išdavėjas, o ne kaip pasibaigęs sertifikatas.

Patikrinkite grandinę, kurią serveris iš tikrųjų siunčia, su openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, ir patvirtinkite ją vietoje su openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Tai padaryti prieš pakeitimą suteikia atskaitos tašką vėlesniam palyginimui.

Trečia sąlyga: kas dar tikrina vardą

VPN koncentratorius, apkrovos balansuotojas, stebėjimo zondas, RADIUS arba SAML integracija ir mobilusis profilis kiekvienas gali turėti savo laukiamo vardo ar pasitikėjimo inkaro kopiją. Atnaujinimas yra momentas, kai tos kopijos išsiskiria, nes sertifikatas keičiasi, o kopijos ne.

Išvardykite kiekvieną vartotoją prieš pakeitimą ir nuspręskite, ar kiekvienam reikia atnaujinimo. Tas, kurį pamiršite, yra tas, kuris jums paskambins.

Yra ir laiko spąstų. Patikrinkite galiojimo pradžią ir pabaigą, nes sertifikatas, paruoštas vėlesniam aktyvavimui, atmetamas, jei įdiegiamas per anksti, o klaida atrodo kaip laikrodžio problema, o ne paruošimo problema. openssl x509 -noout -dates naujame faile prieš diegdami yra dviejų sekundžių patikra. Taip pat išlaikykite palaikomą atkūrimo kelią ir žinomą gerą konfigūraciją, kad nepavykusį atnaujinimą būtų galima atšaukti atkuriant ankstesnį sertifikatą ir raktą.

Įdiekite, patvirtinkite nauju autentifikavimu, tada išimkite

Nustatytas tunelis atspindi patvirtinimą, įvykusį jį sukuriant, todėl jis gali atrodyti sveikas, nors kiekvienas naujas ryšys nepavyksta. Išbandykite nauju autentifikavimu naudodami tikrąjį paslaugos pavadinimą, kurį naudoja klientai.

Atlikite programos lygio patikrinimą, kuris rūpi naudotojui, ir patvirtinkite grandinės pristatymą iš kliento, o ne iš serverio perspektyvos. Nenutildykite vardo ar sertifikato patikrinimų, kad perėjimas būtų tylus; tai paverčia laikiną suderinamumo problemą nuolatine.

Pasibaigusį materialą išimkite tik po to, kai įdiegimas patvirtintas, o pažeistą raktą traktuokite kaip visiškai kitą atvejį: vien atnaujinimas nieko neatšaukia, todėl paveiktai tapatybei reikia diegimo atšaukimo ir sesijų tvarkymo proceso. RFC 5280 apibrėžia sertifikato ir kelio patvirtinimo taisykles, kuriomis visa tai remiasi. Laikykite rutininį lapo atnaujinimą atskirai nuo CA pakeitimo, kad klientų nebūtų prašoma be priežasties pasitikėti nauju išdavėju.