ჯვარედინად ხელმოწერილი CA: გასაღები ემთხვევა, AKI-ბმული არა

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

შეასრულეთ ეს ხუთი შემოწმება თანმიმდევრობით: თითოეული განსხვავებულ წარუმატებლობას გამორიცხავს.

შემოწმება 1: დახაზეთ ორივე ჯაჭვი შაბლონზე ხელის დაჭერამდე

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

ჯვარედინად ხელმოწერილი ასლი ასევე უნდა იყოს ნამდვილი CA სერტიფიკატი, basic constraints-ით და key usage-ით, რომლებიც ხელმოწერას უშვებენ.

შემოწმება 2: შეადარეთ AKI ველები და არა მხოლოდ გასაღები

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

გამოიკვლიეთ ფოთოლი გამოცნობის ნაცვლად: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

შემდეგ შეადარეთ ორივე კანდიდატი openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier"-ით, და იგივე ბრძანება თვითნაწერ ასლის წინააღმდეგ.

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

შემოწმება 3: შეცვალეთ გამოცემის პოლიტიკა, არასოდეს ხელმოწერილი ბაიტები

გაფართოებები ხელმოწერის შიგნით ცხოვრობს. ერთის დამატება, წაშლა ან რედაქტირება არსებულ ფოთოლზე შეკეთება არ არის, ეს სხვა სერტიფიკატია და ხელახალ გამოცემას მოითხოვს. ცვლილება გამოცემის პოლიტიკაშია: authorityKeyIdentifier = keyid,issuer:always ახალ ფოთოლს სერტიფიკატისთვის სპეციფიკურ ბმულს ატარებინებს, ხოლო მხოლოდ keyid ინარჩუნებს უფრო თავისუფალ ფორმას, რომელიც განზრახ ჯვარედინი ხელმოწერის გადასვლას უხდება. გადაწყვიტეთ, რომელი სურს თქვენს PKI-ს, სანამ შემდეგი პარტია ხელმოიწერება.

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

შემოწმება 4: დაადასტურეთ თითოეული ნდობის პოპულაცია ცალ-ცალკე

გამოსცადეთ ძველი ბილიკი და ახალი ბილიკი ცალკე გაშვებად. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem ჯვარედინად ხელმოწერილ მარშრუტს ვარჯიშობს, და იგივე ბრძანება ახალი ფესვით და untrusted ფაილის გარეშე თვითნაწერ მარშრუტს ვარჯიშობს. ორივე ფესვის ერთ პაკეტში შერევა მალავს, რომელი ჯაჭვი შეირჩა. შემდეგ გაიმეორეთ რეალურ კლიენტებთან, რადგან VPN backend-ს შეიძლება ჯაჭვის უპირატესობა მიანიჭოს ან დაამაგროს სერტიფიკატი ისე, როგორც openssl არ აკეთებს.

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

შემოწმება 5: შეინახეთ ძველი ბილიკი ექსპლუატაციიდან გაყვანის საათზე

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

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