openssl ca: არასწორი ვადის ამოწურვის თარიღი index.txt-ში და როგორ გამოვასწოროთ
CA უარს ამბობს გაცემაზე, რადგან index.txt-ის ერთი ხაზი არ ირჩევა. დააკოპირეთ CA-ის მდგომარეობა, გაშიფრეთ ჩანაწერი და შემდეგ შეათანხმეთ ხელმოწერილ სერტიფიკატთან.
გაცემის გაშვება ჩერდება entry 22: invalid expiry date-ზე, თუმცა თქვენ წინ არსებული მოთხოვნა სრულიად რიგზეა. საჩივარი მოდის CA-ის მონაცემთა ბაზის ანალიზატორისგან, არა CSR-ისგან და არა იმ VPN კლიენტისგან, რომელიც საბოლოოდ წარადგენს სერტიფიკატს. ეს განსხვავება განსაზღვრავს ყველაფერს შემდგომს: ჩანაწერი დაზიანებულია, ამიტომ შესწორება CA-ის მდგომარეობას ეკუთვნის და არა მოთხოვნას ან პარტნიორის კონფიგურაციას. დანომრილ ჩანაწერს მოეპყარით როგორც ხაზს index.txt-ში, და პრობლემა მცირდება შეზღუდულ მონაცემთა კითხვამდე, რომელსაც შესამოწმებელი პასუხი აქვს.
წაიკითხეთ შეცდომა როგორც საჩივარი მონაცემთა ბაზაზე
ყოველი openssl ca გამოძახება გადის თავის ტექსტურ ბაზაზე, სანამ რამეს მოაწერს ხელს. ყოველი ხაზი შეიცავს მდგომარეობის ასოს, ვადის ამოწურვის დროის ბეჭედს, სურვილისამებრ გაუქმების ბეჭედს, სერიულ ნომერს თექვსმეტობითში, ფაილის სახელს და სუბიექტს. როცა ერთი ველი არ ირჩევა, ბრძანება აცნობებს ხაზის ნომერს და ჩერდება იმის ნაცვლად, რომ დარჩენილი ჩანაწერი გამოიცნოს.
ეს გაჩერება დამცავია და არა პედანტური. ჩანაწერი, რომელსაც ხელსაწყო ვერ კითხულობს, მას უმძიმებს გადაწყვეტილების მიღებას: არსებობს თუ არა უკვე მოთხოვნილი სუბიექტი, გაცემულია თუ არა სერიული ნომერი, ან რა უნდა შეიცავდეს შემდეგი CRL. დაზიანებული ხაზის გავლით გაგრძელება შექმნიდა ზუსტად იმ ჩუმ შეუთანხმებლობას, რომელიც თვეების შემდეგ, ჩვეულებრივ ისეთი გაუქმების დროს, რომელსაც ვერავინ ახსნის, ზედაპირზე ამოდის. წაიკითხეთ შეტყობინება როგორც საჩივარი მონაცემებზე, და გამოძიება CA-ის საქაღალდეში რჩება.
დააკოპირეთ CA-ის მდგომარეობა, სანამ რამეს შეეხებით
გადაუღეთ სურათი მთელ CA საქაღალდეს და არა მხოლოდ მონაცემთა ბაზის ფაილს. ინდექსი, მისი ატრიბუტების ფაილი, სერიული და CRL ნომრის ფაილები, კერძო გასაღები და გაცემული სერტიფიკატები ყველა მონაწილეობს შემდგომ ოპერაციებში, ხოლო შესწორება, რომელიც ერთს აღადგენს და დანარჩენებს გამოტოვებს, მეორე ინციდენტს ქმნის. გამოიყენეთ CA-ის საკუთარი სარეზერვო პროცედურა, სადაც არსებობს, და სამუშაოს ხანგრძლივობით შეაჩერეთ დაგეგმილი გაცემა.
ჩაიწერეთ OpenSSL-ის აწყობა და კონფიგურაციის ფაილი, რომელიც წარუმატებელმა ბრძანებამ რეალურად ჩატვირთა. ინსტალაციები ხშირად ინახავენ ერთზე მეტ CA საქაღალდეს, და შეცდომას მნიშვნელობა აქვს მხოლოდ იმ ბაზის მიმართ, რომელსაც არჩეული კონფიგურაცია ასახელებს.
იპოვეთ ჩანაწერი და გაშიფრეთ მისი თარიღის ველი
მოხსენებული ხაზის ნომერი პირველი ჩანაწერიდან ითვლება, ამიტომ sed -n '22p' index.txt ხვდება პრობლემურ ჩანაწერზე მას შემდეგ, რაც დაადასტურებთ, რომ მის ზემოთ ცარიელი ან კომენტარის ხაზები არ არის. დაბეჭდეთ ეს ხაზი თვალსაჩინო გამყოფებით, რადგან ტაბულაციები და ბოლოში არსებული სივრცეები ჩვეულებრივია და ჩვეულებრივ რედაქტორის ფანჯარაში უხილავია.
ვადის ველი დროის ბეჭედია, რომლის სიგანე წელზეა დამოკიდებული. 2049 წლამდე მნიშვნელობები იწერება UTCTime-ში როგორც YYMMDDHHMMSSZ, ხოლო უფრო გვიანდელი მნიშვნელობები გადადის GeneralizedTime-ზე ოთხნიშნა წლით. ჩანაწერი, რომელიც ორ ფორმას ურევს, ან ორნიშნა წელს ატარებს იქ, სადაც ანალიზატორი ახლა ოთხს ელის, ზუსტად ამ წერტილში მარცხდება. ასევე შეწყვეტილი წერისგან დარჩენილი მოკვეცილი ველი.
შეადარეთ ჩანაწერი იმ სერტიფიკატს, რომელზეც მიუთითებს და არა სხვა CA-ის ფაილს. ხელმოწერილი სერტიფიკატი არის ხელისუფლება იმაში, თუ რა უნდა თქვას ვალიდურობამ, და ის უკვე არსებობს როგორც გასაანალიზებელი ობიექტი.
შეასწორეთ ჩანაწერი ხელმოწერილი სერტიფიკატის მიხედვით
წაიკითხეთ ნამდვილი თარიღები ამ ბრძანებით: openssl x509 -in issued.pem -noout -dates -serial -subject. გადააქციეთ notAfter იმ ბეჭდის სიგანეში, რომელსაც თქვენი აწყობა ამ წლისთვის წერს, და ერთი სიმბოლოს შეცვლამდე დაადასტურეთ, რომ სერიული ნომერი ემთხვევა იმ ჩანაწერს, რომელსაც აპირებთ რედაქტირებას.
შეასწორეთ მხოლოდ დაზიანებული ველი, შეინარჩუნეთ მდგომარეობის ასო და სერიული ნომერი, დანარჩენი ხაზი კი ხელუხლებელი დატოვეთ. თუ ჩანაწერი ვერც ერთ ხელმოწერილ სერტიფიკატს ვერ შეეთანხმება, მოეპყარით როგორც მაწანწალა ჩანაწერს და გაიტანეთ იგი CA-ის საკუთარი გაუქმების გზით, ხაზის ხელით წაშლის ნაცვლად.
ნუ შეასწორებთ თარიღის მოჭრით, რომ წლის შესახებ ვარაუდს მოერგოს. ორსიმბოლოიანი ჭრა აწყობებს შორის გადატანადი არ არის და ჩუმად ცვლის იმ ვალიდურობას, რომელსაც ბაზა მომავალ დუბლიკატ-სუბიექტისა და CRL შემოწმებებს აცნობებს. როცა საწყისი მნიშვნელობის აღდგენა შეუძლებელია, ხელახლა გასცით ახალი სერიული ნომრით და ჩაწერეთ, რატომ იქნა ძველი მიტოვებული. აუდიტის კვალი შესწორების ნაწილია და არა მის გარშემო არსებული ქაღალდები.
წასვლამდე შეამოწმეთ გაცემა და CRL-ის გენერაცია
გაუშვით ერთი გაცემა იმავე კონფიგურაციით და დაადასტურეთ, რომ ის ხაზის ნომრის საჩივრის გარეშე სრულდება. შემდეგ შექმენით CRL ამ ბრძანებით: openssl ca -gencrl -config openssl.cnf და შეამოწმეთ, რომ ის ირჩევა, რადგან დაზიანებული ჩანაწერი ხშირად სწორედ იქ ამოდის ზედაპირზე და არა ხელმოწერის დროს.
შეამოწმეთ ახალი სერტიფიკატი ამ ბრძანებით: openssl x509 -noout -dates -serial და შეადარეთ იმ ხაზს, რომელიც CA-მ ახლახან დაწერა. დაადასტურეთ, რომ მდგომარეობის ასო და ვადის თარიღი ემთხვევა სერტიფიკატს, და დაადასტურეთ, რომ openssl verify -CAfile ca.pem issued.pem ბრუნდება შეცდომის გარეშე. შემდეგ აღადგინეთ დაგეგმილი გაცემა და დააკვირდით პირველ გაშვებას, რადგან მეორე დაზიანებული ხაზი დაუყოვნებლივ გამოაცხადებს თავს.