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

რასაც კლიენტი ითხოვს, იდენტობაა

Apple-ის უსაფრთხოების ჩარჩო სერთიფიკატსა და იდენტობას სხვადასხვა ობიექტად განიხილავს. სერთიფიკატი საჯარო მონაცემია. იდენტობა არის ის სერთიფიკატი პლუს მისი პირადი გასაღები, და მხოლოდ იდენტობას შეუძლია გამოწვევის დასრულება. სანდო CA სერთიფიკატი კი კლიენტს გამომცემლის შეფასების საშუალებას აძლევს; ის მანქანას გამოცემული კლიენტური სერთიფიკატის მფლობელად არ აქცევს.

ItemWhat it can doWhat it cannot do
CA or server certificateValidate the gateway's chainAuthenticate this client
Client certificate without keyNothing for authenticationProve possession of anything
Identity (cert plus key)Answer the authentication challengeGuarantee the gateway accepts it

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

სამი მიზეზი, რატომ რჩება ამრჩევი ცარიელი

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

security find-identity -v -p ssl-client

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

სად ცხოვრობს პირადი გასაღები და ვის შეუძლია მისი გამოყენება

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

System Roots ნდობის კოლექციაა. მასში სერთიფიკატის დადება ცვლის, თუ რომელ გამომცემლებს ენდობა სისტემა; ის პირად გასაღებს არ ქმნის და იდენტობების საცავი არ არის. ამრჩევის შესავსებად შეუსაბამო სერთიფიკატების გადაადგილება იმ ტიპის შეკეთებაა, რომელიც მანქანას სამუდამოდ გაფართოებული ნდობის ნაკრებით ტოვებს.

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

როგორ მიუთითებს პროფილი სერთიფიკატზე

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

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

არჩევა და მიღება ცალკე ეტაპებია

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

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

დაკავშირებული სტატიები