openssl ca: dată de expirare invalidă în index.txt și cum o reparăm

O rulare de emitere se oprește la entry 22: invalid expiry date, iar cererea din fața dumneavoastră este perfect în regulă. Reclamația vine de la analizatorul bazei de date a CA, nu de la CSR și nu de la clientul VPN care va prezenta în cele din urmă certificatul. Această distincție decide tot ce urmează: o înregistrare este malformată, deci reparația aparține stării CA, nu cererii sau configurației partenerului. Tratați intrarea numerotată ca pe o linie din index.txt, iar problema se reduce la o întrebare de date delimitată, cu un răspuns verificabil.

Citiți eroarea ca pe o reclamație despre baza de date

Fiecare openssl ca apel parcurge baza sa de date text înainte de a semna ceva. Fiecare linie conține o literă de stare, un marcaj temporal de expirare, un marcaj de revocare opțional, un număr de serie în hexazecimal, un nume de fișier și subiectul. Când un câmp nu poate fi analizat, comanda raportează numărul liniei și se oprește în loc să ghicească restul înregistrării.

Oprirea aceea este protectoare, nu pedantă. O înregistrare pe care instrumentul nu o poate citi îl lasă incapabil să decidă dacă subiectul cerut există deja, dacă un număr de serie a fost atribuit sau ce ar trebui să conțină următorul CRL. Continuarea dincolo de o linie defectă ar produce exact acea inconsistență tăcută care iese la iveală luni mai târziu, de obicei în timpul unei revocări pe care nimeni nu o poate explica. Citiți mesajul ca pe o reclamație despre date, iar investigația rămâne în directorul CA.

Copiați starea CA înainte de a atinge ceva

Faceți o imagine a întregului director CA, nu doar a fișierului bazei de date. Indexul, fișierul său de atribute, fișierele numărului de serie și ale numărului CRL, cheia privată și certificatele emise participă toate la operațiunile ulterioare, iar o reparație care restaurează unul și le ratează pe celelalte creează un al doilea incident. Folosiți rutina proprie de copie de siguranță a CA acolo unde există și suspendați emiterea programată pe durata lucrării.

Notați build-ul OpenSSL și fișierul de configurare pe care comanda eșuată le-a încărcat efectiv. Instalările păstrează adesea mai mult de un director CA, iar eroarea are sens doar față de baza de date pe care o numește configurația selectată.

Găsiți intrarea și decodificați-i câmpul de dată

Numărul liniei raportate se numără de la prima înregistrare, așa că sed -n '22p' index.txt ajunge pe intrarea problematică după ce ați confirmat că deasupra ei nu există linii goale sau comentarii. Tipăriți acea linie cu delimitatori vizibili, pentru că tabulatorii și spațiile de la sfârșit sunt frecvente și invizibile într-o fereastră obișnuită de editor.

Câmpul de expirare este un marcaj temporal a cărui lățime depinde de an. Valorile până în 2049 se scriu în UTCTime ca YYMMDDHHMMSSZ, în timp ce valorile ulterioare trec la GeneralizedTime cu un an din patru cifre. O înregistrare care amestecă cele două forme, sau care poartă un an din două cifre acolo unde analizatorul așteaptă acum patru, eșuează exact în acest punct. La fel și un câmp trunchiat lăsat de o scriere întreruptă.

Comparați înregistrarea cu certificatul la care se referă, nu cu fișierul altei CA. Certificatul semnat este autoritatea asupra a ceea ce ar trebui să spună valabilitatea, și el există deja ca obiect analizabil.

Reparați înregistrarea după certificatul semnat

Citiți datele reale cu openssl x509 -in issued.pem -noout -dates -serial -subject. Convertiți notAfter în lățimea de marcaj pe care build-ul dumneavoastră o scrie pentru acel an, și confirmați că numărul de serie corespunde intrării pe care o veți edita înainte de a schimba un singur caracter.

Editați doar câmpul stricat, păstrați litera de stare și numărul de serie, și lăsați restul liniei în pace. Dacă înregistrarea nu poate fi reconciliată cu niciun certificat semnat, tratați-o ca pe o intrare rătăcită și retrageți-o pe calea proprie de revocare a CA, în loc să ștergeți linia de mână.

Nu reparați tăind o dată ca să se potrivească unei presupuneri despre an. O tăietură de două caractere nu este portabilă între build-uri și schimbă în tăcere valabilitatea pe care baza de date o raportează verificărilor viitoare de subiect duplicat și CRL. Când valoarea originală nu poate fi recuperată, reemiteți sub un număr de serie nou și notați de ce a fost abandonat cel vechi. Urma de audit face parte din reparație, nu este hârtie în jurul ei.

Verificați emiterea și generarea CRL înainte de a pleca

Rulați o emitere cu aceeași configurație și confirmați că se încheie fără reclamație privind numărul liniei. Apoi generați un CRL cu openssl ca -gencrl -config openssl.cnf și verificați că poate fi analizat, pentru că o înregistrare deteriorată apare adesea acolo și nu în timpul semnării.

Inspectați noul certificat cu openssl x509 -noout -dates -serial și comparați-l cu linia pe care CA tocmai a scris-o. Confirmați că litera de stare și data de expirare concordă cu certificatul, și confirmați că openssl verify -CAfile ca.pem issued.pem se întoarce fără eroare. Apoi restabiliți emiterea programată și urmăriți prima rulare, pentru că o a doua linie malformată se va anunța imediat.