VPN sertifikatını kimliyini dəyişmədən yeniləmək

Kimliyi dəyişən sertifikat yeniləməsi yeniləmə deyil, texniki xidmət bileti geyinmiş miqrasiyadır. Müştəri adı, zənciri və bəzən konkret açarı yoxlayır və bunların üçü də bitmə tarixi dəyişmədən dəyişə bilər. Əvəzedici istəməzdən əvvəl müştərinin həqiqətən nəyi yoxladığını yazın: host adı və ya qarşı tərəf kimliyi, sertifikatın məqsədi, açar siyasəti və verən zəncir. Yeniləmə, əvəzləmənin bunlardan hansını dəyişdiyindən asılı olaraq adi və ya koordinasiyalı olur.

Yeniləmənin formasını üç şərt müəyyən edir

Üç şərt bunlardır: nəyinsə uc sertifikatı bərkidib-bərkitməməsi, zəncirin dəyişib-dəyişməməsi və adı başqa kimin yoxlaması. Bunlara CA-nın rahatlığından deyil, müştəri tərəfindən cavab verin, çünki gecə saat üçdə uğursuz olan müştəridir.

Əlinizdəki sertifikatı yoxlamaqla başlayın. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName subyekti, verəni, etibarlılıq pəncərəsini və sertifikatın həqiqətən etibarlı olduğu adları çap edir. Son sahə ən vacibidir və ən çox güman ediləndir: müştərinin etibar etdiyi SAN-ı buraxan yeniləmə sorğusu texniki cəhətdən etibarlı, funksional cəhətdən səhv sertifikat yaradır. SAN siyahısını yaddaşdan yenidən yazmaq əvəzinə köhnə sertifikatdan sorğuya köçürün.

Birinci şərt: nəyinsə uc sertifikatı bərkidib-bərkitməməsi

Müştərilər idarə olunan CA-ya etibar edir və adı yoxlayırsa, yeni açarla uc sertifikatının yenilənməsi onlar üçün görünməzdir. Hər hansı müştəri uc sertifikatı, onun barmaq izini və ya açıq açarını bərkidirsə, əvəzləmə sərt keçidlə koordinasiyalı dəyişiklikdir, çünki köhnə bərkitmə yeni sertifikatı yoxlaya bilməz.

Nə sifariş etməzdən əvvəl hansı halda olduğunuzu müəyyənləşdirin. Heç kimin sənədləşdirmədiyi bərkitmə pozulanda da bərkitmə olaraq qalır.

İkinci şərt: bərkitmələri və zənciri müqayisə edin

Barmaq izləri bərkitməni yoxlanıla bilən edir: openssl x509 -noout -fingerprint -sha256 -in server.crt köhnə və yeni sertifikatda, və openssl x509 -noout -pubkey açıq açarları müqayisə etmək üçün. Müştəri konfiqurasiyasında, mobil profildə və ya cihazın etibar anbarında bu dəyərlərdən biri varsa, bərkitməniz var. Mobil VPN profilləri tez-tez gizlənmə yeridir, çünki profil bir dəfə paylanır və bir daha yoxlanılmır.

Əvəzləmə eyni ara sertifikatdan gəlirsə və müştəri o ara sertifikata artıq sahibdirsə və ya onu ala bilirsə, etibar tərəfində heç nə dəyişmir. Yeni ara sertifikat, fərqli verən və ya səhv sıra ilə çatdırılan zəncir yeniləməni etibar dəyişikliyinə çevirir və nasazlıq vaxtı keçmiş sertifikat kimi deyil, naməlum verən kimi görünür.

Serverin həqiqətən göndərdiyi zənciri bununla yoxlayın: openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, və yerli olaraq bununla təsdiqləyin: openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Bunu dəyişiklikdən əvvəl etmək sonra müqayisə üçün baza xətti verir.

Üçüncü şərt: adı başqa kim yoxlayır

VPN konsentratoru, yük balanslaşdırıcısı, monitorinq zondası, RADIUS və ya SAML inteqrasiyası və mobil profil hər biri gözlənilən adın və ya etibar ankerinin öz kopyasını saxlaya bilər. Yeniləmə həmin kopyaların ayrıldığı andır, çünki sertifikat dəyişir, kopyalar isə yox.

Dəyişiklikdən əvvəl hər istehlakçını siyahıya alın və hər biri üçün yeniləmə lazım olub-olmadığını qərarlaşdırın. Unutduğunuz biri sizi çağıran olacaq.

Bir də vaxt tələsi var. Etibarlılığın başlanğıcını da, bitmə tarixini də yoxlayın, çünki sonrakı aktivləşdirmə üçün hazırlanmış sertifikat çox erkən quraşdırılarsa rədd edilir və xəta hazırlıq problemi kimi deyil, saat problemi kimi görünür. openssl x509 -noout -dates yeni faylda yerləşdirmədən əvvəl iki saniyəlik yoxlamadır. Dəstəklənən bərpa yolunu və bilinən yaxşı konfiqurasiyanı da saxlayın ki, səhv gedən yeniləmə əvvəlki sertifikat və açarı bərpa etməklə geri qaytarıla bilsin.

Yerləşdirin, təzə autentifikasiya ilə yoxlayın, sonra çıxarın

Qurulmuş tunel qurularkən baş verən yoxlamanı əks etdirir, ona görə də sağlam görünə bilər, halbuki hər yeni bağlantı uğursuz olur. Müştərilərin istifadə etdiyi faktiki xidmət adı ilə təzə autentifikasiya sınaqdan keçirin.

İstifadəçi üçün vacib olan tətbiq səviyyəli yoxlamanı tamamlayın və zəncirin çatdırılmasını server tərəfdən deyil, müştəri baxışından təsdiqləyin. Keçidi sakit saxlamaq üçün ad və ya sertifikat yoxlamalarını sıxışdırmayın; bu, müvəqqəti uyğunluq problemini daimi bir problemə çevirir.

Köhnə materialı yalnız yerləşdirmə yoxlanıldıqdan sonra çıxarın və kompromisə uğramış açarı tamamilə ayrı hal kimi qəbul edin: yeniləmə tək başına heç nəyi ləğv etmir, ona görə təsirlənmiş kimlik yerləşdirmənin ləğv və sessiya idarəetmə prosesinə ehtiyac duyur. RFC 5280 bütün bunların altındakı sertifikat və yol yoxlama qaydalarını müəyyən edir. Adi uc sertifikat yeniləməsini CA əvəzləməsindən ayrı saxlayın, belə ki, müştərilərdən səbəbsiz yeni verənə etibar etmələri istənməsin.