ფოთლის სერტიფიკატი ვალიდურია, ჯაჭვი ვადაგასულია: წაიკითხეთ სიღრმე

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

სიღრმე ასახელებს სერტიფიკატს, რომელიც ჩავარდა

OpenSSL-ის დიაგნოსტიკაში სიღრმე 0 სამიზნე სერტიფიკატია, ხოლო სიღრმე 1 — ის გამომცემელი, რომელმაც ხელი მოაწერა, და უფრო დიდი რიცხვები ნდობის საყრდენისკენ გრძელდება. სიღრმე 1-ზე მოხსენებული ვადის გასვლა არ უარყოფს ფოთოლზე არსებულ მოქმედ notAfter-ს, ამიტომ ხილული სერტიფიკატის ხელახალი შემოწმება შეცდომას არასოდეს ახსნის.

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

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

ნდობის შეყვანები არ არის იგივე, რაც ჯაჭვის კანდიდატები

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

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

ნაგულისხმევი გზისა და საცავის გამორთვა -no-CApath -no-CAstore-ით ტესტს პატიოსანს ინახავს: შედეგი მაშინ თქვენს მიერ დასახელებულ ფაილებზეა დამოკიდებული და არა იმაზე, რასაც სამუშაო სადგური შემთხვევით ენდობა. OpenSSL-ის შემოწმების საცნობარი აღწერს ამ ოპციებს და მათ მიერ წარმოებულ დიაგნოსტიკას.

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

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

რას ამტკიცებს შემოწმება და რას ტოვებს გარეთ

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

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

თითოეული სერტიფიკატის ფანჯრის სანახავად, ერთის ნაცვლად, დაბეჭდეთ ისინი ნაკრებად:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

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

შეაკეთეთ გზა შემოწმების შესუსტების გარეშე

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

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

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