openssl ca: neplatný dátum vypršania v index.txt a ako ho opraviť

Beh vydávania sa zastaví na entry 22: invalid expiry date, a požiadavka pred vami je úplne v poriadku. Sťažnosť prichádza z analyzátora databázy CA, nie z CSR a nie z klienta VPN, ktorý napokon certifikát predloží. Toto rozlíšenie určuje všetko ďalej: záznam je poškodený, takže oprava patrí do stavu CA, nie do požiadavky alebo konfigurácie partnera. Číslovaný záznam berte ako riadok v index.txt, a problém sa zúži na ohraničenú dátovú otázku s overiteľnou odpoveďou.

Čítajte chybu ako sťažnosť na databázu

Každé openssl ca volanie prechádza svojou textovou databázou, kým čokoľvek podpíše. Každý riadok nesie písmeno stavu, časovú pečiatku vypršania, voliteľnú pečiatku odvolania, sériové číslo v šestnástkovej sústave, názov súboru a subjekt. Keď sa jedno pole nedá analyzovať, príkaz nahlási číslo riadku a zastaví sa namiesto toho, aby zvyšok záznamu hádal.

Toto zastavenie je ochranné, nie pedantské. Záznam, ktorý nástroj nedokáže prečítať, ho necháva bez možnosti rozhodnúť, či požadovaný subjekt už existuje, či bolo pridelené sériové číslo alebo čo má obsahovať nasledujúci CRL. Pokračovanie za chybným riadkom by vytvorilo práve tú tichú nekonzistenciu, ktorá vypláva o mesiace neskôr, zvyčajne pri odvolaní, ktoré nikto nedokáže vysvetliť. Čítajte správu ako sťažnosť na dáta a vyšetrovanie zostane v adresári CA.

Skopírujte stav CA, skôr než sa čohokoľvek dotknete

Urobte snímku celého adresára CA, nielen súboru databázy. Index, jeho súbor atribútov, súbory sériového čísla a čísla CRL, súkromný kľúč a vydané certifikáty sa všetky zúčastňujú ďalších operácií, a oprava, ktorá obnoví jeden a ostatné vynechá, vytvorí druhý incident. Kde existuje, použite vlastnú zálohovaciu rutinu CA, a na čas práce pozastavte plánované vydávanie.

Zaznamenajte zostavenie OpenSSL a konfiguračný súbor, ktoré neúspešný príkaz skutočne načítal. Inštalácie často uchovávajú viac ako jeden adresár CA a chyba má význam len voči databáze, ktorú pomenúva zvolená konfigurácia.

Nájdite záznam a dekódujte jeho pole dátumu

Nahlásené číslo riadku sa počíta od prvého záznamu, takže sed -n '22p' index.txt dopadne na problematický záznam, keď potvrdíte, že nad ním nie sú prázdne riadky ani komentáre. Vypíšte ten riadok s viditeľnými oddeľovačmi, pretože tabulátory a koncové medzery sú bežné a v obyčajnom okne editora neviditeľné.

Pole vypršania je časová pečiatka, ktorej šírka závisí od roka. Hodnoty do 2049 sa zapisujú v UTCTime ako YYMMDDHHMMSSZ, zatiaľ čo neskoršie hodnoty prechádzajú na GeneralizedTime so štvormiestnym rokom. Záznam, ktorý mieša oba tvary, alebo nesie dvojmiestny rok tam, kde analyzátor teraz očakáva štyri, zlyhá presne v tomto bode. Rovnako skrátené pole, ktoré zanechalo prerušené zapisovanie.

Porovnávajte záznam s certifikátom, na ktorý odkazuje, a nie so súborom inej CA. Podpísaný certifikát je autoritou v tom, čo má platnosť hovoriť, a už existuje ako analyzovateľný objekt.

Opravte záznam podľa podpísaného certifikátu

Prečítajte skutočné dátumy pomocou openssl x509 -in issued.pem -noout -dates -serial -subject. Preveďte notAfter na šírku pečiatky, ktorú vaše zostavenie pre ten rok zapisuje, a pred zmenou jediného znaku potvrďte, že sériové číslo zodpovedá záznamu, ktorý sa chystáte upraviť.

Upravte len poškodené pole, ponechajte písmeno stavu aj sériové číslo a zvyšok riadku nechajte na pokoji. Ak sa záznam nedá zladiť so žiadnym podpísaným certifikátom, považujte ho za zblúdilý záznam a vyraďte ho vlastnou cestou odvolania CA namiesto ručného vymazania riadku.

Neopravujte tak, že dátum skrátite, aby sadol na odhad roka. Skrátenie o dva znaky nie je prenosné medzi zostaveniami a potichu mení platnosť, ktorú databáza hlási budúcim kontrolám duplicitného subjektu a CRL. Keď sa pôvodná hodnota nedá obnoviť, vydajte znova pod novým sériovým číslom a zapíšte, prečo bol starý opustený. Auditná stopa je súčasťou opravy, nie papierovačkou okolo nej.

Overte vydávanie a generovanie CRL, kým odídete

Spustite jedno vydávanie s tou istou konfiguráciou a potvrďte, že sa skončí bez sťažnosti na číslo riadku. Potom vygenerujte CRL pomocou openssl ca -gencrl -config openssl.cnf a skontrolujte, že sa dá analyzovať, pretože poškodený záznam sa často vynorí práve tam a nie pri podpisovaní.

Prezrite si nový certifikát pomocou openssl x509 -noout -dates -serial a porovnajte ho s riadkom, ktorý CA práve zapísala. Potvrďte, že písmeno stavu a dátum vypršania zodpovedajú certifikátu, a potvrďte, že openssl verify -CAfile ca.pem issued.pem sa vracia bez chyby. Potom obnovte plánované vydávanie a sledujte prvý beh, pretože druhý poškodený riadok sa ozve okamžite.