IKEv2 სერტიფიკატის დაყენება iPhone-ზე: ხელით ან მართული რეგისტრაცია

RSA-ს არჩევა მხოლოდ იმიტომ, რომ კარიბჭის სერტიფიკატის ინსტრუმენტი ნაგულისხმევად მას იყენებს, გადაწყვეტილებაა, რომელიც მთავარ კითხვამდე მიიღება: როგორ დარეგისტრირდება ეს iPhone-ები? მომხმარებლის მიერ აკრეფილი კავშირი და მართვის მიერ მოწოდებული კონფიგურაციის პროფილი სხვადასხვა პარამეტრს აჩვენებს, და ზოგიერთი სერტიფიკატის არჩევანი მხოლოდ ერთ ამ გზაზე არსებობს. სწორად დაალაგეთ თანმიმდევრობა და სერტიფიკატის გეგმა მოკლე გახდება; შეცდით და გასცემთ სერტიფიკატს, რომელსაც ტელეფონი არ გამოიყენებს. ქვემოთ მოცემული ნაბიჯები განიხილეთ როგორც თანმიმდევრობა, რადგან თითოეული ავიწროებს შემდეგისთვის ხელმისაწვდომ არჩევანს.

პირველი ნაბიჯი: აირჩიეთ რეგისტრაციის გზა

ხელით კონფიგურაცია ნიშნავს, რომ მომხმარებელი შეიყვანს სერვერის მისამართს, აირჩევს ავთენტიფიკაციის მეთოდს და მიაწოდებს ნებისმიერ სერტიფიკატს, რომელსაც ინტერფეისი დაუშვებს. მართული რეგისტრაცია ნიშნავს, რომ პროფილი ატარებს მისამართს, იდენტიფიკატორებს და მითითებას სერტიფიკატის დატვირთვაზე. მართული გზა შეიძლება გამოხატოს ისეთი კომბინაციები, რომლებსაც ხელით ეკრანი ვერ შეძლებს, ამიტომ სერტიფიკატის გადაწყვეტილება ამ არჩევანის შემდეგ უნდა მოვიდეს და არა მანამდე.

ორივე გზას შეუძლია ტელეფონის ავთენტიფიკაცია. ისინი განსხვავდებიან იმით, თუ რისი კონფიგურირება შეიძლება და ვის ეკუთვნის იდენტობა, ამიტომ შეგნებულად აირჩიეთ ერთი, ნაცვლად მართული პროფილისა და ხელით სერტიფიკატის შერევისა.

მეორე ნაბიჯი: აირჩიეთ ალგორითმები არჩეული გზისთვის

ხელით კონფიგურირებული iPhone-ებისთვის strongSwan-ის iOS თავსებადობის შენიშვნები გვირჩევენ RSA სერვერის სერტიფიკატს, რადგან ხელით კლიენტმა შეიძლება არ მიიღოს ECDSA სერვერის სერტიფიკატი; იგივე შენიშვნები macOS-ს ცალკე განიხილავს. წაიკითხეთ ეს როგორც მხარდაჭერილი კლიენტების ნაკრებისთვის მითითება და არა როგორც მუდმივი კანონი Apple-ის მოწყობილობებზე. მართულ პროფილს მეტი სივრცე აქვს: მას შეუძლია სერტიფიკატის ტიპი ცალსახად აირჩიოს, მათ შორის ECDSA კლიენტის იდენტობა, როცა დატვირთვა და კარიბჭე ორივე ამას მხარს უჭერს.

სანამ რამეს განათავსებთ, შეამოწმეთ ის iOS ვერსიები, რომლებსაც ნამდვილად უჭერთ მხარს. უახლეს გამოშვებაზე მყოფი ლაბორატორიული ტელეფონი არ აღწერს პარკს, რომელიც ძველ მოწყობილობებს მოიცავს, და ლაბორატორიაში მომუშავე ალგორითმი მაინც შეიძლება ჩავარდეს ველზე ყველაზე ძველ ტელეფონზე. ვერსიების დიაპაზონი აიღეთ მოწყობილობების მართვიდან და არა მეხსიერებიდან. თუ პარკი რამდენიმე გამოშვებას მოიცავს, ჯერ ყველაზე ძველი შეამოწმეთ, რადგან სწორედ იქ არის ხელით ინტერფეისი ყველაზე შემზღუდველი.

მესამე ნაბიჯი: წაიკითხეთ პროფილის ველები ცალკე რამეებად

რამდენიმე მსგავსი სახელის გასაღები სხვადასხვა ობიექტს აღწერს. დისტანციური მისამართი არის ჰოსტი, რომელსაც ტელეფონი რეკავს. დისტანციური იდენტიფიკატორი არის ის IKE იდენტობა, რომელიც მოსალოდნელია კარიბჭემ წარმოადგინოს. დატვირთვის სერტიფიკატის მითითება კლიენტის სერტიფიკატზე მიუთითებს, ხოლო სერტიფიკატის ტიპის ველი ირჩევს იმ ტიპს, რომელიც IKEv2 მანქანური ავთენტიფიკაციისთვის გამოიყენება. არც ერთი მათგანი არ არის CA-ის ხელმოწერის ალგორითმი, თუმცა სიტყვები ერთმანეთს ემთხვევა.

Apple-ის IKEv2 დატვირთვის მითითება RSA-ს ჩამოთვლის როგორც ნაგულისხმევ სერტიფიკატის ტიპს ცალსახა ECDSA ვარიანტებით, და აკავშირებს გამომცემლის სახელის გასაღებს გარკვეულ ავთენტიფიკაციის პარამეტრებთან. ეს კავშირები წაიკითხეთ არჩეული მეთოდის მითითებაში, ნაცვლად სამუშაო განლაგებიდან ერთი გასაღების კოპირებისა.

მეოთხე ნაბიჯი: შეათანხმეთ კარიბჭის იდენტობა მის სერტიფიკატთან

გამოიყენეთ ცალსახა კარიბჭის სახელი, მაგალითად vpn.example.com და ჩადეთ შესაბამისი ალტერნატიული სუბიექტის სახელი სერვერის სერტიფიკატში. strongSwan-ის Apple სახელმძღვანელო ასევე მოელის გაფართოებული გასაღების გამოყენებას სერვერის ავთენტიფიკაციისთვის. RSA-ის ან ECDSA-ის არჩევა ამას არაფერს ცვლის: ალგორითმს არ შეუძლია სახელის შეუსაბამობის, დაკარგული EKU-ს ან არასრული ჯაჭვის გამოსწორება.

ნდობის საყრდენის გავრცელება ცალკე ამოცანაა იდენტობის დამტკიცებისგან. ტელეფონს სჭირდება სერტიფიკატების ჯაჭვი, რომლის გადამოწმებაც შეუძლია, და ის ისე უნდა იყოს კონფიგურირებული, რომ ელოდოს იმ სახელს, რომელიც ნამდვილად ჩადეთ სერტიფიკატში.

სხვა პლატფორმის წარმატებული დაკავშირება მტკიცებაა ამ პლატფორმის ვალიდაციის წესებზე და არა ნებართვა ტელეფონის წესების შესამსუბუქებლად. შეინარჩუნეთ შემოწმებები იდენტური კლიენტებს შორის, თუ არ გაქვთ დოკუმენტირებული მიზეზი განსხვავებისთვის.

მეხუთე ნაბიჯი: გამოყავით კლიენტის იდენტობა CA-ის ნდობისგან

კლიენტის სერტიფიკატი და მისი კერძო გასაღები არ არის იგივე ობიექტი, რაც CA-ის სერტიფიკატი, რომელსაც ტელეფონი ენდობა. CA-ის სერტიფიკატის PKCS#12 იდენტობაში ჩასმა ავტომატურად არ აყენებს მას ნდობის საყრდენად ყველა მხარდაჭერილ მოწყობილობაზე, ამიტომ ნდობის გავრცელება განიხილეთ როგორც ცალკე ნაბიჯი საკუთარი შემოწმებით.

თუ დიზაინი სამაგიეროდ პაროლზე დაფუძნებულ EAP-ს იყენებს, ტელეფონს სჭირდება განკუთვნილი ანგარიშის ავთენტიფიკაცია და სერვერის ვალიდაცია. ეს გზა არ ამართლებს ერთი საერთო კლიენტის კერძო გასაღების გაგზავნას მთელ პარკზე, რაც სხვა დიზაინია და გაცილებით უარესი წარუმატებლობის რეჟიმით.

დაასრულეთ გეგმა განახლებისა და გაუქმების გათვალისწინებით: ვინ თავიდან გასცემს კლიენტის სერტიფიკატს, როგორ განახლდება პროფილი და როგორ წყდება დაკარგული ტელეფონი. ჩაწერეთ პროფილის ვერსია და ის მოწყობილობის ვერსიები, რომელთა წინააღმდეგაც შეამოწმეთ, რადგან სწორედ ეს ჩანაწერი ხდის შემდეგ სერტიფიკატის ცვლილებას ჩვეულებრივ სამუშაოდ.