openssl ca: kehtetu aegumiskuupäev failis index.txt ja kuidas seda parandada

Väljastamise käivitus peatub kohal entry 22: invalid expiry date, ja teie ees olev taotlus on täiesti korras. Kaebus tuleb CA andmebaasi parserilt, mitte CSR-ilt ja mitte VPN-kliendilt, mis sertifikaadi lõpuks esitab. See eristus määrab kõik järgneva: kirje on vigane, seega kuulub parandus CA olekusse, mitte taotlusesse ega partneri konfiguratsiooni. Käsitlege numereeritud kirjet reana failis index.txt, ja probleem taandub piiritletud andmeküsimuseks, millele saab vastust kontrollida.

Lugege viga andmebaasi kaebusena

Iga openssl ca kutse käib enne millegi allkirjastamist läbi oma tekstilise andmebaasi. Iga rida sisaldab olekutähte, aegumise ajatemplit, valikulist tühistamise ajatemplit, seerianumbrit kuueteistkümnendsüsteemis, failinime ja subjekti. Kui üks väli ei ole parsitav, teatab käsk reanumbri ja peatub, selle asemel et ülejäänud kirje üle oletada.

See peatumine on kaitsev, mitte pedantne. Kirje, mida tööriist lugeda ei suuda, jätab ta otsustusvõimetuks: kas soovitud subjekt on juba olemas, kas seerianumber on välja antud või mida peaks järgmine CRL sisaldama. Vigasest reast möödumine tekitaks täpselt selle vaikse vastuolu, mis kerkib esile kuude pärast, tavaliselt tühistamise ajal, mida keegi seletada ei oska. Lugege sõnumit andmete kaebusena ja uurimine jääb CA kataloogi sisse.

Kopeerige CA olek enne, kui midagi puudutate

Tehke hetktõmmis kogu CA kataloogist, mitte ainult andmebaasifailist. Indeks, selle atribuudifail, seerianumbri ja CRL-i numbri failid, privaatvõti ja väljastatud sertifikaadid osalevad kõik hilisemates toimingutes, ja parandus, mis taastab ühe ning jätab teised kõrvale, loob teise juhtumi. Kasutage CA enda varundusrutiini, kus see olemas on, ja peatage töö ajaks plaaniline väljastamine.

Kirjutage üles OpenSSL-i build ja konfiguratsioonifail, mille ebaõnnestunud käsk tegelikult laadis. Paigaldused hoiavad sageli rohkem kui üht CA kataloogi, ja viga tähendab midagi ainult selle andmebaasi suhtes, mille valitud konfiguratsioon nimetab.

Leidke kirje ja dekodeerige selle kuupäevaväli

Teatatud reanumbrit loetakse esimesest kirjest, seega sed -n '22p' index.txt satub probleemsele kirjele pärast seda, kui olete kinnitanud, et selle kohal ei ole tühje ridu ega kommentaare. Printige see rida nähtavate eraldajatega, sest tabulaatorid ja lõpu tühikud on tavalised ja tavalises redaktoraknas nähtamatud.

Aegumisväli on ajatempel, mille laius sõltub aastast. Väärtused kuni 2049 kirjutatakse UTCTime kujul YYMMDDHHMMSSZ, hilisemad väärtused lähevad aga üle neljakohalise aastaga GeneralizedTime kujule. Kirje, mis segab kahte vormi või kannab kahekohalist aastat seal, kus parser ootab nüüd nelja, ebaõnnestub täpselt selles punktis. Nii ka katkestatud kirjutamisest maha jäänud kärbitud väli.

Võrrelge kirjet sertifikaadiga, millele see viitab, mitte mõne teise CA failiga. Allkirjastatud sertifikaat on autoriteet selle kohta, mida kehtivus peaks ütlema, ja see on juba olemas parsitava objektina.

Parandage kirje allkirjastatud sertifikaadi järgi

Lugege tegelikud kuupäevad välja käsuga openssl x509 -in issued.pem -noout -dates -serial -subject. Teisendage notAfter ajatempli laiuseks, mille teie build selle aasta jaoks kirjutab, ja kinnitage enne ühegi märgi muutmist, et seerianumber vastab kirjele, mida kavatsete muuta.

Muutke ainult katkist välja, jätke olekutäht ja seerianumber alles ning jätke ülejäänud rida puutumata. Kui kirjet ei saa ühegi allkirjastatud sertifikaadiga vastavusse viia, käsitlege seda eksinud kirjena ja vedage see välja CA enda tühistamistee kaudu, selle asemel et rida käsitsi kustutada.

Ärge parandage kuupäeva kärpimisega, et see sobiks oletusega aasta kohta. Kahemärgiline lõige ei ole buildide vahel ülekantav ja muudab vaikselt kehtivust, mida andmebaas teatab tulevastele duplikaat-subjekti ja CRL-i kontrollidele. Kui algset väärtust ei saa taastada, väljastage uuesti uue seerianumbriga ja kirjutage üles, miks vana kõrvale jäeti. Auditijälg on paranduse osa, mitte selle ümber käiv paberimajandus.

Kontrollige väljastamist ja CRL-i genereerimist enne lahkumist

Käivitage üks väljastamine sama konfiguratsiooniga ja kinnitage, et see lõpeb ilma reanumbrikaebuseta. Seejärel genereerige CRL käsuga openssl ca -gencrl -config openssl.cnf ja kontrollige, et see parsitakse, sest kahjustatud kirje tuleb sageli esile just seal, mitte allkirjastamise ajal.

Vaadake uus sertifikaat üle käsuga openssl x509 -noout -dates -serial ja võrrelge seda reaga, mille CA äsja kirjutas. Kinnitage, et olekutäht ja aegumiskuupäev on sertifikaadiga kooskõlas, ja kinnitage, et openssl verify -CAfile ca.pem issued.pem naaseb veata. Seejärel taastage plaaniline väljastamine ja jälgige esimest käivitust, sest teine vigane rida annab kohe märku.