სანამ გადააკეთებთ: SSH გასაღები OpenVPN სერტიფიკატის წინააღმდეგ

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

რომელი ობიექტი გაქვთ სინამდვილეში?

ხუთი რამ არსებობს, რომელსაც ხალხი გასაღებს უწოდებს, და მათგან მხოლოდ ერთია ის, რასაც TLS პროფილი ითხოვს. SSH საჯარო გასაღები ერთი ხაზის ტექსტია ტიპის პრეფიქსითა და base64 შიგთავსით. OpenSSH სერტიფიკატი ეს გასაღებია, დამატებული ხელმოწერით, principals-ითა და ოფციებით, რომელსაც ssh-keygen აწარმოებს, როგორც საკუთარი პატარა CA. X.509 სერტიფიკატი სრულიად სხვა სტრუქტურაა: ატარებს სუბიექტს, ვალიდურობის ფანჯარას, გაფართოებებს და სერტიფიკატის ორგანოს ხელმოწერას. პირადი გასაღები საიდუმლო ნახევარია, ხოლო გამოცემული პაკეტი ჩვეულებრივ სერტიფიკატია მისი ჯაჭვითა და პირადი გასაღებით ერთ ფაილში.

პირველი ტესტი ერთი ბრძანება ღირს. მიუთითეთ openssl ფაილზე და სთხოვეთ სერტიფიკატის სტრუქტურის ანალიზი:

openssl x509 -in client.crt -noout -subject -issuer

თუ ეს ჩავარდა unable-to-load ან PEM შეცდომით, ფაილი X.509 სერტიფიკატი არ არის, რაც არ უნდა დაარქვათ. სახელის შეცვლა შიგნით ASN.1-ს არ გადაწერს, და არც საჯარო გასაღების ხაზის PEM სათაურის ტექსტში გახვევა.

საერთოდ ითხოვს პროფილი სერტიფიკატს?

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

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

რა შეუძლია და რა არ შეუძლია ხელახალ კოდირებას

პირად გასაღებებს ნამდვილად აქვთ ლეგიტიმური ალტერნატიული კონტეინერები. იგივე RSA ან EC გასაღები შეიძლება ჩაიწეროს როგორც ტრადიციული PEM, როგორც PKCS#8, ან PKCS#12 პაკეტის შიგნით, და ხელსაწყოები სიამოვნებით გარდაქმნიან მათ შორის. საჯარო გასაღებებსაც მსგავსი ამბავი აქვთ: ssh-keygen შეუძლია SSH გასაღების RFC 4716 ფორმის გამოტანა, ხოლო OpenSSH საკუთარ სერტიფიკატის ფორმატსაც იცნობს. ეს ყველაფერი წარმოდგენაა, და წარმოდგენა ნდობა არ არის.

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

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

სად შემოდის სურათში სერტიფიკატის ორგანო

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

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

რა ჯდება SSH გასაღების ხელახლა გამოყენება

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

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