openssl ca : date d’expiration invalide dans index.txt, et comment la réparer

Une exécution d’émission s’arrête sur entry 22: invalid expiry date, alors que la demande devant vous est parfaitement valide. Le reproche vient de l’analyseur de la base de données de la CA, pas de la CSR et pas du client VPN qui présentera finalement le certificat. Cette distinction décide de tout ce qui suit : un enregistrement est malformé, donc la réparation appartient à l’état de la CA, pas à la demande ni à la configuration du pair. Traitez l’entrée numérotée comme une ligne d’index.txt, et le problème se réduit à une question de données bornée dont la réponse est vérifiable.

Lisez l’erreur comme un reproche adressé à la base de données

Chaque openssl ca invocation parcourt sa base de données textuelle avant de signer quoi que ce soit. Chaque ligne porte une lettre d’état, un horodatage d’expiration, un horodatage de révocation facultatif, un numéro de série en hexadécimal, un nom de fichier et le sujet. Quand un champ ne s’analyse pas, la commande signale le numéro de ligne et s’arrête au lieu de deviner le reste de l’enregistrement.

Cet arrêt est protecteur plutôt que pointilleux. Un enregistrement que l’outil ne peut pas lire le laisse incapable de décider si le sujet demandé existe déjà, si un numéro de série a été attribué ou ce que la prochaine CRL devrait contenir. Continuer au-delà d’une mauvaise ligne produirait exactement cette incohérence silencieuse qui remonte des mois plus tard, généralement pendant une révocation que personne ne sait expliquer. Lisez le message comme un reproche sur les données, et l’enquête reste à l’intérieur du répertoire de la CA.

Copiez l’état de la CA avant de toucher à quoi que ce soit

Prenez un instantané de tout le répertoire de la CA, pas seulement du fichier de base de données. L’index, son fichier d’attributs, les fichiers du numéro de série et du numéro de CRL, la clé privée et les certificats émis participent tous aux opérations suivantes, et une réparation qui en restaure un en oubliant les autres crée un second incident. Utilisez la routine de sauvegarde propre à la CA lorsqu’il en existe une, et suspendez l’émission programmée pendant la durée du travail.

Notez la compilation d’OpenSSL et le fichier de configuration que la commande en échec a réellement chargés. Les installations conservent souvent plus d’un répertoire de CA, et l’erreur n’a de sens que par rapport à la base de données que nomme la configuration retenue.

Trouvez l’entrée et décodez son champ de date

Le numéro de ligne signalé se compte depuis le premier enregistrement, donc sed -n '22p' index.txt tombe sur l’entrée fautive une fois que vous avez confirmé qu’aucune ligne vide ni aucun commentaire ne la précède. Imprimez cette ligne avec des délimiteurs visibles, car les tabulations et les espaces de fin sont fréquents et invisibles dans une fenêtre d’éditeur ordinaire.

Le champ d’expiration est un horodatage dont la largeur dépend de l’année. Les valeurs jusqu’à 2049 s’écrivent en UTCTime sous la forme YYMMDDHHMMSSZ, tandis que les valeurs ultérieures passent en GeneralizedTime avec une année à quatre chiffres. Un enregistrement qui mélange les deux formes, ou qui porte une année à deux chiffres là où l’analyseur attend désormais quatre chiffres, échoue exactement à cet endroit. Tout comme un champ tronqué laissé par une écriture interrompue.

Comparez l’enregistrement au certificat auquel il renvoie plutôt qu’au fichier d’une autre CA. Le certificat signé fait autorité sur ce que la validité doit dire, et il existe déjà comme objet analysable.

Réparez l’enregistrement d’après le certificat signé

Lisez les vraies dates avec openssl x509 -in issued.pem -noout -dates -serial -subject. Convertissez notAfter vers la largeur d’horodatage que votre compilation écrit pour cette année-là, et confirmez que le numéro de série correspond à l’entrée que vous allez modifier avant de changer un seul caractère.

Ne modifiez que le champ cassé, conservez la lettre d’état et le numéro de série, et laissez le reste de la ligne tranquille. Si l’enregistrement ne peut être réconcilié avec aucun certificat signé, traitez-le comme une entrée égarée et retirez-le par la voie de révocation propre à la CA au lieu de supprimer la ligne à la main.

Ne réparez pas en rognant une date pour la faire entrer dans une supposition sur l’année. Une coupe de deux caractères n’est pas portable d’une compilation à l’autre, et elle change en silence la validité que la base de données annonce aux futurs contrôles de sujet en double et de CRL. Quand la valeur d’origine est irrécupérable, réémettez sous un nouveau numéro de série et notez pourquoi l’ancien a été abandonné. La piste d’audit fait partie de la réparation, ce n’est pas de la paperasse autour d’elle.

Vérifiez l’émission et la génération de CRL avant de partir

Lancez une émission avec la même configuration et confirmez qu’elle se termine sans reproche sur un numéro de ligne. Générez ensuite une CRL avec openssl ca -gencrl -config openssl.cnf et vérifiez qu’elle s’analyse, car un enregistrement endommagé ressort souvent là plutôt que pendant la signature.

Inspectez le nouveau certificat avec openssl x509 -noout -dates -serial et comparez-le à la ligne que la CA vient d’écrire. Confirmez que la lettre d’état et la date d’expiration s’accordent avec le certificat, et confirmez que openssl verify -CAfile ca.pem issued.pem revient sans erreur. Rétablissez ensuite l’émission programmée et surveillez la première exécution, car une seconde ligne malformée s’annoncera aussitôt.