iPhone-da IKEv2 sertifikat quruluşu: əl ilə və idarə olunan qeydiyyat

RSA-nı seçmək yalnız ona görə ki şlüzün sertifikat aləti defolt olaraq ondan istifadə edir, əsl sualdan əvvəl verilən qərardır: bu iPhone-lar necə qeydiyyata alınacaq? İstifadəçinin əl ilə daxil etdiyi bağlantı ilə idarəetmənin çatdırdığı konfiqurasiya profili fərqli parametrlər təqdim edir və bəzi sertifikat seçimləri yalnız bu yollardan birində mövcuddur. Sıranı düzgün qursanız, sertifikat planı qısa olur; səhv qursanız, telefonun istifadə etməyəcəyi bir etimadnamə verirsiniz. Aşağıdakı addımları ardıcıllıq kimi qəbul edin, çünki hər biri növbəti addım üçün mövcud seçimləri daraldır.

Birinci addım: qeydiyyat yolunu seçin

Əl ilə quraşdırma istifadəçinin server ünvanını daxil etməsi, autentifikasiya metodunu seçməsi və interfeysin icazə verdiyi istənilən etimadnaməni təqdim etməsi deməkdir. İdarə olunan qeydiyyat isə profil ünvanı, identifikatorları və etimadnamə yükünə istinadı daşıyır. İdarə olunan yol əl ekranının ifadə edə bilmədiyi kombinasiyaları ifadə edə bilir, buna görə sertifikat qərarı bu seçimdən sonra, ondan əvvəl deyil, gəlməlidir.

Hər iki yol telefonu autentifikasiya edə bilər. Onlar nəyi konfiqurasiya edə bildiyinizə və kimliyin kimə məxsus olduğuna görə fərqlənir, ona görə idarə olunan profili əl ilə etimadnamə daxil etməklə qarışdırmaq əvəzinə birini qəsdən seçin.

İkinci addım: seçdiyiniz yol üçün alqoritmləri seçin

Əl ilə konfiqurasiya edilmiş iPhone-lar üçün strongSwan-ın iOS uyğunluq qeydləri RSA server sertifikatını tövsiyə edir, çünki əl müştərisi ECDSA server sertifikatını qəbul etməyə bilər; həmin qeydlər macOS-u ayrıca nəzərdən keçirir. Bunu dəstəklənən müştəri dəsti üçün göstəriş kimi oxuyun, Apple cihazları haqqında daimi qanun kimi deyil. İdarə olunan profilin daha çox imkanı var: yük və şlüz birlikdə dəstəklədikdə, o, sertifikat növünü açıq şəkildə seçə bilər, o cümlədən ECDSA müştəri kimliyini.

Hər şeyi yayımlamadan əvvəl həqiqətən dəstəklədiyiniz iOS versiyalarını yoxlayın. Ən yeni buraxılışdakı laboratoriya telefonu köhnə cihazları əhatə edən parkı təsvir etmir və laboratoriyada işləyən alqoritm sahədəki ən köhnə telefonda yenə də uğursuz ola bilər. Versiya aralığını yaddaşınızdan deyil, cihaz idarəetməsindən götürün. Park bir neçə buraxılışı əhatə edirsə, əvvəlcə ən köhnəsini sınaqdan keçirin, çünki əl interfeysi ən çox orada məhdudlaşdırır.

Üçüncü addım: profil sahələrini ayrı-ayrı şeylər kimi oxuyun

Oxşar adlı bir neçə açar fərqli obyektləri təsvir edir. Uzaq ünvan telefonun yığdığı hostdur. Uzaq identifikator onun şlüzün təqdim etməsini gözlədiyi IKE kimliyidir. Yükün sertifikat istinadı müştəri etimadnaməsinə işarə edir və sertifikat növü sahəsi IKEv2 maşın autentifikasiyası üçün istifadə olunan növü seçir. Bunların heç biri CA-nın imza alqoritmi deyil, hərçənd sözlər üst-üstə düşür.

Apple-ın IKEv2 yük istinadı RSA-nı açıq ECDSA variantları ilə defolt sertifikat növü kimi sadalayır və emitent adı açarını müəyyən autentifikasiya parametrlərinə bağlayır. Bu əlaqələri işləyən bir yerləşdirmədən bir açar kopyalamaq əvəzinə, seçdiyiniz metod üçün istinaddan oxuyun.

Dördüncü addım: şlüzün kimliyini sertifikatına uyğunlaşdırın

Məsələn vpn.example.com kimi açıq şlüz adı istifadə edin və uyğun alternativ subyekt adını server sertifikatına yerləşdirin. strongSwan-ın Apple təlimatı həmçinin server autentifikasiyası üçün genişləndirilmiş açar istifadəsini gözləyir. RSA və ya ECDSA seçmək bunların heç birini dəyişmir: alqoritm ad uyğunsuzluğunu, çatışmayan EKU-nu və ya natamam zənciri düzəldə bilməz.

Etibar ankerini paylamaq kimliyi təsdiqləməkdən ayrı bir vəzifədir. Telefona doğrulaya biləcəyi sertifikat zənciri lazımdır və o, sertifikata həqiqətən qoyduğunuz adı gözləmək üçün konfiqurasiya edilməlidir.

Başqa platformanın uğurla qoşulması həmin platformanın doğrulama qaydaları haqqında sübutdur, telefonun qaydalarını yumşaltmaq üçün icazə deyil. Fərqlənmək üçün sənədləşdirilmiş səbəbiniz yoxdursa, yoxlamaları müştərilər arasında eyni saxlayın.

Beşinci addım: müştəri kimliyini CA etibarından ayırın

Müştəri sertifikatı və onun şəxsi açarı telefonun etibar etdiyi CA sertifikatı ilə eyni obyekt deyil. CA sertifikatını PKCS#12 kimliyinin içində birləşdirmək onu hər dəstəklənən cihazda avtomatik olaraq etibar ankeri kimi quraşdırmır, ona görə etibarın paylanmasını öz yoxlaması olan ayrı bir addım kimi qəbul edin.

Əgər dizayn əvəzinə parol əsaslı EAP istifadə edirsə, telefona nəzərdə tutulan hesab autentifikasiyası və server doğrulaması lazımdır. Bu yol bütün parka bir ortaq müştəri şəxsi açarı paylamağı əsaslandırmır, çünki bu, daha pis uğursuzluq rejimi olan fərqli bir dizayndır.

Planı yenilənmə və ləğvi nəzərə alaraq bitirin: müştəri etimadnaməsini kimin yenidən verdiyi, profilin necə yeniləndiyi və itirilmiş telefonun necə kəsildiyi. Profil versiyasını və yoxladığınız cihaz versiyalarını qeyd edin, çünki növbəti sertifikat dəyişimini adi bir əməliyyata çevirən məhz bu qeyddir.