openssl ca: nederīgs derīguma termiņa datums index.txt un kā to salabot

Izdošanas palaišana apstājas pie entry 22: invalid expiry date, un priekšā esošais pieprasījums ir pilnīgi kārtībā. Sūdzība nāk no CA datubāzes parsera, nevis no CSR un nevis no VPN klienta, kas galu galā uzrādīs sertifikātu. Šī atšķirība nosaka visu pārējo: ieraksts ir bojāts, tāpēc labojums pieder CA stāvoklim, nevis pieprasījumam vai partnera konfigurācijai. Uz numurēto ierakstu skatieties kā uz rindu failā index.txt, un problēma sašaurinās līdz ierobežotam datu jautājumam ar pārbaudāmu atbildi.

Lasiet kļūdu kā sūdzību par datubāzi

Katrs openssl ca izsaukums pirms kaut kā parakstīšanas izstaigā savu teksta datubāzi. Katrā rindā ir statusa burts, derīguma termiņa laika zīmogs, neobligāts atsaukšanas zīmogs, sērijas numurs heksadecimālajā formā, faila nosaukums un subjekts. Kad viens lauks netiek parsēts, komanda ziņo rindas numuru un apstājas, nevis min pārējo ierakstu.

Šī apstāšanās ir aizsargājoša, nevis pedantiska. Ieraksts, ko rīks nevar nolasīt, atstāj to nespējīgu izlemt, vai pieprasītais subjekts jau pastāv, vai sērijas numurs jau izsniegts, vai arī kas jāietver nākamajā CRL. Turpināšana pāri sliktai rindai radītu tieši to kluso nekonsekvenci, kas parādās mēnešus vēlāk, parasti atsaukšanas laikā, ko neviens nevar izskaidrot. Lasiet ziņojumu kā sūdzību par datiem, un izmeklēšana paliek CA mapē.

Nokopējiet CA stāvokli, pirms kam pieskaraties

Uzņemiet visu CA mapes momentuzņēmumu, ne tikai datubāzes failu. Indekss, tā atribūtu fails, sērijas numura un CRL numura faili, privātā atslēga un izsniegtie sertifikāti visi piedalās turpmākajās darbībās, un labojums, kas atjauno vienu un izlaiž pārējos, rada otru incidentu. Kur tāda ir, izmantojiet pašas CA dublēšanas procedūru, un darba laikā apturiet plānoto izsniegšanu.

Pierakstiet OpenSSL būvējumu un konfigurācijas failu, ko neizdevusī komanda faktiski ielādēja. Instalācijas bieži glabā vairāk nekā vienu CA mapi, un kļūdai ir jēga tikai attiecībā pret datubāzi, ko nosauc izvēlētā konfigurācija.

Atrodiet ierakstu un atšifrējiet tā datuma lauku

Norādītais rindas numurs tiek skaitīts no pirmā ieraksta, tāpēc sed -n '22p' index.txt nonāk uz problemātiskā ieraksta, tiklīdz esat pārliecinājies, ka virs tā nav tukšu vai komentāru rindu. Izdrukājiet šo rindu ar redzamiem atdalītājiem, jo tabulācijas un beigu atstarpes ir ierastas un parastā redaktora logā nav redzamas.

Derīguma lauks ir laika zīmogs, kura platums atkarīgs no gada. Vērtības līdz 2049 tiek rakstītas UTCTime formātā kā YYMMDDHHMMSSZ, bet vēlākās vērtības pāriet uz GeneralizedTime ar četrciparu gadu. Ieraksts, kas sajauc abas formas vai nes divciparu gadu tur, kur parsētājs tagad gaida četrus, neizdodas tieši šajā vietā. Tāpat arī pārtrauktas rakstīšanas atstāts apgriezts lauks.

Salīdziniet ierakstu ar sertifikātu, uz kuru tas attiecas, nevis ar citas CA failu. Parakstītais sertifikāts ir autoritāte tam, ko derīgumam vajadzētu teikt, un tas jau pastāv kā parsējams objekts.

Salabojiet ierakstu atbilstoši parakstītajam sertifikātam

Nolasiet īstos datumus ar openssl x509 -in issued.pem -noout -dates -serial -subject. Pārveidojiet notAfter tādā zīmoga platumā, kādu jūsu būvējums raksta šim gadam, un pirms vienas rakstzīmes maiņas pārliecinieties, ka sērijas numurs atbilst ierakstam, kuru gatavojaties rediģēt.

Rediģējiet tikai bojāto lauku, saglabājiet statusa burtu un sērijas numuru, un atstājiet pārējo rindu mierā. Ja ierakstu nevar saskaņot ne ar vienu parakstītu sertifikātu, uzskatiet to par nomaldījušos ierakstu un izvediet to pa pašas CA atsaukšanas ceļu, nevis dzēsiet rindu ar roku.

Nesalabojiet, apgriežot datumu, lai tas atbilstu minējumam par gadu. Divu rakstzīmju griezums nav pārnesams starp būvējumiem, un tas klusi maina derīgumu, ko datubāze ziņo turpmākajām dublēta subjekta un CRL pārbaudēm. Kad sākotnējo vērtību nav iespējams atjaunot, izsniedziet no jauna ar jaunu sērijas numuru un pierakstiet, kāpēc vecais tika atstāts. Audita pēdas ir labojuma daļa, nevis papīru darbs ap to.

Pirms aiziešanas pārbaudiet izsniegšanu un CRL ģenerēšanu

Palaidiet vienu izsniegšanu ar to pašu konfigurāciju un pārliecinieties, ka tā beidzas bez sūdzības par rindas numuru. Pēc tam ģenerējiet CRL ar openssl ca -gencrl -config openssl.cnf un pārbaudiet, ka tas tiek parsēts, jo bojāts ieraksts bieži parādās tieši tur, nevis parakstīšanas laikā.

Apskatiet jauno sertifikātu ar openssl x509 -noout -dates -serial un salīdziniet to ar rindu, ko CA tikko ierakstīja. Pārliecinieties, ka statusa burts un derīguma datums saskan ar sertifikātu, un pārliecinieties, ka openssl verify -CAfile ca.pem issued.pem atgriežas bez kļūdas. Pēc tam atjaunojiet plānoto izsniegšanu un vērojiet pirmo palaišanu, jo otra bojātā rinda pieteiksies uzreiz.