VPN-ის ახალი შესვლები ვერ ხერხდება, თუმცა სერტიფიკატები ძალაშია: შეამოწმეთ CRL

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

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

ორი საათი, და მხოლოდ ერთი მათგანია სერტიფიკატი

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

ორ ობიექტს სხვადასხვა მფლობელი ჰყავს: სერტიფიკატი მოდის იმ CA-დან, რომელმაც გამოსცა ის, ხოლო სია გრაფიკის მიხედვით გენერირდება იმის მიერ, ვინც ახორციელებს ამ CA-ს. მომხმარებელი ვერ განაახლებს მას, და სერტიფიკატების ხელახლა გამოცემა ვერ გაახანგრძლივებს მას.

წაიკითხეთ სია, რომელსაც სერვისი რეალურად ტვირთავს

დაიწყეთ გაშვებული კონფიგურაციიდან და არა იმ ფაილიდან, რომელსაც ელოდებით. crl-verify-ის ბილიკი შეიძლება იყოს აბსოლუტური, პროფილის მიმართ ფარდობითი, ან გამოსახულებაში ჩასმული ასლი, და გადამოწმებელი კითხულობს სწორედ ამ ასლს. შეამოწმეთ ის ადგილზე openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate-ით და შეადარეთ თარიღები სერვერის საათს.

შემდეგ დაადასტურეთ, რომ ფაილი ნამდვილად გამოყენებადი ფაილია: შეამოწმეთ მისი ხელმოწერა openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout-ით, რომელიც აცხადებს გადამოწმების შედეგს ნაცვლად იმისა, რომ ველები ჩუმად დაბეჭდოს. სხვა CA-ის მიერ ხელმოწერილი სია, ან მეორე დირექტორიაში დარჩენილი მოძველებული ასლი, ფერხდება ზუსტად ისე, როგორც ვადაგასული.

ხელახლა შექმენით გაუქმების მონაცემთა ბაზიდან და არა ნულიდან

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

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

გაშალეთ იქ, სადაც გადამოწმებელი იხედება

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

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

შემდეგი ვადა გახადეთ ხილული, სანამ ის გავა

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

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