openssl ca: data de caducidade non válida en index.txt e como arranxala

Unha execución de emisión detense con entry 22: invalid expiry date, e a solicitude que ten diante é perfectamente correcta. A queixa vén do analizador da base de datos da CA, non da CSR nin do cliente VPN que finalmente presentará o certificado. Esa distinción decide todo o que vén despois: un rexistro está mal formado, así que a reparación pertence ao estado da CA e non á solicitude nin á configuración do par. Trate a entrada numerada como unha liña de index.txt, e o problema redúcese a unha pregunta de datos acoutada cunha resposta comprobable.

Lea o erro como unha queixa da base de datos

Cada openssl ca invocación percorre a súa base de datos de texto antes de asinar nada. Cada liña contén unha letra de estado, un selo temporal de caducidade, un selo de revocación opcional, un número de serie en hexadecimal, un nome de ficheiro e o suxeito. Cando un campo non se pode analizar, a orde informa do número de liña e detense en lugar de adiviñar o resto do rexistro.

Esa parada é protectora e non pedante. Un rexistro que a ferramenta non pode ler déixaa incapaz de decidir se o suxeito solicitado xa existe, se se entregou un número de serie ou que debería conter a próxima CRL. Continuar máis alá dunha liña defectuosa produciría exactamente esa inconsistencia silenciosa que aflora meses despois, normalmente durante unha revocación que ninguén sabe explicar. Lea a mensaxe como unha queixa sobre os datos e a investigación quedará dentro do directorio da CA.

Copie o estado da CA antes de tocar nada

Faga unha instantánea de todo o directorio da CA, non só do ficheiro da base de datos. O índice, o seu ficheiro de atributos, os ficheiros do número de serie e do número de CRL, a chave privada e os certificados emitidos participan todos en operacións posteriores, e unha reparación que restaura un e esquece os demais crea un segundo incidente. Use a rutina de copia de seguridade propia da CA cando exista, e pouse a emisión programada mentres dure o traballo.

Anote a compilación de OpenSSL e o ficheiro de configuración que a orde fallida cargou realmente. As instalacións adoitan gardar máis dun directorio de CA, e o erro só significa algo fronte á base de datos que nomea a configuración seleccionada.

Atope a entrada e descodifique o seu campo de data

O número de liña indicado cóntase desde o primeiro rexistro, así que sed -n '22p' index.txt cae sobre a entrada conflictiva unha vez confirmado que non hai liñas en branco nin comentarios por enriba. Imprima esa liña con delimitadores visibles, porque os tabuladores e os espazos finais son frecuentes e invisibles nunha xanela de editor corrente.

O campo de caducidade é un selo temporal cuxa largura depende do ano. Os valores ata 2049 escríbense en UTCTime como YYMMDDHHMMSSZ, mentres que os valores posteriores pasan a GeneralizedTime cun ano de catro díxitos. Un rexistro que mestura as dúas formas, ou que leva un ano de dous díxitos onde o analizador agora espera catro, falla exactamente neste punto. Tamén o fai un campo truncado que deixase unha escritura interrompida.

Compare o rexistro co certificado ao que se refire e non co ficheiro doutra CA. O certificado asinado é a autoridade sobre o que debe dicir a validez, e xa existe como obxecto analizable.

Repare o rexistro contra o certificado asinado

Lea as datas reais con openssl x509 -in issued.pem -noout -dates -serial -subject. Converta notAfter á largura de selo que a súa compilación escribe para ese ano, e confirme que o número de serie coincide coa entrada que está a piques de editar antes de cambiar un só carácter.

Edite só o campo roto, conserve a letra de estado e o número de serie, e deixe o resto da liña en paz. Se o rexistro non se pode reconciliar con ningún certificado asinado, tráteo como unha entrada extraviada e retíreo pola vía de revocación propia da CA en lugar de borrar a liña a man.

Non repare recortando unha data para encaixala cunha conxectura sobre o ano. Un corte de dous caracteres non é portable entre compilacións e cambia en silencio a validez que a base de datos informa ás futuras comprobacións de suxeito duplicado e de CRL. Cando o valor orixinal non se pode recuperar, volva emitir cun número de serie novo e anote por que se abandonou o vello. O rastro de auditoría forma parte da reparación, non son papeis ao seu redor.

Verifique a emisión e a xeración de CRL antes de marchar

Execute unha emisión coa mesma configuración e confirme que remata sen queixa de número de liña. Logo xere unha CRL con openssl ca -gencrl -config openssl.cnf e comprobe que se analiza, porque un rexistro danado adoita aflorar aí e non durante a sinatura.

Inspeccione o certificado novo con openssl x509 -noout -dates -serial e compáreo coa liña que a CA acaba de escribir. Confirme que a letra de estado e a caducidade concordan co certificado, e confirme que openssl verify -CAfile ca.pem issued.pem volve sen erro. Despois restaure a emisión programada e vixíe a primeira execución, porque unha segunda liña mal formada anunciarase de inmediato.