openssl ca: ûnjildige ferfaldatum yn index.txt, en hoe't jo it reparearje

In útjaanrun stopt mei entry 22: invalid expiry date, en it fersyk foar jo is folslein yn oarder. De klacht komt fan 'e parser fan 'e CA-database, net fan 'e CSR en net fan 'e VPN-klant dy't it sertifikaat úteinlik presintearje sil. Dat ûnderskied beslút alles dêrnei: in record is misfoarme, dus heart de reparaasje yn 'e CA-steat en net yn it fersyk of de peer-konfiguraasje. Behannelje de nûmere ynfier as in rigel yn index.txt, en it probleem krimpt ta in begrinzge databasefraach mei in antwurd dat te kontrolearjen is.

Lês de flater as in klacht oer de database

Elke openssl ca oanrop giet troch syn tekstdatabase foardat er eat ûndertekenet. Elke rigel befettet in statusletter, in ferfaltiidstimpel, in opsjonele weromroppingstiidstimpel, in searjenûmer yn hex, in bestânsnamme en it ûnderwerp. As ien fjild net parst, rapportearret it kommando it rigelnûmer en stopt, ynstee fan 'e rest fan it record te rieden.

Dat stopjen is beskermjend ynstee fan pedantysk. In record dat it helpmiddel net lêze kin, lit it net ta om te besluten oft it frege ûnderwerp al bestiet, oft in searjenûmer útjûn is, of wat de folgjende CRL befetsje moat. Trochgean oer in minne rigel soe krekt dy stille ynkonsistinsje produsearje dy't moannen letter opkomt, meastentiids by in weromropping dy't nimmen ferklearje kin. Lês it berjocht as in klacht oer de gegevens, en it ûndersyk bliuwt binnen de CA-map.

Kopiearje de CA-steat foardat jo eat oanreitsje

Nim in momintopname fan 'e hiele CA-map, net allinnich fan it databasebestân. De yndeks, syn attribútbestân, de bestannen foar searjenûmer en CRL-nûmer, de partikuliere kaai en de útjûne sertifikaten dogge allegear mei oan lettere operaasjes, en in reparaasje dy't ien werombringt en de oaren mist, makket in twadde ynsidint. Brûk de eigen reservekopy-routine fan 'e CA wêr't dy bestiet, en pauzearje it plande útjaan foar de doer fan it wurk.

Skriuw de OpenSSL-build en it konfiguraasjebestân op dat it mislearre kommando eins laden hat. Ynstallaasjes hâlde faak mear as ien CA-map, en de flater betsjut allinnich eat tsjin 'e database dy't de keazen konfiguraasje neamt.

Fyn de ynfier en dekodearje syn datumfjild

It rapportearre rigelnûmer wurdt fan it earste record ôf teld, dus sed -n '22p' index.txt lânet op 'e problematyske ynfier sadree't jo befêstige hawwe dat der gjin lege rigels of kommentaren boppe steane. Printsje dy rigel mei sichtbere skiedingstekens, want tabbladen en eftersteande spaasjes binne gewoan en ûnsichtber yn in gewoan bewurkingsfinster.

It ferfalfjild is in tiidstimpel wêrfan't de breedte fan it jier ôfhinget. Wearden oant 2049 wurde yn UTCTime skreaun as YYMMDDHHMMSSZ, wylst lettere wearden oergean nei GeneralizedTime mei in fjouwer-sifer jier. In record dat de twa foarmen mingt, of dat in twa-sifer jier draacht wêr't de parser no fjouwer ferwachtet, falt krekt op dit punt. Krektlyk in ôfkapt fjild dat troch in ûnderbrutsen skriuwerij efterlitten is.

Fergelykje it record mei it sertifikaat dêr't it nei ferwiist, net mei it bestân fan in oare CA. It ûndertekene sertifikaat is it gesach oer wat de jildichheid sizze moat, en it bestiet al as in te parsen objekt.

Reparearje it record neffens it ûndertekene sertifikaat

Lês de echte datums mei openssl x509 -in issued.pem -noout -dates -serial -subject. Konvertearje notAfter nei de stimpelbreedte dy't jo build foar dat jier skriuwt, en befêstigje dat it searjenûmer oerienkomt mei de ynfier dy't jo op it punt steane te bewurkjen foardat jo ien teken feroarje.

Bewurkje allinnich it stikene fjild, hâld de statusletter en it searjenûmer, en lit de rest fan 'e rigel gewurde. As it record mei gjin inkeld ûndertekene sertifikaat ferienige wurde kin, behannelje it dan as in ferswaaid ynfier en nim it werom fia it eigen weromroppingspaad fan 'e CA, ynstee fan 'e rigel mei de hân te wiskjen.

Reparearje net troch in datum by te knippen om by in gissing oer it jier te passen. In knip fan twa tekens is net oer te dragen tusken builds, en it feroaret stil de jildichheid dy't de database oan takomstige dûbele-ûnderwerp- en CRL-kontrôles rapportearret. As de oarspronklike wearde net werom te heljen is, jaan dan opnij út ûnder in nij searjenûmer en skriuw op wêrom't de âlde ferlitten is. It auditspoar is diel fan 'e reparaasje, gjin papierwinkel deromhinne.

Kontrolearje útjaan en CRL-generaasje foardat jo fuortgeane

Run ien útjaan mei deselde konfiguraasje en befêstigje dat it sûnder klacht oer in rigelnûmer foltôget. Generearje dan in CRL mei openssl ca -gencrl -config openssl.cnf en kontrolearje dat er parst, want in skansearre record komt faak dêr oan it ljocht en net by it ûndertekenjen.

Undersykje it nije sertifikaat mei openssl x509 -noout -dates -serial en fergelykje it mei de rigel dy't de CA krekt skreaun hat. Befêstigje dat de statusletter en de ferfaldatum mei it sertifikaat oerienkomme, en befêstigje dat openssl verify -CAfile ca.pem issued.pem sûnder flater weromkomt. Set dan it plande útjaan wer oan en hâld de earste run yn 'e gaten, want in twadde misfoarme rigel kundiget him fuortendaliks oan.