რას ამოწმებს თქვენი VPN კლიენტი სერტიფიკატის ენდობამდე
გაატარეთ სერტიფიკატის გაფრთხილება ოთხ კარიბჭეში, რომლებსაც თქვენი კლიენტი ამოწმებს: CA-ს ნდობა, ჯაჭვის აგება, თანატოლის სახელი და დანიშნულება და გაუქმების პოლიტიკა.
თქვენი VPN კლიენტი ამბობს, რომ სერტიფიკატის გადამოწმება ვერ მოხერხდა, და დიალოგი იქ წყდება. ფაილი არსებობს, სერვერი მუშაობს, და იგივე პროფილი გასულ თვეში სხვა ლეპტოპზე მუშაობდა. იმ ერთსტრიქონიანი გაფრთხილების ქვეშ კლიენტმა თანატოლის სერტიფიკატი ოთხ კარიბჭეში გაატარა: თქვენ მიერ კონფიგურირებული სერტიფიკატის უფლებამოსილება იძლევა გარანტიას ხელმოწერის ბილიკზე, ეს ბილიკი აღწევს უფლებამოსილებამდე, თანატოლის სახელი არის ის, რაც მოითხოვეთ, და სერტიფიკატი ახლა გამოსაყენებელია ამ დანიშნულებისთვის. იპოვეთ დახურული კარიბჭე და შეკეთება, როგორც წესი, ერთი ფაილია; გამოტოვეთ ეს ნაბიჯი და მთელი შუადღე პაკეტებს ხელახლა შემოიტანთ.
წაიკითხეთ დიალოგი პროფილის რედაქტირებამდე
სერტიფიკატის შეცდომების ფორმულირებას ქვემოთ მდებარე ბიბლიოთეკა აკეთებს და არა თქვენ მიერ დაინსტალირებული VPN პროდუქტი, ამიტომ ზუსტი სტრიქონი თქვენი პირველი მტკიცებულებაა. „ლოკალური გამომცემლის სერტიფიკატის მიღება ვერ ხერხდება“ მიუთითებს ბილიკზე ან ნდობის საყრდენზე. „სერტიფიკატის ვადა ამოიწურა ან ჯერ არ არის ძალაში“ მიუთითებს დროზე. „სერტიფიკატის დანიშნულება მხარდაჭერილი არ არის“ მიუთითებს გაფართოებულ გასაღების გამოყენებაზე. სახელის შეუსაბამობა გეუბნებათ, რომელი სახელი სურდა. ოთხიდან არცერთი არ სწორდება კლიენტის ხელახლა დაყენებით.
სანამ რამეს შეცვლით, აწიეთ ჟურნალის დონე. OpenVPN იტყობინება გადამოწმების წარუმატებლობაზე ხელის ჩამორთმევის გარშემო, როცა მას --verb 4-ით გაუშვებთ, ხოლო strongSwan თავის იდენტობისა და ჯაჭვის გადაწყვეტილებებს charon ჟურნალში წერს. შემდეგ დაადასტურეთ, რომელ სერტიფიკატს ამოწმებთ, რადგან ადამიანები ჩვეულებრივ დისკზე არსებულ ფაილს სცდიან, მაშინ როცა პროფილი ძველ ასლს შიგნით დებს. როცა პროფილი PEM ბლოკებს შიგნით დებს, სწორედ შიგნით ჩადებული სერტიფიკატი მოწმდება.
სერტიფიკატის უფლებამოსილება ხელს აწერს იდენტობებს და არა ნებართვებს
უფლებამოსილება ინახავს სახელს და ხელმოწერის გასაღებს. ის გასცემს სერტიფიკატებს, რომლებიც საჯარო გასაღებს ამ სახელს უკავშირებს საკუთარი პოლიტიკის მიხედვით, ვალიდურობის ფანჯრითა და გამოყენების შეზღუდვებით. თქვენს კლიენტს გამომცემლის ამოსაცნობად მხოლოდ უფლებამოსილების სერტიფიკატი სჭირდება; ხელმოწერის გასაღები მას არასდროს სჭირდება, და ამ გასაღების კლიენტებზე გაგზავნა მისცემდა მათ ნებისმიერი იდენტობის შექმნის უნარს, რომელსაც განლაგება ენდობა.
უფლებამოსილების ნდობა მის მიერ ხელმოწერილ ყველა სერტიფიკატს კანდიდატად აქცევს და არა სწორ თანატოლად. იმავე შიდა CA-ს ვებ სერვერის სერტიფიკატიც კანდიდატია. ამიტომ არსებობს სახელისა და დანიშნულების კარიბჭეები და ამიტომ კომპრომეტირებული CA გასაღები უფრო მნიშვნელოვანია, ვიდრე ნებისმიერი ცალკე სერვერი: ის აღწევს ყველა იდენტობამდე, რომელიც უფლებამოსილებას ოდესმე გამოუცია. გასცეთ კლიენტის სერტიფიკატები თითო მოწყობილობაზე, რათა დაკარგული ლეპტოპი იყოს ერთი გაუქმება და არა მთელი განლაგების გასაღების განახლება.
თავიდან ააგეთ ბილიკი, რომლის აგებასაც კლიენტი ცდილობს
ბილიკი იწყება თანატოლის სერტიფიკატიდან, გადის ნულ ან მეტ შუალედურ სერტიფიკატში და მთავრდება თქვენი ნდობის საცავის ფესვთან. დაკარგული შუალედური სერტიფიკატი ჯაჭვის ყველაზე გავრცელებული ხარვეზია, და კლიენტის მხრიდან ის ზუსტად ისე გამოიყურება, როგორც არასანდობი ფესვი. ჯერ ფურცელი წაიკითხეთ, შემდეგ კი ნება მიეცით OpenSSL-ს ააგოს ბილიკი იმ მასალისგან, რომლის გაგზავნასაც აპირებთ.
openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crtნულოვანი გასვლის სტატუსი ნიშნავს, რომ ბილიკი ამ ფაილებიდან აშენდა; წარუმატებლობა ასახელებს სერტიფიკატს, რომლამდე ვერ მიაღწია. თუ openssl verify წარმატებულია, კლიენტი კი მაინც უარყოფს, განსხვავება იმაშია, თუ რას აგზავნის სერვერი სინამდვილეში ან რომელ ნდობის ფაილს ტვირთავს პროფილი. OpenVPN-ში შუალედური სერტიფიკატები შეიძლება მოჰყვეს სერვერის სერტიფიკატის ფაილს ან ცალკე მიეწოდოს --extra-certs-ით, და პაკეტი ორი ფესვით იმავე სუბიექტის სახელქვეშ თქვენი ერთ-ერთ კლიენტს არასწორ ტოტში გაგზავნის.
სახელი და დანიშნულება ცალკე კარიბჭეებია
ჯაჭვის აგება არასდროს იკითხავს, თქვენია თუ არა სახელი. OpenVPN მას ამოწმებს მხოლოდ მაშინ, როცა პროფილი აყენებს --verify-x509-name-ს, და მხოლოდ საერთო სახელის შედარების ძველი ჩვევა ტყდება იმ სერტიფიკატებზე, რომელთა იდენტობებიც subjectAltName-ში ცხოვრობს. IKEv2 განლაგებები კონფიგურირებულ იდენტობას ადარებენ SAN ჩანაწერებს ან გამომყოფ სახელს, კლიენტის მიხედვით, და wildcard ან %any მნიშვნელობა ჩუმად თიშავს იმ შედარებას, რომელიც გეგონათ გქონდათ.
შემდეგ მოდის დრო და დანიშნულება. ლეპტოპი, რომლის საათიც რამდენიმე საათით წინაა, უარყოფს ჯერ არ ძალაში მყოფ სერტიფიკატს, და ვადაგასული შუალედური სერტიფიკატი ამარცხებს ბილიკს, სანამ ფურცელი ძალაშია. დანიშნულების ხარვეზები მოდის სერტიფიკატიდან, რომელსაც გაფართოებულ გასაღების გამოყენებაში serverAuth არ აქვს, ან keyUsage-ით, რომელიც ხელის ჩამორთმევის ხელმოწერას არ უშვებს, რასაც OpenSSL მხარდაჭერილი არ არსებული სერტიფიკატის დანიშნულებად აცხადებს. ხელახლა გასცეთ სწორი შაბლონიდან; ამ შეტყობინებაში არაფერია გადამოწმების გამორთვის მიზეზი.
გაუქმება მუშაობს მხოლოდ მაშინ, როცა ვინმემ ის კონფიგურირა
CRL ან OCSP პასუხი ავტომატურად არ მოწმდება. OpenVPN სერვერზე კლიენტის სერტიფიკატები სიას ედარება მხოლოდ მაშინ, როცა --crl-verify რომელიმეზე მიუთითებს. სერვერის სერტიფიკატის კლიენტის მხრიდან შემოწმება დამოკიდებულია იმპლემენტაციაზე და ხშირად არ არსებობს. strongSwan-ს სჭირდება თავისი გაუქმების დანამატი და პოლიტიკა, სანამ თანატოლისთვის CRL-ს შეხედავს.
ეს ხსნის იმ ბილეთს, რომელსაც საბოლოოდ მიიღებთ: გაუქმებული კლიენტის სერტიფიკატი კვლავ უკავშირდება, და ყველა ასკვნის, რომ გაუქმება გატეხილია. არაფერი ამოწმებდა. გამოაქვეყნეთ და განაახლეთ CRL, ან შეინახეთ კლიენტის სერტიფიკატები იმდენად მოკლევადიანი, რომ მოძველებულ გაუქმებას ცოტა ხანს ჰქონდეს მნიშვნელობა, და ივარჯიშეთ გაუქმების ბილიკზე ლაბორატორიულ სერტიფიკატზე, სანამ ინციდენტის დროს დაგჭირდებათ.
შეკეთების რიგი, რომელიც გადამოწმებას ჩართულს ტოვებს
სანამ ფაილებს შეეხებით, დაალაგეთ სიმპტომის მიხედვით, რადგან ცხრილის ყოველი სტრიქონი სხვა ობიექტთან გაგზავნით.
| Client says | Most likely gate | First check |
|---|---|---|
| unable to get local issuer certificate | trust anchor or missing intermediate | your own openssl verify against the files the profile loads |
| expired or not yet valid | validity window | leaf and intermediate dates against the device clock |
| unsupported certificate purpose | extended key usage | serverAuth present, keyUsage allows the handshake |
| name mismatch | peer identity | subjectAltName entries versus the profile name |
სია ერთი გავლით დაამუშავეთ: დაადასტურეთ ფაილი, რომელსაც პროფილი ტვირთავს, თავად ააგეთ ბილიკი, შეამოწმეთ, რომ სერვერი შუალედურ სერტიფიკატს აგზავნის, შეადარეთ საათი, წაიკითხეთ SAN, წაიკითხეთ EKU, შემდეგ ხელახლა დაუკავშირდით და დააკვირდით, როგორ ქრება იგივე ჟურნალის სტრიქონი. თუ მოწყობილობას საერთოდ ვერ მიეცემა CA, მიმაგრება პატიოსანი ალტერნატივაა, რადგან OpenVPN 2.6 იღებს --peer-fingerprint-ს და ნდობას ერთ გასაღებამდე ავიწროებს გადამოწმების მოხსნის ნაცვლად. RFC 5280 არის ცნობარი იმისა, თუ რას ნიშნავს თითოეული ეს ველი.