Atnaujintas VPN sertifikatas: kai kurie klientai vis dar jį atmeta

Pusė aplinkos vėl prisijungia po atnaujinimo, o trys įrenginiai atmeta, kiekvienas su įspėjimu apie šliuzo tapatybę. Pats atnaujinimas yra įprastas. Tai, ką tie trys įrenginiai laiko, yra prisegimas prie seno objekto, ir prisegimas nėra CA sąrašas, pavadinimo patikra ar pasitikėjimo saugyklos įrašas. Palyginkite tris mechanizmus prieš liesdami bet kurį klientą.

Vienas atnaujinimas, du elgesiai

Klientai, kurie prisijungia iš naujo, turi pasitikėjimo sprendimą, kuris dar praeina, o tie, kurie atmeta, turi reikalavimą, kurio naujasis sertifikatas netenkina. Tas skirtumas yra informacija, o ne triukšmas. Atidžiai perskaitykite nepavykusio kliento pranešimą. Pavadinimo nesutapimas, nežinomas išdavėjas ir pasikeitęs piršto atspaudas yra trys skirtingi nuosprendžiai, ir tik paskutinis nurodo prisegimą.

Taip pat patikrinkite, kurį profilį pasirinko nepavykęs klientas. Importuota kopija, gyvenanti savo saugykloje, nesikeičia, kai administratorius redaguoja originalų failą kitur.

Atnaujinimas pakeičia objektą, o ne tik datą

Piršto atspaudas identifikuoja užkoduotą sertifikato turinį. Atnaujinimas sukuria naują sertifikatą, todėl piršto atspaudas pasikeičia net kai subjekto pavadinimas ir viešasis raktas lieka tokie patys. Tai tikėtina ir nekenksminga klientams, kurie pasitiki CA ir tikrina pavadinimą. Tai pražūtinga klientui, sukonfigūruotam priimti tiksliai vieną sertifikatą, ir taip pat pražūtinga klientui, kurio pasitikėjimo saugykla niekada negavo naujo išdavėjo.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

Antroji eilutė atsako į kitą klausimą, ar raktų pora išliko. Atnaujinimas, kuris naudoja raktą iš naujo, išlaiko tą reikšmę ir keičia tik sertifikatą, ir būtent tai yra atvejis, kai administratorius linkęs manyti, kad niekas nepasikeitė. Tikrinkite sertifikatą, kuris įdiegtas, o ne tą, kuris yra kūrimo serveryje. Failo saugykloje palyginimas įrodo, kas buvo sugeneruota, o ne tai, ką klausytojas šiuo metu pateikia.

Perskaitykite, ką klientas prisega

Kai kurie klientai laiko piršto atspaudą savo profilyje ir lygina jį per kiekvieną ryšį. Kiti saugo jį platformos pasitikėjimo saugykloje, o dar kiti pasikliauja tik CA. Taisymas kiekvienu atveju skiriasi, todėl pirmiausia nustatykite mechanizmą.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

Pirmoji komanda rodo prisegimą įprastame profilyje; antroji rodo piršto atspaudą, kurį galinis taškas tikrai pateikia dabar. Kai šie du skiriasi, jūs radote gedimą nespėliodami. Neįklijuokite naujos reikšmės į kiekvieną besiskundžiantį klientą. Klientas, atmetantis dėl išdavėjo, ir toliau atmes, o jūs būsite įtikinę save, kad problema buvo piršto atspaudas, nors taip nebuvo.

Palyginkite sertifikatą, kurį pateikia kiekvienas backend

Nutrūkstantys rezultatai paprastai reiškia daugiau nei vieną galinį tašką, o viename mazge pritaikytas atnaujinimas palieka kitus pateikti seną objektą. Palyginkite kiekvieną backend pagal adresą, o ne pagal bendrą pavadinimą.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

Telkinys, kuriame vienas mazgas atsilieka, paaiškina klientą, kuris prisijungia antruoju bandymu ir nepavyksta pirmuoju. Tai taip pat paaiškina stebėjimo patikrą, kuri praeina, kol naudotojai skundžiasi. Pirmiausia ištaisykite atsilikimą. Pasitikėjimo konfigūracijos perkėlimas prieš tai, kai kiekvienas mazgas pateikia naują sertifikatą, sukuria langą, kuriame niekas neveikia, o perkėlimas po to palieka klientus nepastoviai nepavykstančius.

Pakeiskite pasitikėjimą valdomu keliu

Patvirtinkite pakeitimą jau patikimu administravimo kanalu prieš priimdami jį bet kur. Tikėtina galiojimo pabaigos data nėra nuosavybės įrodymas. Atnaujinkite valdomą konfigūraciją per procesą, kuris ją valdo, su bet kokiu suplanuotu priimtinų tapatybių persidengimu, ir išlaikykite diegimo reikalaujamą pavadinimo patikrą. Prisegimas be pavadinimo patikros yra silpnesnis sprendimas nei CA pasitikėjimas, kurį jis pakeitė.

Tada patikrinkite kiekvieną klientą, prisijunkite, patvirtinkite jo priimtą tapatybę ir užsirašykite sertifikato versiją, kuria jis dabar pasitiki. Kartą atmestas įspėjimas linkęs grįžti per kitą atnaujinimą.