VPN sertifikāta atjaunošana, nemainot tā identitāti
Atjaunošana saglabā vārdus, mērķus un ķēdi, kuriem klients jau uzticas. Trīs nosacījumi izlemj, vai tā ir rutīna, vai saskaņotas uzticības izmaiņas.
Sertifikāta atjaunošana, kas maina identitāti, nav atjaunošana, tā ir migrācija uzturēšanas biļetes tērpā. Klients pārbauda vārdu, ķēdi un dažkārt konkrētu atslēgu, un visas trīs var mainīties, nemainot derīguma termiņu. Pirms pieprasāt aizstāšanu, pierakstiet, ko klients patiešām pārbauda: resursdatora nosaukumu vai partnera identitāti, sertifikāta mērķi, atslēgu politiku un izdevēja ķēdi. Atjaunošana ir rutīna vai saskaņota atkarībā no tā, ko no tiem maina aizstāšana.
Trīs nosacījumi izlemj atjaunošanas formu
Trīs nosacījumi ir: vai kaut kas piefiksē lapu, vai mainās ķēde un kas vēl pārbauda vārdu. Atbildiet uz tiem no klienta puses, nevis no CA ērtībām, jo klients ir tas, kas neizdodas trijos naktī.
Sāciet ar esošā sertifikāta pārbaudi. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName izdrukā subjektu, izdevēju, derīguma logu un vārdus, kuriem sertifikāts patiešām ir derīgs. Pēdējais lauks ir vissvarīgākais un visbiežāk tiek pieņemts: atjaunošanas pieprasījums, kas izlaiž SAN, uz kuru klients paļaujas, rada sertifikātu, kas ir tehniski derīgs, bet funkcionāli nepareizs. Kopējiet SAN sarakstu no vecā sertifikāta pieprasījumā, nevis ierakstiet to no jauna no atmiņas.
Pirmais nosacījums: vai kaut kas piefiksē lapu
Ja klienti uzticas uzturētam CA un pārbauda vārdu, lapas atjaunošana ar jaunu atslēgu viņiem ir neredzama. Ja kāds klients piefiksē lapas sertifikātu, tā pirksta nospiedumu vai tā publisko atslēgu, aizstāšana ir saskaņota izmaiņa ar stingru pāreju, jo vecā piefiksēšana nevar apstiprināt jauno sertifikātu.
Noskaidrojiet, kurā gadījumā esat, pirms kaut ko pasūtāt. Piefiksēšana, ko neviens nav dokumentējis, joprojām ir piefiksēšana, kad tā lūzt.
Otrais nosacījums: salīdziniet piefiksējumus un ķēdi
Pirkstu nospiedumi padara piefiksēšanu pārbaudāmu: openssl x509 -noout -fingerprint -sha256 -in server.crt vecajā un jaunajā sertifikātā, un openssl x509 -noout -pubkey publisko atslēgu salīdzināšanai. Ja klienta konfigurācijā, mobilajā profilā vai ierīces uzticības krātuvē ir kāda no šīm vērtībām, jums ir piefiksēšana. Mobilie VPN profili ir izplatīta slēptuve, jo profils tiek izplatīts vienreiz un vairs nekad netiek pārbaudīts.
Ja aizstāšana nāk no tā paša starpposma un klients to jau ir ieguvis vai var iegūt, uzticības pusē nekas nemainās. Jauns starpposms, cits izdevējs vai nepareizā secībā piegādāta ķēde pārvērš atjaunošanu uzticības izmaiņās, un kļūme izskatās kā nezināms izdevējs, nevis kā beidzies sertifikāts.
Pārbaudiet ķēdi, ko serveris patiešām sūta, ar openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, un apstipriniet to lokāli ar openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. To izdarīt pirms izmaiņām dod jums bāzes līniju vēlākam salīdzinājumam.
Trešais nosacījums: kas vēl pārbauda vārdu
VPN koncentrators, slodzes līdzsvarotājs, uzraudzības zonde, RADIUS vai SAML integrācija un mobilais profils katrs var turēt savu gaidāmā vārda vai uzticības enkura kopiju. Atjaunošana ir brīdis, kad šīs kopijas atšķiras, jo sertifikāts mainās, bet kopijas ne.
Uzskaitiet katru lietotāju pirms izmaiņām un izlemiet, vai katram nepieciešams atjauninājums. Tas, ko aizmirsīsiet, ir tas, kas jums piezvanīs.
Ir arī laika slazds. Pārbaudiet derīguma sākumu, kā arī beigas, jo sertifikāts, kas sagatavots vēlākai aktivizācijai, tiek noraidīts, ja to instalē pārāk agri, un kļūda izskatās kā pulksteņa problēma, nevis sagatavošanas problēma. openssl x509 -noout -dates jaunajā failā pirms izvietošanas ir divu sekunžu pārbaude. Saglabājiet arī atbalstītu atkopšanas ceļu un zināmo labo konfigurāciju, lai neizdevušos atjaunošanu varētu atcelt, atjaunojot iepriekšējo sertifikātu un atslēgu.
Izvietojiet, apstipriniet ar svaigu autentifikāciju, pēc tam izņemiet
Izveidots tunelis atspoguļo validāciju, kas notika, kad tas tika būvēts, tāpēc tas var izskatīties veselīgs, kamēr katrs jauns savienojums neizdodas. Pārbaudiet ar svaigu autentifikāciju, izmantojot īsto pakalpojuma nosaukumu, ko izmanto klienti.
Pabeidziet lietojumprogrammas līmeņa pārbaudi, kas lietotājam ir svarīga, un apstipriniet ķēdes piegādi no klienta, nevis servera perspektīvas. Nepārtrauciet vārda vai sertifikāta pārbaudes, lai pāreja būtu klusa; tas pārvērš īslaicīgu saderības problēmu pastāvīgā.
Izņemiet novecojušu materiālu tikai pēc tam, kad izvietošana ir apstiprināta, un apdraudētu atslēgu uzskatiet par pilnīgi citu gadījumu: atjaunošana vien pati neko neatsauc, tāpēc skartajai identitātei nepieciešams izvietošanas atsaukšanas un sesiju pārvaldības process. RFC 5280 definē sertifikāta un ceļa validācijas noteikumus, kas ir visa šī pamatā. Turiet rutīnas lapas atjaunošanu atsevišķi no CA aizstāšanas, lai klientiem netiktu lūgts bez iemesla uzticēties jaunam izdevējam.