openssl ca: ogiltigt utgångsdatum i index.txt och hur du rättar det

En utfärdandekörning stannar med entry 22: invalid expiry date, och begäran framför dig är helt i sin ordning. Klagomålet kommer från CA-databasens parser, inte från CSR:n och inte från VPN-klienten som till slut kommer att presentera certifikatet. Den skillnaden avgör allt som följer: en post är felaktigt utformad, så reparationen hör hemma i CA-tillståndet och inte i begäran eller i peer-konfigurationen. Behandla den numrerade posten som en rad i index.txt, och problemet krymper till en avgränsad datafråga med ett svar du kan kontrollera.

Läs felet som ett klagomål på databasen

Varje openssl ca anrop går igenom sin textdatabas innan det signerar något. Varje rad innehåller en statusbokstav, en utgångstidsstämpel, en valfri återkallningstidsstämpel, ett serienummer i hex, ett filnamn och subjektet. När ett fält inte kan tolkas rapporterar kommandot radnumret och stannar i stället för att gissa resten av posten.

Det stoppet är skyddande och inte pedantiskt. En post som verktyget inte kan läsa gör det oförmöget att avgöra om det efterfrågade subjektet redan finns, om ett serienummer har delats ut eller vad nästa CRL bör innehålla. Att fortsätta förbi en dålig rad skulle producera precis den tysta inkonsekvens som dyker upp månader senare, vanligtvis under en återkallning som ingen kan förklara. Läs meddelandet som ett klagomål på data, och utredningen stannar inne i CA-katalogen.

Kopiera CA-tillståndet innan du rör något

Ta en ögonblicksbild av hela CA-katalogen, inte bara databasfilen. Indexet, dess attributfil, filerna för serienummer och CRL-nummer, den privata nyckeln och de utfärdade certifikaten deltar alla i senare operationer, och en reparation som återställer en och missar de andra skapar en ny incident. Använd CA:ns egen säkerhetskopieringsrutin där en finns, och pausa planerad utfärdning under arbetets gång.

Notera OpenSSL-bygget och konfigurationsfilen som det misslyckade kommandot faktiskt laddade. Installationer håller ofta mer än en CA-katalog, och felet betyder bara något mot den databas som den valda konfigurationen pekar ut.

Hitta posten och avkoda dess datumfält

Det rapporterade radnumret räknas från första posten, så sed -n '22p' index.txt landar på den problematiska posten när du väl har bekräftat att det inte står tomma rader eller kommentarer ovanför. Skriv ut raden med synliga avgränsare, eftersom tabbar och avslutande mellanslag är vanliga och osynliga i ett vanligt redigeringsfönster.

Utgångsfältet är en tidsstämpel vars bredd beror på året. Värden till och med 2049 skrivs i UTCTime som YYMMDDHHMMSSZ, medan senare värden går över till GeneralizedTime med ett fyrsiffrigt år. En post som blandar de två formerna, eller som bär ett tvåsiffrigt år där parsern nu förväntar sig fyra, misslyckas exakt på denna punkt. Det gör också ett avkortat fält som en avbruten skrivning har lämnat efter sig.

Jämför posten med certifikatet den hänvisar till, inte med filen för en annan CA. Det signerade certifikatet är auktoriteten för vad giltigheten ska säga, och det finns redan som ett objekt som kan tolkas.

Reparera posten mot det signerade certifikatet

Läs de verkliga datumen med openssl x509 -in issued.pem -noout -dates -serial -subject. Konvertera notAfter till den stämpelbredd som ditt bygge skriver för det året, och bekräfta att serienumret stämmer med den post du är på väg att redigera innan du ändrar ett enda tecken.

Redigera bara det trasiga fältet, behåll statusbokstaven och serienumret, och låt resten av raden vara. Om posten inte kan stämmas av mot något signerat certifikat, behandla den som en vilsegången post och avveckla den via CA:ns egen återkallningsväg i stället för att radera raden för hand.

Reparera inte genom att klippa en datum för att passa en gissning om året. Ett snitt på två tecken är inte portabelt mellan byggen, och det ändrar tyst den giltighet som databasen rapporterar till framtida kontroller av dubblettsubjekt och CRL. När det ursprungliga värdet inte kan återställas, utfärda på nytt under ett nytt serienummer och skriv ned varför det gamla övergavs. Spåret är en del av reparationen, inte pappersarbete runt den.

Kontrollera utfärdande och CRL-generering innan du går

Kör en utfärdning med samma konfiguration och bekräfta att den slutförs utan klagomål på ett radnummer. Generera sedan en CRL med openssl ca -gencrl -config openssl.cnf och kontrollera att den kan tolkas, eftersom en skadad post ofta dyker upp där och inte under signeringen.

Granska det nya certifikatet med openssl x509 -noout -dates -serial och jämför det med raden som CA:n just skrev. Bekräfta att statusbokstaven och utgångsdatumet stämmer med certifikatet, och bekräfta att openssl verify -CAfile ca.pem issued.pem kommer tillbaka utan fel. Återställ sedan den planerade utfärdningen och håll koll på första körningen, eftersom en andra felaktig rad anmäler sig direkt.