openssl ca: fecha de caducidad no válida en index.txt y cómo arreglarla

Una ejecución de emisión se detiene con entry 22: invalid expiry date, y la solicitud que tiene delante es perfectamente correcta. La queja viene del analizador de la base de datos de la CA, no de la CSR ni del cliente VPN que finalmente presentará el certificado. Esa distinción decide todo lo que sigue: un registro está mal formado, así que la reparación corresponde al estado de la CA y no a la solicitud ni a la configuración del par. Trate la entrada numerada como una línea de index.txt, y el problema se reduce a una pregunta de datos acotada con una respuesta comprobable.

Lea el error como una queja de la base de datos

Cada openssl ca invocación recorre su base de datos de texto antes de firmar nada. Cada línea contiene una letra de estado, una marca de tiempo de caducidad, una marca de revocación opcional, un número de serie en hexadecimal, un nombre de archivo y el sujeto. Cuando un campo no se puede analizar, la orden informa del número de línea y se detiene en lugar de adivinar el resto del registro.

Esa parada es protectora y no pedante. Un registro que la herramienta no puede leer la deja incapaz de decidir si el sujeto solicitado ya existe, si se ha entregado un número de serie o qué debería contener la próxima CRL. Continuar más allá de una línea defectuosa produciría exactamente esa inconsistencia silenciosa que aflora meses después, normalmente durante una revocación que nadie sabe explicar. Lea el mensaje como una queja sobre los datos y la investigación se quedará dentro del directorio de la CA.

Copie el estado de la CA antes de tocar nada

Tome una instantánea de todo el directorio de la CA, no solo del archivo de la base de datos. El índice, su archivo de atributos, los archivos del número de serie y del número de CRL, la clave privada y los certificados emitidos participan todos en operaciones posteriores, y una reparación que restaura uno y omite los demás crea un segundo incidente. Use la rutina de copia de seguridad propia de la CA cuando exista, y pause la emisión programada mientras dure el trabajo.

Anote la compilación de OpenSSL y el archivo de configuración que la orden fallida cargó realmente. Las instalaciones suelen guardar más de un directorio de CA, y el error solo significa algo frente a la base de datos que nombra la configuración seleccionada.

Encuentre la entrada y descodifique su campo de fecha

El número de línea indicado se cuenta desde el primer registro, así que sed -n '22p' index.txt cae sobre la entrada conflictiva una vez haya confirmado que no hay líneas en blanco ni comentarios por encima. Imprima esa línea con delimitadores visibles, porque los tabuladores y los espacios finales son frecuentes e invisibles en una ventana de editor corriente.

El campo de caducidad es una marca de tiempo cuya anchura depende del año. Los valores hasta 2049 se escriben en UTCTime como YYMMDDHHMMSSZ, mientras que los valores posteriores pasan a GeneralizedTime con un año de cuatro dígitos. Un registro que mezcla las dos formas, o que lleva un año de dos dígitos donde el analizador ahora espera cuatro, falla exactamente en este punto. También lo hace un campo truncado que haya dejado una escritura interrumpida.

Compare el registro con el certificado al que se refiere y no con el archivo de otra CA. El certificado firmado es la autoridad sobre lo que debe decir la validez, y ya existe como objeto analizable.

Repare el registro contra el certificado firmado

Lea las fechas reales con openssl x509 -in issued.pem -noout -dates -serial -subject. Convierta notAfter a la anchura de marca que su compilación escribe para ese año, y confirme que el número de serie coincide con la entrada que está a punto de editar antes de cambiar un solo carácter.

Edite solo el campo roto, conserve la letra de estado y el número de serie, y deje el resto de la línea en paz. Si el registro no se puede reconciliar con ningún certificado firmado, trátelo como una entrada extraviada y retírelo por la vía de revocación propia de la CA en lugar de borrar la línea a mano.

No repare recortando una fecha para que encaje con una conjetura sobre el año. Un corte de dos caracteres no es portable entre compilaciones y cambia en silencio la validez que la base de datos informa a futuras comprobaciones de sujeto duplicado y de CRL. Cuando el valor original no se puede recuperar, vuelva a emitir con un número de serie nuevo y anote por qué se abandonó el viejo. El rastro de auditoría forma parte de la reparación, no es papeleo a su alrededor.

Verifique la emisión y la generación de CRL antes de irse

Ejecute una emisión con la misma configuración y confirme que termina sin queja de número de línea. Luego genere una CRL con openssl ca -gencrl -config openssl.cnf y compruebe que se analiza, porque un registro dañado suele aflorar ahí y no durante la firma.

Inspeccione el certificado nuevo con openssl x509 -noout -dates -serial y compárelo con la línea que la CA acaba de escribir. Confirme que la letra de estado y la caducidad concuerdan con el certificado, y confirme que openssl verify -CAfile ca.pem issued.pem vuelve sin error. Después restaure la emisión programada y vigile la primera ejecución, porque una segunda línea mal formada se anunciará de inmediato.