openssl ca: data di scadenza non valida in index.txt e come ripararla

Un'esecuzione di emissione si ferma con entry 22: invalid expiry date, e la richiesta che avete davanti è perfettamente valida. La lamentela arriva dal parser del database della CA, non dalla CSR e non dal client VPN che alla fine presenterà il certificato. Questa distinzione decide tutto il resto: un record è malformato, quindi la riparazione appartiene allo stato della CA e non alla richiesta né alla configurazione del peer. Trattate la voce numerata come una riga di index.txt, e il problema si riduce a una domanda sui dati circoscritta con una risposta verificabile.

Leggete l'errore come una lamentela sul database

Ogni openssl ca invocazione percorre il suo database testuale prima di firmare qualcosa. Ogni riga contiene una lettera di stato, un timestamp di scadenza, un timestamp di revoca opzionale, un numero di serie in esadecimale, un nome di file e il soggetto. Quando un campo non si analizza, il comando segnala il numero di riga e si ferma invece di indovinare il resto del record.

Quella fermata è protettiva, non pedante. Un record che lo strumento non riesce a leggere lo lascia incapace di decidere se il soggetto richiesto esista già, se sia stato assegnato un numero di serie o cosa debba contenere la prossima CRL. Proseguire oltre una riga difettosa produrrebbe esattamente quell'incoerenza silenziosa che riemerge mesi dopo, di solito durante una revoca che nessuno sa spiegare. Leggete il messaggio come una lamentela sui dati, e l'indagine resta dentro la directory della CA.

Copiate lo stato della CA prima di toccare qualsiasi cosa

Fate uno snapshot dell'intera directory della CA, non solo del file del database. L'indice, il suo file di attributi, i file del numero di serie e del numero di CRL, la chiave privata e i certificati emessi partecipano tutti alle operazioni successive, e una riparazione che ne ripristina uno e trascura gli altri crea un secondo incidente. Usate la routine di backup propria della CA dove esiste, e sospendete l'emissione pianificata per la durata del lavoro.

Annotate la build di OpenSSL e il file di configurazione che il comando fallito ha realmente caricato. Le installazioni spesso tengono più di una directory CA, e l'errore ha senso solo rispetto al database che la configurazione scelta nomina.

Trovate la voce e decodificatene il campo data

Il numero di riga segnalato si conta dal primo record, quindi sed -n '22p' index.txt cade sulla voce incriminata una volta confermato che sopra non ci sono righe vuote né commenti. Stampate quella riga con delimitatori visibili, perché tabulazioni e spazi finali sono comuni e invisibili in una normale finestra di editor.

Il campo di scadenza è un timestamp la cui larghezza dipende dall'anno. I valori fino al 2049 si scrivono in UTCTime come YYMMDDHHMMSSZ, mentre i valori successivi passano a GeneralizedTime con un anno a quattro cifre. Un record che mescola le due forme, o che porta un anno a due cifre dove il parser ora ne attende quattro, fallisce esattamente in questo punto. Lo stesso vale per un campo troncato lasciato da una scrittura interrotta.

Confrontate il record con il certificato a cui si riferisce, non con il file di un'altra CA. Il certificato firmato è l'autorità su ciò che la validità dovrebbe dire, ed esiste già come oggetto analizzabile.

Riparate il record in base al certificato firmato

Leggete le date reali con openssl x509 -in issued.pem -noout -dates -serial -subject. Convertite notAfter nella larghezza del timestamp che la vostra build scrive per quell'anno, e confermate che il numero di serie corrisponda alla voce che state per modificare prima di cambiare un solo carattere.

Modificate solo il campo rotto, conservate la lettera di stato e il numero di serie, e lasciate in pace il resto della riga. Se il record non si può riconciliare con nessun certificato firmato, trattatelo come voce fuori posto e ritiratelo attraverso il percorso di revoca proprio della CA invece di cancellare la riga a mano.

Non riparate tagliando una data per farla rientrare in una congettura sull'anno. Un taglio di due caratteri non è portabile tra build, e cambia in silenzio la validità che il database riporta ai futuri controlli su soggetti duplicati e CRL. Quando il valore originale è irrecuperabile, rieseguite l'emissione con un nuovo numero di serie e annotate perché il vecchio è stato abbandonato. La traccia di audit fa parte della riparazione, non è carta che le sta intorno.

Verificate l'emissione e la generazione della CRL prima di andarvene

Eseguite un'emissione con la stessa configurazione e confermate che termina senza lamentele sul numero di riga. Poi generate una CRL con openssl ca -gencrl -config openssl.cnf e controllate che si analizzi, perché un record danneggiato spesso emerge lì e non durante la firma.

Ispezionate il nuovo certificato con openssl x509 -noout -dates -serial e confrontatelo con la riga che la CA ha appena scritto. Confermate che la lettera di stato e la scadenza concordino con il certificato, e confermate che openssl verify -CAfile ca.pem issued.pem torni senza errori. Poi ripristinate l'emissione pianificata e osservate la prima esecuzione, perché una seconda riga malformata si annuncerà subito.