openssl ca: ugyldig utløpsdato i index.txt, og hvordan du retter den

En utstedelseskjøring stopper med entry 22: invalid expiry date, og forespørselen foran deg er helt i orden. Klagen kommer fra CA-databasens parser, ikke fra CSR-en og ikke fra VPN-klienten som til slutt vil legge fram sertifikatet. Den forskjellen avgjør alt etterpå: en post er misdannet, så reparasjonen hører hjemme i CA-tilstanden og ikke i forespørselen eller i peer-konfigurasjonen. Behandle den nummererte oppføringen som en linje i index.txt, og problemet krymper til et avgrenset dataspørsmål med et svar du kan kontrollere.

Les feilen som en klage på databasen

Hvert openssl ca kall går gjennom tekstdatabasen sin før det signerer noe. Hver linje inneholder en statusbokstav, et utløpstidsstempel, et valgfritt tilbakekallingstidsstempel, et serienummer i hex, et filnavn og subjektet. Når ett felt ikke kan parses, rapporterer kommandoen linjenummeret og stopper i stedet for å gjette resten av posten.

Den stoppen er beskyttende og ikke pedantisk. En post verktøyet ikke kan lese, gjør det ute av stand til å avgjøre om det etterspurte subjektet allerede finnes, om et serienummer er delt ut, eller hva neste CRL bør inneholde. Å fortsette forbi en dårlig linje ville produsere nettopp den stille inkonsistensen som dukker opp måneder senere, vanligvis under en tilbakekalling ingen kan forklare. Les meldingen som en klage på dataene, og undersøkelsen holder seg inne i CA-katalogen.

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

Ta et øyeblikksbilde av hele CA-katalogen, ikke bare databasefilen. Indeksen, attributtfilen, filene for serienummer og CRL-nummer, den private nøkkelen og de utstedte sertifikatene deltar alle i senere operasjoner, og en reparasjon som gjenoppretter én og mangler de andre skaper en ny hendelse. Bruk CA-ens egen sikkerhetskopiroutine der den finnes, og sett planlagt utstedelse på pause mens arbeidet pågår.

Noter OpenSSL-bygget og konfigurasjonsfilen som den feilende kommandoen faktisk lastet. Installasjoner holder ofte mer enn én CA-katalog, og feilen betyr bare noe mot databasen som den valgte konfigurasjonen peker på.

Finn oppføringen og dekod datofeltet

Det rapporterte linjenummeret telles fra første post, så sed -n '22p' index.txt lander på den problematiske oppføringen når du først har bekreftet at det ikke står tomme linjer eller kommentarer over den. Skriv ut linjen med synlige skilletegn, fordi tabulatorer og etterfølgende mellomrom er vanlige og usynlige i et vanlig editorvindu.

Utløpsfeltet er et tidsstempel hvis bredde avhenger av året. Verdier til og med 2049 skrives i UTCTime som YYMMDDHHMMSSZ, mens senere verdier går over til GeneralizedTime med et firesifret år. En post som blander de to formene, eller som bærer et tosifret år der parseren nå forventer fire, feiler nøyaktig på dette punktet. Det samme gjør et avkortet felt som en avbrutt skriving har etterlatt.

Sammenlign posten med sertifikatet den viser til, ikke med filen til en annen CA. Det signerte sertifikatet er autoriteten på hva gyldigheten skal si, og det finnes allerede som et objekt som kan parses.

Reparer posten mot det signerte sertifikatet

Les de virkelige datoene med openssl x509 -in issued.pem -noout -dates -serial -subject. Konverter notAfter til den stempelbredden bygget ditt skriver for det året, og bekreft at serienummeret stemmer med oppføringen du er i ferd med å redigere før du endrer ett tegn.

Rediger bare det ødelagte feltet, behold statusbokstaven og serienummeret, og la resten av linjen være. Hvis posten ikke kan avstemmes mot noe signert sertifikat, behandle den som en villfaren oppføring og pensioner den via CA-ens egen tilbakekallingsvei i stedet for å slette linjen for hånd.

Ikke reparer ved å klippe en dato til for å passe et gjett om året. Et kutt på to tegn er ikke portabelt mellom bygg, og det endrer stille gyldigheten databasen rapporterer til fremtidige kontroller av duplikatsubjekt og CRL. Når den opprinnelige verdien ikke kan gjenopprettes, utsted på nytt under et nytt serienummer og skriv ned hvorfor den gamle ble forlatt. Sporet er en del av reparasjonen, ikke papirarbeid rundt den.

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

Kjør én utstedelse med samme konfigurasjon og bekreft at den fullføres uten klage på et linjenummer. Generer deretter en CRL med openssl ca -gencrl -config openssl.cnf og kontroller at den kan parses, fordi en skadet post ofte dukker opp der og ikke under signeringen.

Undersøk det nye sertifikatet med openssl x509 -noout -dates -serial og sammenlign det med linjen CA-en nettopp skrev. Bekreft at statusbokstaven og utløpsdatoen stemmer med sertifikatet, og bekreft at openssl verify -CAfile ca.pem issued.pem kommer tilbake uten feil. Gjenoppta deretter den planlagte utstedelsen og følg med på første kjøring, fordi en annen misdannet linje melder seg straks.