სერტიფიკატების გაუქმება ვერ ხერხდება: რომელი ჰოსტი რას ვერ აღწევს

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

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

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

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

წაიკითხეთ გამოქვეყნების წერტილი სერტიფიკატიდან

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

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

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

შეამოწმეთ მოპოვება იმ მოწყობილობიდან, რომელიც ვალიდაციას აკეთებს

მოპოვების ტესტი შეასრულეთ იმ გარემოში, რომელიც რეალურად აკეთებს ვალიდაციას, დამტკიცებული სერტიფიკატის მასალით და პირადი გასაღებების გარეშე.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

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

გამოყავით ნაკლული მონაცემები გაუქმების სტატუსისგან

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

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