განახლებული VPN სერტიფიკატი: ზოგი კლიენტი მაინც უარყოფს მას
განახლებამ შეიძლება შეინარჩუნოს სახელი და შეცვალოს ობიექტი. შეადარეთ CA-ს ნდობა, სახელის შემოწმებები და კლიენტის მხრიდან დამაგრება, სანამ რომელიმე უსაფრთხოების გაფრთხილებას მიიღებთ.
განახლების შემდეგ გარემოს ნახევარი ხელახლა უკავშირდება, ხოლო სამი მოწყობილობა უარყოფს, თითოეული გეითვეის იდენტურობის შესახებ გაფრთხილებით. თავად განახლება ჩვეულებრივი პროცედურაა. ამ სამ მოწყობილობას ძველ ობიექტზე დამაგრება აქვს, და დამაგრება არ არის CA-ს სია, სახელის შემოწმება ან ნდობის საცავის ჩანაწერი. შეადარეთ სამივე მექანიზმი, სანამ რომელიმე კლიენტს შეეხებით.
ერთი განახლება, ორი ქცევა
ხელახლა დაკავშირებულ კლიენტებს ნდობის გადაწყვეტილება ჯერ კიდევ გადის, ხოლო უარყოფილებს აქვთ მოთხოვნა, რომელსაც ახალი სერტიფიკატი არ აკმაყოფილებს. ეს განსხვავება ინფორმაციაა, არა ხმაური. ზუსტად წაიკითხეთ წარუმატებელი კლიენტის შეტყობინება. სახელის შეუსაბამობა, უცნობი გამომცემელი და შეცვლილი თითის ანაბეჭდი სამი განსხვავებული განაჩენია, და მხოლოდ ბოლო მიუთითებს დამაგრებაზე.
ასევე შეამოწმეთ, რომელი პროფილი აირჩია წარუმატებელმა კლიენტმა. იმპორტირებული ასლი, რომელიც საკუთარ საცავში ცხოვრობს, არ იცვლება, როცა ადმინისტრატორი ორიგინალ ფაილს სხვაგან არედაქტირებს.
განახლება ცვლის ობიექტს და არა მხოლოდ თარიღს
თითის ანაბეჭდი იდენტიფიცირებს დაშიფრულ სერტიფიკატის შიგთავსს. განახლება ახალ სერტიფიკატს ქმნის, ამიტომ თითის ანაბეჭდი იცვლება მაშინაც, როცა სუბიექტის სახელი და საჯარო გასაღები იგივე რჩება. ეს მოსალოდნელი და უვნებელია იმ კლიენტებისთვის, რომლებიც CA-ს ენდობიან და სახელს ამოწმებენ. ეს საბედისწეროა კლიენტისთვის, რომელიც ზუსტად ერთი სერტიფიკატის მიღებაზეა კონფიგურირებული, და ასევე საბედისწეროა იმ კლიენტისთვის, რომლის ნდობის საცავმა ახალი გამომცემელი არასოდეს მიიღო.
openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256
მეორე ხაზი სხვა კითხვას პასუხობს, გადაურჩა თუ არა გასაღების წყვილი. განახლება, რომელიც გასაღებს ხელახლა იყენებს, ინარჩუნებს ამ მნიშვნელობას და მხოლოდ სერტიფიკატს ცვლის, და ეს არის ზუსტად ის შემთხვევა, როცა ადმინისტრატორს ცდუნება უჩნდება, რომ არაფერი შეიცვალა. შეამოწმეთ განლაგებული სერტიფიკატი და არა ის, რომელიც აწყობის სერვერზეა. საცავში ფაილის შედარება ამტკიცებს, რა შეიქმნა, და არა იმას, რასაც მსმენელი ახლა წარმოადგენს.
წაიკითხეთ, რას ამაგრებს კლიენტი
ზოგი კლიენტი თითის ანაბეჭდს საკუთარ პროფილში ინახავს და ყოველ კავშირზე ადარებს. სხვები მას პლატფორმის ნდობის საცავში ინახავენ, ზოგიც მხოლოდ CA-ს ეყრდნობა. შეკეთება თითოეულ შემთხვევაში განსხვავებულია, ამიტომ ჯერ მექანიზმი დაადგინეთ.
grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256
პირველი ბრძანება ჩვეულებრივ პროფილში დამაგრებას აჩვენებს, მეორე კი თითის ანაბეჭდს, რომელსაც ენდპოინტი სწორედ ახლა ემსახურება. როცა ეს ორი განსხვავდება, თქვენ ხარვეზი იპოვეთ გამოცნობის გარეშე. არ ჩასვათ ახალი მნიშვნელობა ყველა მომჩივან კლიენტში. გამომცემლის გამო უარყოფილი კლიენტი განაგრძობს უარყოფას, და თქვენ საკუთარ თავს ასწავლით, რომ პრობლემა თითის ანაბეჭდი იყო, მაშინ როცა არ იყო.
შეადარეთ თითოეული ბექენდის მიერ მოწოდებული სერტიფიკატი
შეწყვეტილი შედეგები ჩვეულებრივ ერთზე მეტ ენდპოინტს ნიშნავს, და ერთ კვანძზე გამოყენებული განახლება დანარჩენებს ძველ ობიექტს აჩვენებინებს. შეადარეთ თითოეული ბექენდი მისამართით და არა საერთო სახელით.
for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done
პული, სადაც ერთი კვანძი ჩამორჩება, ხსნის კლიენტს, რომელიც მეორე ცდაზე უკავშირდება და პირველზე მარცხდება. ის ასევე ხსნის მონიტორინგის შემოწმებას, რომელიც გადის, სანამ მომხმარებლები ჩივიან. ჯერ ჩამორჩენა გაასწორეთ. ნდობის კონფიგურაციის გაშვება მანამ, სანამ ყველა კვანძი ახალ სერტიფიკატს მოემსახურება, ქმნის ფანჯარას, სადაც არაფერი მუშაობს, ხოლო ამის შემდეგ გაშვება კლიენტებს არაპროგნოზირებადად ამარცხებს.
შეცვალეთ ნდობა მართული გზით
დაადასტურეთ ჩანაცვლება უკვე სანდო ადმინისტრაციული არხით, სანამ სადმე მიიღებთ მას. დამაჯერებელი ვადის გასვლის თარიღი საკუთრების მტკიცებულება არ არის. განაახლეთ მართული კონფიგურაცია იმ პროცესით, რომელიც მას ფლობს, მისაღები იდენტურობების ნებისმიერი დაგეგმილი გადაფარვით, და შეინარჩუნეთ განლაგების მოთხოვნილი სახელის შემოწმება. დამაგრება სახელის შემოწმების გარეშე უფრო სუსტი დიზაინია, ვიდრე CA-ს ნდობა, რომელიც მან შეცვალა.
შემდეგ შეამოწმეთ თითოეული კლიენტისთვის, დაუკავშირდით, დაადასტურეთ მის მიერ მიღებული იდენტურობა და ჩაიწერეთ სერტიფიკატის ვერსია, რომელსაც ახლა ენდობა. ერთხელ უარყოფილი გაფრთხილება ჩვეულებრივ ბრუნდება შემდეგ განახლებაზე.