openssl ca: ugyldig utløpsdato i index.txt, og korleis du rettar han

Ein utstedingskøyring stoppar med entry 22: invalid expiry date, og førespurnaden framfor deg er heilt i orden. Klaga kjem frå parsaren til CA-databasen, ikkje frå CSR-en og ikkje frå VPN-klienten som til slutt vil leggje fram sertifikatet. Den skilnaden avgjer alt etterpå: ein post er misdanna, så reparasjonen høyrer heime i CA-tilstanden og ikkje i førespurnaden eller i peer-konfigurasjonen. Behandle den nummererte oppføringa som ei line i index.txt, og problemet krympar til eit avgrensa dataspørsmål med eit svar du kan kontrollere.

Les feilen som ei klage på databasen

Kvart openssl ca kall går gjennom tekstdatabasen sin før det signerer noko. Kvar line inneheld ein statusbokstav, eit utløpstidsstempel, eit valfritt tilbakekallingstidsstempel, eit serienummer i hex, eit filnamn og subjektet. Når eitt felt ikkje kan parsast, rapporterer kommandoen linenummeret og stoppar i staden for å gjette resten av posten.

Den stoppen er vernande og ikkje pedantisk. Ein post verktøyet ikkje kan lese, gjer det ute av stand til å avgjere om det etterspurde subjektet alt finst, om eit serienummer er delt ut, eller kva neste CRL bør innehalde. Å halde fram forbi ei dårleg line ville produsere nettopp den stille inkonsistensen som dukkar opp månader seinare, vanlegvis under ei tilbakekalling ingen kan forklare. Les meldinga som ei klage på dataa, og granskinga held seg inne i CA-katalogen.

Kopier CA-tilstanden før du rører noko

Ta eit augeblinksbilete av heile CA-katalogen, ikkje berre databasefila. Indeksen, attributtfila, filene for serienummer og CRL-nummer, den private nøkkelen og dei utstedte sertifikata deltar alle i seinare operasjonar, og ein reparasjon som gjenopprettar éin og manglar dei andre skapar ei ny hending. Bruk den eigne sikkerheitskopirrutinen til CA-en der han finst, og set planlagd utsteding på pause medan arbeidet pågår.

Noter OpenSSL-bygget og konfigurasjonsfila som den feilande kommandoen faktisk lasta. Installasjonar held ofte meir enn éin CA-katalog, og feilen tyder berre noko mot databasen som den valde konfigurasjonen peikar på.

Finn oppføringa og dekod datofeltet

Det rapporterte linenummeret blir talt frå første post, så sed -n '22p' index.txt landar på den problematiske oppføringa når du først har stadfesta at det ikkje står tomme liner eller kommentarar over henne. Skriv ut den lina med synlege skiljeteikn, fordi tabulatorar og etterfølgjande mellomrom er vanlege og usynlege i eit vanleg editorvindauge.

Utløpsfeltet er eit tidsstempel der breidda avheng av året. Verdiar til og med 2049 blir skrivne i UTCTime som YYMMDDHHMMSSZ, medan seinare verdiar går over til GeneralizedTime med eit firesifra år. Ein post som blandar dei to formene, eller som ber eit tosifra år der parsaren no ventar fire, feilar nøyaktig på dette punktet. Det same gjer eit avkorta felt som ein avbroten skriving har late etter seg.

Samanlikn posten med sertifikatet han viser til, ikkje med fila til ein annan CA. Det signerte sertifikatet er autoriteten på kva gyldigheita skal seie, og det finst alt som eit objekt som kan parsast.

Reparer posten mot det signerte sertifikatet

Les dei verkelege datoane med openssl x509 -in issued.pem -noout -dates -serial -subject. Konverter notAfter til den stempelbreidda bygget ditt skriv for det året, og stadfest at serienummeret stemmer med oppføringa du er i ferd med å redigere før du endrar eitt teikn.

Rediger berre det øydelagde feltet, hald på statusbokstaven og serienummeret, og lat resten av lina vere. Viss posten ikkje kan avstemmast mot noko signert sertifikat, handsam han som ei villfaren oppføring og pensioner henne via den eigne tilbakekallingsvegen til CA-en i staden for å slette lina for hand.

Ikkje reparer ved å klippe ein dato til for å passe eit gjett om året. Eit kutt på to teikn er ikkje portabelt mellom bygg, og det endrar stille gyldigheita databasen rapporterer til framtidige kontrollar av duplikatsubjekt og CRL. Når den opphavlege verdien ikkje kan gjenopprettast, utsted på nytt under eit nytt serienummer og skriv ned kvifor den gamle vart forlaten. Sporet er ein del av reparasjonen, ikkje papirarbeid rundt han.

Kontroller utsteding og CRL-generering før du går

Køyr éi utsteding med same konfigurasjon og stadfest at ho blir fullført utan klage på eit linenummer. Generer deretter ein CRL med openssl ca -gencrl -config openssl.cnf og kontroller at han kan parsast, fordi ein skadd post ofte dukkar opp der og ikkje under signeringa.

Undersøk det nye sertifikatet med openssl x509 -noout -dates -serial og samanlikn det med lina CA-en nettopp skreiv. Stadfest at statusbokstaven og utløpsdatoen stemmer med sertifikatet, og stadfest at openssl verify -CAfile ca.pem issued.pem kjem tilbake utan feil. Ta deretter opp att den planlagde utstedinga og følg med på første køyring, fordi ei anna misdanna line melder seg straks.