ერთი საერთო სახელი, ორი სერტიფიკატი: დაშვების სია თუ გაუქმება?

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

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

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

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

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

შეამოწმეთ, რა უშვებს კლიენტს სინამდვილეში

შესაბამისი ფაილის მქონე client-config-dir უზრუნველყოფს პარამეტრებს თითოეული კლიენტისთვის; თავისთავად ეს დაშვების წესი არ არის. სახელით დაშვება მოითხოვს ccd-exclusive, რომელიც უარყოფს კლიენტებს, რომლებსაც შესაბამისი ფაილი არ აქვთ. ამის ჩართვა მოქმედ განლაგებაზე თიშავს ყველას, ვისი სახელის ფაილიც არ არსებობს, ამიტომ დაითვალეთ ფაილები სანამ რამეს შეცვლით.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

დათვლა შემოწმებაა: შეადარეთ დირექტორიის სია იმ იდენტობებს, რომელთა დაკავშირებასაც ელოდებით.

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

შეამოწმეთ CRL, რომელსაც კარიბჭე ტვირთავს

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

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

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

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

შეცვალეთ, შემდეგ დაამტკიცეთ ორივე შედეგი

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

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

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

რასაც სახელის შემოწმება ვერასდროს შეძლებს

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

სადაც სერტიფიკატის დონის კონტროლია საჭირო, გამოიყენეთ სერტიფიკატს სახელდებული მექანიზმი: CRL ჩანაწერები, ან შემოწმების კაუჭი, რომელიც ამოწმებს ოპერატორის მიერ შენახულ თითის ანაბეჭდს. ორივე მოვლას მოითხოვს და ორივე პატიოსანია იმ ობიექტის მიმართ, რომელსაც იკვლევს. OpenVPN 2.6-ის სახელმძღვანელო ასახავს crl-verify და კლიენტისთვის სპეციფიკურ დაშვებას ცალკე პარამეტრებად სწორედ ამ მიზეზით.

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