რომელი PKCS#11 URI სჭირდება OpenConnect-ს ტოკენისთვის?

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

რა სურს კლიენტს ექსპორტირებული გასაღების ნაცვლად

-c პარამეტრი ჩვეულებრივ ფაილის გზას იღებს, მაგრამ როცა მნიშვნელობა PKCS#11 URI-დ არის გაანალიზებული, OpenConnect მას ტოკენის შიგნით არსებულ ობიექტზე მითითებად თვლის და არა დისკზე არსებულ ფაილზე. -k პარამეტრი პირადი გასაღებისთვის იგივენაირად იქცევა. არაფერი ექსპორტირდება და გასაღები არასოდეს ტოვებს იმ დაცვას, რომელსაც ბარათი იძლევა. რაც კლიენტს თქვენგან სჭირდება, არის სახელი, რომელზეც ტოკენის მოდული, სერტიფიკატების საცავი და კარიბჭის ჩანაწერი თანხმდებიან.

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

ორი URI, ორი განსხვავებული საქმე

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

გასაღების URI პასუხობს, სად არის შესაბამისი პირადი მასალა, როცა OpenConnect ვერ ასკვნის. მხოლოდ -c-ის დაყენებით კლიენტი სერტიფიკატის თვისებებიდან აშენებს გასაღების ძიებას; -k-ის მიწოდება ვარაუდს ცვლის ობიექტის მკაფიო მითითებით. ტოკენის PIN მესამე, დაუკავშირებელი შეყვანაა: ის ხსნის ბარათს ოპერაციისთვის და არასოდეს იდენტიფიცირებს ობიექტს.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

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

თქვენი ჩანაწერის შესაბამისი URI-ის პოვნა

GnuTLS-ს მოჰყვება p11tool, რომელიც ჩამოთვლის, თუ რას აღწევს მიმდინარე მომხმარებელი რეალურად p11-kit-ის მეშვეობით. დაიწყეთ p11tool --list-tokens-ით, შემდეგ ჩამოთვალეთ სერტიფიკატის ობიექტები იმ ტოკენზე, რომელიც გაინტერესებთ. დაამატეთ --login, როცა ობიექტები მხოლოდ PIN-ის შემდეგ ჩნდება, და შეადარეთ სუბიექტი და გამომცემელი ჩანაწერის ჟურნალს, ნაცვლად იმისა, რომ პირველი გამოჩენილი აირჩიოთ.

თუ ტოკენი საერთოდ არ ჩანს, პრობლემა OpenConnect-ის ქვემოთაა: p11-kit-ს ამ შუამავალი პროგრამისთვის რეგისტრირებული მოდული არ აქვს, ან მოდული სხვა ანგარიშისთვისაა რეგისტრირებული. სისტემური დონის რეგისტრაცია /etc/pkcs11/modules-ის ქვეშაა, ხოლო მომხმარებლისეულ საქაღალდეს შეუძლია იგივე შეინახოს სისტემის ასლზე ხელის შეუხებლად. შეამოწმეთ, რომ მოდულის ფაილში მომწოდებლის გზა მიუთითებს იმ ბიბლიოთეკაზე, რომელიც მკითხველის პროგრამულმა უზრუნველყოფამ რეალურად დააყენა.

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

როცა ავტომატური გასაღების ძიება კარგავს იმედს

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

სანამ კლიენტს დაადანაშაულებთ, დაადასტურეთ, რომ გასაღები არსებობს და ჩანს p11tool --list-keys-ით. შემდეგ შეამოწმეთ, რომ ობიექტი მონიშნულია ხელმოწერისა ან გაშიფვრისთვის გამოსადეგად, რადგან არასწორი ატრიბუტებით შექმნილი გასაღები ვერ დაასრულებს ხელის ჩამორთმევას, რაც არ უნდა სწორი იყოს URI. ნუ გადაიტანთ სერიალიზებულ pkcs11-id მნიშვნელობას OpenVPN პროფილიდან OpenConnect პარამეტრში; ორი კლიენტი სხვადასხვა იდენტიფიკატორის ფორმატს იყენებს, თუნდაც ერთ ბარათს ესაუბრებოდეს.

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

წარუმატებლობები, რომლებიც მხოლოდ URI-ის პრობლემებს ჰგავს

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

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

იმუშავეთ ობიექტიდან გარეთ: ხედავს p11tool ტოკენს, ხედავს სერტიფიკატსა და გასაღებს, იღებს OpenConnect URI-ს და მხოლოდ ამის შემდეგ იკითხეთ, იღებს კარიბჭე იდენტობას. ყოველ საფეხურს თავისი შეცდომის შეტყობინება აქვს და ყოველი მომდევნოზე იაფად საცდელია.