openssl ca: neplatné datum vypršení v index.txt a jak ho opravit

Běh vydávání se zastaví na entry 22: invalid expiry date, a požadavek před vámi je zcela v pořádku. Stížnost přichází z parseru databáze CA, ne z CSR a ne z klienta VPN, který nakonec certifikát předloží. Toto rozlišení určuje vše další: záznam je poškozený, takže oprava patří do stavu CA, nikoli do požadavku nebo konfigurace protistrany. Číslovaný záznam berte jako řádek v index.txt, a problém se zúží na ohraničenou datovou otázku s ověřitelnou odpovědí.

Čtěte chybu jako stížnost na databázi

Každé openssl ca volání prochází svou textovou databází, než cokoli podepíše. Každý řádek nese písmeno stavu, časové razítko vypršení, volitelné razítko odvolání, sériové číslo v hexadecimálním tvaru, název souboru a subjekt. Když jedno pole nelze analyzovat, příkaz nahlásí číslo řádku a zastaví se, místo aby zbytek záznamu hádal.

Toto zastavení je ochranné, nikoli pedantské. Záznam, který nástroj nedokáže přečíst, ho nechává bez možnosti rozhodnout, zda požadovaný subjekt již existuje, zda bylo přiděleno sériové číslo nebo co má obsahovat příští CRL. Pokračování za vadným řádkem by vytvořilo právě tu tichou nekonzistenci, která vyplave o měsíce později, obvykle při odvolání, které nikdo nedokáže vysvětlit. Čtěte zprávu jako stížnost na data a vyšetřování zůstane uvnitř adresáře CA.

Zkopírujte stav CA, než se čehokoli dotknete

Pořiďte snímek celého adresáře CA, ne jen souboru databáze. Index, jeho soubor atributů, soubory sériového čísla a čísla CRL, soukromý klíč a vydané certifikáty se všechny účastní dalších operací, a oprava, která obnoví jeden a ostatní vynechá, vytvoří druhý incident. Kde existuje, použijte vlastní zálohovací rutinu CA, a po dobu práce pozastavte plánované vydávání.

Zaznamenejte build OpenSSL a konfigurační soubor, které neúspěšný příkaz skutečně načetl. Instalace často uchovávají více než jeden adresář CA a chyba má význam jen vůči databázi, kterou pojmenovává zvolená konfigurace.

Najděte záznam a dekódujte jeho pole data

Nahlášené číslo řádku se počítá od prvního záznamu, takže sed -n '22p' index.txt dopadne na problematický záznam, jakmile potvrdíte, že nad ním nejsou prázdné řádky ani komentáře. Vypište ten řádek s viditelnými oddělovači, protože tabulátory a koncové mezery jsou běžné a v obyčejném okně editoru neviditelné.

Pole vypršení je časové razítko, jehož šířka závisí na roce. Hodnoty do 2049 se zapisují v UTCTime jako YYMMDDHHMMSSZ, zatímco pozdější hodnoty přecházejí na GeneralizedTime se čtyřmístným rokem. Záznam, který míchá obě formy, nebo který nese dvoumístný rok tam, kde parser nyní očekává čtyři, selže přesně v tomto bodě. Stejně tak oříznuté pole, které zůstalo po přerušeném zápisu.

Srovnávejte záznam s certifikátem, na který odkazuje, a ne se souborem jiné CA. Podepsaný certifikát je autoritou v tom, co má platnost říkat, a už existuje jako analyzovatelný objekt.

Opravte záznam podle podepsaného certifikátu

Přečtěte skutečná data pomocí openssl x509 -in issued.pem -noout -dates -serial -subject. Převeďte notAfter na šířku razítka, kterou váš build pro tento rok zapisuje, a než změníte jediný znak, potvrďte, že sériové číslo odpovídá záznamu, který se chystáte upravit.

Upravte jen poškozené pole, ponechte písmeno stavu i sériové číslo a zbytek řádku nechte být. Pokud záznam nelze sladit s žádným podepsaným certifikátem, považujte ho za zbloudilý záznam a vyřaďte ho vlastní cestou odvolání v CA, místo abyste řádek mazali ručně.

Neopravujte to tak, že datum zkrátíte, aby odpovídalo odhadu roku. Zkrácení o dva znaky není přenositelné mezi buildy a tiše mění platnost, kterou databáze hlásí budoucím kontrolám duplicitního subjektu a CRL. Když původní hodnotu nelze obnovit, vydejte znovu pod novým sériovým číslem a zapište, proč byl starý opuštěn. Auditní stopa je součástí opravy, ne papírováním kolem ní.

Ověřte vydávání a generování CRL, než odejdete

Spusťte jedno vydávání se stejnou konfigurací a potvrďte, že skončí bez stížnosti na číslo řádku. Potom vygenerujte CRL pomocí openssl ca -gencrl -config openssl.cnf a zkontrolujte, že se analyzuje, protože poškozený záznam se často vynoří právě tam, a ne během podepisování.

Prohlédněte nový certifikát pomocí openssl x509 -noout -dates -serial a porovnejte ho s řádkem, který CA právě zapsala. Potvrďte, že písmeno stavu a datum vypršení odpovídají certifikátu, a potvrďte, že openssl verify -CAfile ca.pem issued.pem se vrací bez chyby. Potom obnovte plánované vydávání a sledujte první běh, protože druhý poškozený řádek se oznámí okamžitě.