VPN სერტიფიკატის განახლება მისი იდენტობის შეცვლის გარეშე

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

სამი პირობა განსაზღვრავს განახლების ფორმას

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

დაიწყეთ თქვენს ხელთ არსებული სერტიფიკატის შემოწმებით. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName ბეჭდავს სუბიექტს, გამომცემელს, ვალიდობის ფანჯარას და იმ სახელებს, რომლებისთვისაც სერტიფიკატი ნამდვილად ვალიდურია. სწორედ ეს უკანასკნელი ველია უმნიშვნელოვანესი და ყველაზე ხშირად ნაგულისხმევი: განახლების მოთხოვნა, რომელიც გამოტოვებს SAN-ს, რომელსაც კლიენტი ეყრდნობა, ქმნის ტექნიკურად ვალიდურ, მაგრამ ფუნქციურად არასწორ სერტიფიკატს. დააკოპირეთ SAN-ების სია ძველი სერტიფიკატიდან მოთხოვნაში, ნაცვლად იმისა, რომ მეხსიერებიდან ხელახლა აკრიფოთ.

პირველი პირობა: ამაგრებს თუ არა რამე ფოთოლს

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

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

მეორე პირობა: შეადარეთ დამაგრებები და ჯაჭვი

ანაბეჭდები დამაგრებას შესამოწმებელს ხდის: openssl x509 -noout -fingerprint -sha256 -in server.crt ძველ და ახალ სერტიფიკატზე, და openssl x509 -noout -pubkey საჯარო გასაღებების შესადარებლად. თუ კლიენტის კონფიგურაცია, მობილური პროფილი ან მოწყობილობის ნდობის საცავი შეიცავს რომელიმე ამ მნიშვნელობას, დამაგრება გაქვთ. მობილური VPN პროფილები გავრცელებული დასამალი ადგილია, რადგან პროფილი ერთხელ ნაწილდება და აღარასოდეს მოწმდება.

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

შეამოწმეთ ჯაჭვი, რომელსაც სერვერი ნამდვილად აგზავნის openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts-ის გამოყენებით, და ლოკალურად დაადასტურეთ ის openssl verify -CAfile ca.pem -untrusted chain.pem server.crt-ის გამოყენებით. ამის გაკეთება ცვლილებამდე გაძლევთ საწყის ხაზს შემდგომი შედარებისთვის.

მესამე პირობა: ვინ კიდევ ამოწმებს სახელს

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

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

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

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

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

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

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