openssl ca: ongeldige vervaldatum in index.txt, en hoe om dit reg te maak

'n Uitreikingslopie stop met entry 22: invalid expiry date, en die versoek wat voor jou lê, is heeltemal in orde. Die klag kom van die CA-databasis se ontleder, nie van die CSR nie en ook nie van die VPN-kliënt wat die sertifikaat uiteindelik sal aanbied nie. Daardie onderskeid bepaal alles daarna: 'n rekord is wanvormig, dus hoort die herstel in die CA-toestand en nie in die versoek of die eweknie-konfigurasie nie. Behandel die genommerde inskrywing as 'n reël in index.txt, en die probleem krimp tot 'n afgebakende datavraag met 'n antwoord wat jy kan natrek.

Lees die fout as 'n klag oor die databasis

Elke openssl ca aanroeping loop eers deur sy teksdatabasis voordat dit iets onderteken. Elke reël hou 'n statusletter, 'n vervalstempel, 'n opsionele herroepingstempel, 'n reeksnommer in heksadesimaal, 'n lêernaam en die onderwerp. Wanneer een veld nie ontleed nie, rapporteer die opdrag die reëlnommer en stop in plaas daarvan om die res van die rekord te raai.

Daardie stop is beskermend eerder as pedanties. 'n Rekord wat die program nie kan lees nie, laat dit nie weet of die gevraagde onderwerp al bestaan nie, of 'n reeksnommer al uitgegee is nie, of wat die volgende CRL moet bevat nie. Om verby 'n slegte reël te gaan, sou juis die stille inkonsekwentheid lewer wat maande later opduik, gewoonlik tydens 'n herroeping wat niemand kan verduidelik nie. Lees die boodskap as 'n klag oor die data, en die ondersoek bly binne die CA-gids.

Kopieer die CA-toestand voordat jy iets aanraak

Neem 'n momentopname van die hele CA-gids, nie net die databasislêer nie. Die indeks, sy eienskaplêer, die reeksnommer- en CRL-nommerlêers, die private sleutel en die uitgereikte sertifikate is almal deel van latere bewerkings, en 'n herstel wat een daarvan terugbring terwyl die ander ontbreek, skep 'n tweede voorval. Gebruik die CA se eie rugsteunroetine waar daar een is, en onderbreek geskeduleerde uitreiking vir die duur van die werk.

Teken die OpenSSL-bou en die konfigurasielêer aan wat die mislukte opdrag werklik gelaai het. Installasies hou dikwels meer as een CA-gids, en die fout beteken net iets teen die databasis wat die gekose konfigurasie noem.

Vind die inskrywing en dekodeer sy datumveld

Die gerapporteerde reëlnommer tel vanaf die eerste rekord, so sed -n '22p' index.txt beland op die betrokke inskrywing sodra jy bevestig het dat daar geen leë of kommentaarreëls bo dit is nie. Druk daardie reël met sigbare skeiers, want oortjies en nasleepspasies is algemeen en onsigbaar in 'n gewone redigeervenster.

Die vervalveld is 'n stempel waarvan die wydte van die jaar afhang. Waardes tot 2049 word in UTCTime as YYMMDDHHMMSSZ geskryf, terwyl later waardes na GeneralizedTime met 'n vier-syfer jaar oorskakel. 'n Rekord wat die twee vorme meng, of wat 'n twee-syfer jaar dra waar die ontleder nou vier verwag, misluk presies op hierdie punt. So ook 'n afgekapte veld wat deur 'n onderbroke skryfaksie agtergelaat is.

Vergelyk die rekord met die sertifikaat waarna dit verwys, eerder as met 'n ander CA se lêer. Die ondertekende sertifikaat is die gesag oor wat die geldigheid behoort te sê, en dit bestaan reeds as 'n ontleedbare objek.

Herstel die rekord teen die ondertekende sertifikaat

Lees die werklike datums met openssl x509 -in issued.pem -noout -dates -serial -subject. Skakel notAfter om na die stempelwydte wat jou bou vir daardie jaar skryf, en bevestig dat die reeksnommer ooreenstem met die inskrywing wat jy op die punt is om te wysig voordat jy 'n karakter verander.

Wysig net die stukkende veld, hou die statusletter en die reeksnommer, en laat die res van die reël alleen. As die rekord nie met enige ondertekende sertifikaat versoen kan word nie, behandel dit as 'n verdwaalde inskrywing en trek dit deur die CA se eie herroepingsroete terug in plaas daarvan om die reël met die hand te skrap.

Moenie herstel deur 'n datum af te knip om by 'n raaiskoot oor die jaar te pas nie. 'n Snit van twee karakters is nie tussen bousels oordraagbaar nie, en dit verander stilweg die geldigheid wat die databasis aan toekomstige duplikaat-onderwerp- en CRL-kontroles rapporteer. Wanneer die oorspronklike waarde onherstelbaar is, heruitreik onder 'n nuwe reeksnommer en skryf neer waarom die oue laat vaar is. Die ouditspoor is deel van die herstel, nie papierwerk daar rondom nie.

Verifieer uitreiking en CRL-generering voordat jy wegstap

Voer een uitreiking met dieselfde konfigurasie uit en bevestig dat dit voltooi sonder 'n klag oor 'n reëlnommer. Genereer dan 'n CRL met openssl ca -gencrl -config openssl.cnf en kontroleer dat dit ontleed, want 'n beskadigde rekord duik dikwels daar op eerder as tydens die ondertekening.

Inspekteer die nuwe sertifikaat met openssl x509 -noout -dates -serial en vergelyk dit met die reël wat die CA pas geskryf het. Bevestig dat die statusletter en die vervaldatum met die sertifikaat ooreenstem, en bevestig dat openssl verify -CAfile ca.pem issued.pem sonder fout terugkeer. Herstel dan geskeduleerde uitreiking en hou die eerste lopie dop, want 'n tweede wanvormige reël kondig homself onmiddellik aan.