openssl ca: neveljaven datum poteka v index.txt in kako ga popraviti

Izvajanje izdaje se ustavi pri entry 22: invalid expiry date, medtem ko je zahteva pred vami povsem v redu. Pritožba prihaja iz razčlenjevalnika baze podatkov CA, ne iz CSR in ne iz odjemalca VPN, ki bo potrdilo na koncu predstavil. Ta razlika določa vse, kar sledi: zapis je poškodovan, zato popravilo spada v stanje CA in ne v zahtevo ali konfiguracijo partnerja. Oštevilčeni vnos obravnavajte kot vrstico v index.txt, in težava se skrči na omejeno vprašanje o podatkih z odgovorom, ki ga je mogoče preveriti.

Napako berite kot pritožbo na bazo podatkov

Vsak openssl ca klic prehodi svojo besedilno bazo podatkov, preden karkoli podpiše. Vsaka vrstica vsebuje črko stanja, časovni žig poteka, neobvezen žig preklica, serijsko številko v šestnajstiškem zapisu, ime datoteke in subjekt. Ko enega polja ni mogoče razčleniti, ukaz sporoči številko vrstice in se ustavi, namesto da bi ugibal preostanek zapisa.

Ta ustavitev je zaščitna in ne pedantna. Zapis, ki ga orodje ne more prebrati, ga pusti brez možnosti, da bi odločilo, ali zahtevani subjekt že obstaja, ali je bila serijska številka dodeljena in kaj naj vsebuje naslednji CRL. Nadaljevanje mimo slabe vrstice bi ustvarilo prav tisto tiho nedoslednost, ki se pokaže mesece pozneje, običajno med preklicem, ki ga nihče ne zna razložiti. Sporočilo berite kot pritožbo na podatke, in preiskava ostane znotraj imenika CA.

Kopirajte stanje CA, preden se česar koli dotaknete

Naredite posnetek celotnega imenika CA, ne le datoteke baze podatkov. Kazalo, njegova datoteka atributov, datoteki serijske številke in številke CRL, zasebni ključ in izdana potrdila vsi sodelujejo pri poznejših operacijah, popravilo, ki eno obnovi in drugo izpusti, pa ustvari drugi incident. Kjer obstaja, uporabite lastno rutino varnostnega kopiranja CA, in med delom začasno ustavite načrtovano izdajanje.

Zabeležite gradnjo OpenSSL in konfiguracijsko datoteko, ki ju je neuspešni ukaz dejansko naložil. Namestitve pogosto hranijo več kot en imenik CA, in napaka ima pomen le glede na bazo podatkov, ki jo navaja izbrana konfiguracija.

Poiščite vnos in dekodirajte njegovo polje datuma

Sporočena številka vrstice se šteje od prvega zapisa, zato sed -n '22p' index.txt pristane na problematičnem vnosu, ko potrdite, da nad njim ni praznih vrstic ali komentarjev. To vrstico natisnite z vidnimi ločili, ker so tabulatorji in presledki na koncu pogosti in v običajnem oknu urejevalnika nevidni.

Polje poteka je časovni žig, katerega širina je odvisna od leta. Vrednosti do vključno 2049 se zapisujejo v UTCTime kot YYMMDDHHMMSSZ, poznejše vrednosti pa preidejo na GeneralizedTime s štirimestnim letom. Zapis, ki meša obe obliki, ali nosi dvomestno leto tam, kjer razčlenjevalnik zdaj pričakuje štiri, spodleti točno na tej točki. Enako velja za odrezano polje, ki ga je pustilo prekinjeno pisanje.

Zapis primerjajte s potrdilom, na katero se nanaša, ne z datoteko druge CA. Podpisano potrdilo je avtoriteta glede tega, kaj naj veljavnost pove, in že obstaja kot predmet, ki ga je mogoče razčleniti.

Popravite zapis glede na podpisano potrdilo

Preberite resnične datume z openssl x509 -in issued.pem -noout -dates -serial -subject. Pretvorite notAfter v širino žiga, ki jo vaša gradnja zapisuje za to leto, in preden spremenite en sam znak potrdite, da se serijska številka ujema z vnosom, ki ga boste urejali.

Urejajte samo pokvarjeno polje, obdržite črko stanja in serijsko številko, preostanek vrstice pa pustite pri miru. Če zapisa ni mogoče uskladiti z nobenim podpisanim potrdilom, ga obravnavajte kot zablodeli vnos in ga umaknite po lastni poti preklica CA, namesto da bi vrstico izbrisali ročno.

Ne popravljajte tako, da datum odrežete, da bi ustrezal domnevi o letu. Rez dveh znakov ni prenosljiv med gradnjami in tiho spremeni veljavnost, ki jo baza podatkov sporoča prihodnjim preverjanjem podvojenega subjekta in CRL. Ko izvorne vrednosti ni mogoče obnoviti, izdajte znova pod novo serijsko številko in zapišite, zakaj je bila stara opuščena. Revizijska sled je del popravila, ne papirji okoli njega.

Preverite izdajanje in ustvarjanje CRL, preden odidete

Zaženite eno izdajo z isto konfiguracijo in potrdite, da se konča brez pritožbe glede številke vrstice. Nato ustvarite CRL z openssl ca -gencrl -config openssl.cnf in preverite, da ga je mogoče razčleniti, ker poškodovan zapis pogosto pride na dan prav tam in ne med podpisovanjem.

Preglejte novo potrdilo z openssl x509 -noout -dates -serial in ga primerjajte z vrstico, ki jo je CA pravkar zapisala. Potrdite, da se črka stanja in datum poteka ujemata s potrdilom, in potrdite, da openssl verify -CAfile ca.pem issued.pem vrne brez napake. Nato obnovite načrtovano izdajanje in spremljajte prvi zagon, ker se bo druga poškodovana vrstica oglasila takoj.