ხსნით კლიენტს, ირჩევთ პროფილს, რომელსაც თვეებია იყენებთ და ის ჩერდება შეტყობინებით "certificate is not yet valid". თქვენს შესვლაში არაფერი შეცვლილა და ნდობის საცავი, სავარაუდოდ, რიგზეა: ხელის ჩამორთმევისას წარმოდგენილ სერტიფიკატს აქვს მოქმედების ფანჯარა, რომელიც იწყება უფრო გვიან, ვიდრე შემმოწმებლის მიერ გამოყენებული მომენტი. სამი განსხვავებული სიტუაცია წარმოქმნის ზუსტად ამ შეტყობინებას და ისინი განსხვავებულ ქმედებებს მოითხოვს. ქვემოთ მოცემული რიგი გეტყვით, რომელი გაქვთ, სანამ საათს ან სერტიფიკატის ფაილს შეეხებით.

სამი მიზეზიდან რომელს ხედავთ

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

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

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

ფანჯარა წაიკითხეთ იმ სერტიფიკატიდან, რომელიც რეალურად იყო წარმოდგენილი

ნუ შეამოწმებთ წინა განლაგებიდან დარჩენილ PEM ფაილს; ჰკითხეთ სერვისს ახლა გაგზავნილი ჯაჭვის შესახებ. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts ბეჭდავს ჯაჭვის ყველა სერტიფიკატს. შეინახეთ თქვენთვის საინტერესო ბლოკი და გაუშვით openssl x509 -noout -subject -issuer -dates; უკანასკნელი ბეჭდავს notBefore და notAfter-ს და სწორედ ეს ორი მნიშვნელობა წყვეტს. Windows-ზე კავშირის სერტიფიკატის დიალოგი და ექსპორტირებულ ფაილზე certutil -dump იმავე ველებს აჩვენებს.

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

ფანჯრის შემოწმება მისი ლოდინის გარეშეც შეგიძლიათ. შემოწმება იღებს გამოკვეთილ დროს: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem აფასებს ჯაჭვს იმ დროის ნიშნულზე. გაუშვით მიმდინარე დროით მარცხის გასამეორებლად, შემდეგ სერტიფიკატის დაწყების დროით იმის დასადასტურებლად, რომ იგივე ჯაჭვი გაივლის, როგორც კი ფანჯარა გაიხსნება. RFC 5280 განსაზღვრავს მოქმედების ველს და წესს, რომ სერტიფიკატი მის გარეთ არ უნდა გამოიყენებოდეს, და სწორედ ეს წესი გამოიყენა თქვენმა კლიენტმა ახლახან.

თქვენი საათი თუ მათი

შეადარეთ მოწყობილობის საათი სერტიფიკატის UTC-ით დაწყებას, თქვენთვის სანდო წყაროდან. date -u გაძლევთ მომენტს, ხოლო systemd ჰოსტზე timedatectl status ასევე იტყობინება, არის თუ არა საათი სინქრონიზებული. Windows-ზე w32tm /query /status აჩვენებს მიმდინარე წყაროსა და ბოლო წარმატებულ სინქრონიზაციას. დავალების პანელში ნაჩვენები დროის ზონა ჩვენების არჩევანია და არა არასწორი საათი; შემმოწმებელი ადარებს UTC მომენტებს.

What you seeMost likely readingNext step
Clock behind, one device affectedLocal time faultResync time, keep validation on, retest
Clock correct, window opens soonCertificate staged earlyWait for the window or follow the cutover plan
Clock correct, intermediate not yet validChain material mismatchOperator replaces the intermediate
Some peers pass, others do notInconsistent nodesRecord each peer's chain before changing anything

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

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

რატომ ჩავარდება ჯაჭვი, მაშინ როცა ფოთოლი კარგად გამოიყურება

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

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

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

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

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

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

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

დაკავშირებული სტატიები