openssl ca: data de caducitat no vàlida a index.txt i com arreglar-la

Una execució d’emissió s’atura amb entry 22: invalid expiry date, i la sol·licitud que teniu al davant és perfectament correcta. La queixa prové de l’analitzador de la base de dades de la CA, no de la CSR ni del client VPN que finalment presentarà el certificat. Aquesta distinció decideix tot el que ve després: un registre està mal format, així que la reparació pertany a l’estat de la CA i no a la sol·licitud ni a la configuració del parell. Tracteu l’entrada numerada com una línia d’index.txt, i el problema es redueix a una pregunta de dades delimitada amb una resposta comprovable.

Llegiu l’error com una queixa de la base de dades

Cada openssl ca invocació recorre la seva base de dades de text abans de signar res. Cada línia conté una lletra d’estat, una marca de temps de caducitat, una marca de revocació opcional, un número de sèrie en hexadecimal, un nom de fitxer i el subjecte. Quan un camp no es pot analitzar, l’ordre informa del número de línia i s’atura en lloc d’endevinar la resta del registre.

Aquesta aturada és protectora i no pas pedant. Un registre que l’eina no pot llegir la deixa incapaç de decidir si el subjecte sol·licitat ja existeix, si ja s’ha lliurat un número de sèrie o què hauria de contenir la propera CRL. Continuar més enllà d’una línia dolenta produiria exactament aquella inconsistència silenciosa que surt mesos després, normalment durant una revocació que ningú no sap explicar. Llegiu el missatge com una queixa sobre les dades i la investigació es quedarà dins del directori de la CA.

Copieu l’estat de la CA abans de tocar res

Feu una instantània de tot el directori de la CA, no només del fitxer de la base de dades. L’índex, el seu fitxer d’atributs, els fitxers del número de sèrie i del número de CRL, la clau privada i els certificats emesos participen tots en les operacions posteriors, i una reparació que en restaura un i en deixa fora els altres crea un segon incident. Feu servir la rutina de còpia de seguretat pròpia de la CA quan n’hi hagi, i atureu l’emissió programada mentre duri la feina.

Anoteu la compilació d’OpenSSL i el fitxer de configuració que l’ordre fallida va carregar realment. Les instal·lacions sovint guarden més d’un directori de CA, i l’error només té sentit respecte de la base de dades que anomena la configuració seleccionada.

Trobeu l’entrada i descodifiqueu-ne el camp de data

El número de línia indicat es compta des del primer registre, així que sed -n '22p' index.txt cau sobre l’entrada conflictiva un cop hàgiu confirmat que no hi ha línies buides ni comentaris a sobre. Imprimiu aquella línia amb delimitadors visibles, perquè els tabuladors i els espais finals són freqüents i invisibles en una finestra d’editor corrent.

El camp de caducitat és una marca de temps l’amplada de la qual depèn de l’any. Els valors fins a 2049 s’escriuen en UTCTime com a YYMMDDHHMMSSZ, mentre que els valors posteriors passen a GeneralizedTime amb un any de quatre xifres. Un registre que barreja les dues formes, o que porta un any de dues xifres on l’analitzador ara n’espera quatre, falla exactament en aquest punt. També ho fa un camp truncat que hagi deixat una escriptura interrompuda.

Compareu el registre amb el certificat al qual fa referència i no amb el fitxer d’una altra CA. El certificat signat és l’autoritat sobre què ha de dir la validesa, i ja existeix com a objecte analitzable.

Repareu el registre contra el certificat signat

Llegiu les dates reals amb openssl x509 -in issued.pem -noout -dates -serial -subject. Convertiu notAfter a l’amplada de marca de temps que la vostra compilació escriu per a aquell any, i confirmeu que el número de sèrie coincideix amb l’entrada que esteu a punt d’editar abans de canviar un sol caràcter.

Editeu només el camp trencat, manteniu la lletra d’estat i el número de sèrie, i deixeu la resta de la línia tranquil·la. Si el registre no es pot reconciliar amb cap certificat signat, tracteu-lo com una entrada extraviada i retireu-lo pel camí de revocació propi de la CA en lloc d’esborrar la línia a mà.

No repareu retallant una data per encaixar-la amb una conjectura sobre l’any. Un tall de dos caràcters no és portable entre compilacions i canvia en silenci la validesa que la base de dades informa a les futures comprovacions de subjecte duplicat i de CRL. Quan el valor original no es pot recuperar, reemeteu amb un número de sèrie nou i anoteu per què es va abandonar el vell. El rastre d’auditoria forma part de la reparació, no és paperassa al seu voltant.

Verifiqueu l’emissió i la generació de CRL abans d’anar-vos-en

Feu una emissió amb la mateixa configuració i confirmeu que acaba sense cap queixa de número de línia. Després genereu una CRL amb openssl ca -gencrl -config openssl.cnf i comproveu que s’analitza, perquè un registre malmès sovint surt allà i no durant la signatura.

Inspeccioneu el certificat nou amb openssl x509 -noout -dates -serial i compareu-lo amb la línia que la CA acaba d’escriure. Confirmeu que la lletra d’estat i la caducitat concorden amb el certificat, i confirmeu que openssl verify -CAfile ca.pem issued.pem torna sense error. Després restaureu l’emissió programada i vigileu la primera execució, perquè una segona línia mal formada s’anunciarà de seguida.