openssl ca: ugyldig udløbsdato i index.txt, og hvordan du retter den

En udstedelseskørsel stopper med entry 22: invalid expiry date, og anmodningen foran dig er fuldstændig i orden. Klagen kommer fra CA-databasens parser, ikke fra CSR'en og ikke fra VPN-klienten, som til sidst vil fremvise certifikatet. Den sondring afgør alt derefter: en post er misdannet, så reparationen hører til i CA'ens tilstand og ikke i anmodningen eller i peer-konfigurationen. Behandl den nummererede post som en linje i index.txt, og problemet skrumper ind til et afgrænset dataspørgsmål med et svar, du kan kontrollere.

Læs fejlen som en klage over databasen

Hvert openssl ca kald gennemgår sin tekstdatabase, før det signerer noget. Hver linje rummer et statusbogstav, et udløbstidsstempel, et valgfrit tilbagekaldelsestidsstempel, et serienummer i hex, et filnavn og subjektet. Når ét felt ikke kan parses, rapporterer kommandoen linjenummeret og stopper i stedet for at gætte på resten af posten.

Det stop er beskyttende snarere end pedantisk. En post, som værktøjet ikke kan læse, efterlader det ude af stand til at afgøre, om det ønskede subjekt allerede findes, om et serienummer er udleveret, eller hvad den næste CRL bør indeholde. At fortsætte forbi en dårlig linje ville frembringe præcis den stille inkonsistens, som dukker op måneder senere, normalt under en tilbagekaldelse, som ingen kan forklare. Læs meddelelsen som en klage over dataene, og undersøgelsen bliver inde i CA-biblioteket.

Kopiér CA'ens tilstand, før du rører noget

Tag et snapshot af hele CA-biblioteket, ikke kun databasefilen. Indekset, dets attributfil, filerne med serienummer og CRL-nummer, den private nøgle og de udstedte certifikater deltager alle i senere operationer, og en reparation, der genskaber én og mangler de andre, skaber en ny hændelse. Brug CA'ens egen backup-rutine, hvor der findes en, og sæt planlagt udstedelse på pause, mens arbejdet står på.

Notér den OpenSSL-build og den konfigurationsfil, som den fejlende kommando faktisk indlæste. Installationer holder ofte mere end ét CA-bibliotek, og fejlen betyder kun noget i forhold til den database, som den valgte konfiguration peger på.

Find posten, og afkod dens datofelt

Det rapporterede linjenummer tælles fra den første post, så sed -n '22p' index.txt lander på den problematiske post, når du først har bekræftet, at der ikke er tomme linjer eller kommentarer oven over. Udskriv linjen med synlige afgrænsere, fordi tabulatorer og efterfølgende mellemrum er almindelige og usynlige i et almindeligt editorvindue.

Udløbsfeltet er et tidsstempel, hvis bredde afhænger af året. Værdier til og med 2049 skrives i UTCTime som YYMMDDHHMMSSZ, mens senere værdier skifter til GeneralizedTime med et firecifret år. En post, der blander de to former, eller som bærer et tocifret år, hvor parseren nu forventer fire, fejler præcis på dette punkt. Det samme gør et afkortet felt, som en afbrudt skrivning har efterladt.

Sammenlign posten med det certifikat, den henviser til, i stedet for med en anden CA's fil. Det signerede certifikat er autoriteten på, hvad gyldigheden bør sige, og det findes allerede som et objekt, der kan parses.

Reparér posten mod det signerede certifikat

Læs de rigtige datoer med openssl x509 -in issued.pem -noout -dates -serial -subject. Omregn notAfter til den stempelbredde, som din build skriver for det år, og bekræft, at serienummeret stemmer med den post, du er ved at redigere, før du ændrer ét tegn.

Redigér kun det ødelagte felt, behold statusbogstavet og serienummeret, og lad resten af linjen være. Hvis posten ikke kan afstemmes med noget signeret certifikat, så behandl den som en vildfaren post og pensionér den ad CA'ens egen tilbagekaldelsesvej i stedet for at slette linjen i hånden.

Reparér ikke ved at klippe en dato til, så den passer på et gæt om året. Et snit på to tegn er ikke portabelt mellem builds, og det ændrer stille den gyldighed, som databasen rapporterer til fremtidige dublet-subjekt- og CRL-kontroller. Når den oprindelige værdi ikke kan genskabes, genudsted med et nyt serienummer og skriv ned, hvorfor den gamle blev forladt. Sporet er en del af reparationen, ikke papirarbejde omkring den.

Kontrollér udstedelse og CRL-generering, før du går

Kør én udstedelse med den samme konfiguration, og bekræft, at den fuldføres uden klage over et linjenummer. Generér derefter en CRL med openssl ca -gencrl -config openssl.cnf og kontrollér, at den kan parses, fordi en beskadiget post ofte dukker op der i stedet for under signeringen.

Undersøg det nye certifikat med openssl x509 -noout -dates -serial og sammenlign det med den linje, CA'en netop har skrevet. Bekræft, at statusbogstavet og udløbsdatoen stemmer med certifikatet, og bekræft, at openssl verify -CAfile ca.pem issued.pem vender tilbage uden fejl. Genoptag derefter den planlagte udstedelse, og hold øje med den første kørsel, fordi en anden misdannet linje melder sig straks.