openssl ca: data de validade inválida no index.txt e como corrigi-la

Uma execução de emissão para em entry 22: invalid expiry date, e o pedido que tem à frente está perfeitamente correto. A queixa vem do analisador da base de dados da CA, não do CSR e não do cliente VPN que acabará por apresentar o certificado. Essa distinção decide tudo o que vem depois: um registo está malformado, pelo que a reparação pertence ao estado da CA e não ao pedido nem à configuração do par. Trate a entrada numerada como uma linha em index.txt, e o problema reduz-se a uma pergunta de dados delimitada com uma resposta verificável.

Leia o erro como uma queixa sobre a base de dados

Cada openssl ca invocação percorre a sua base de dados textual antes de assinar seja o que for. Cada linha contém uma letra de estado, um carimbo temporal de validade, um carimbo de revogação opcional, um número de série em hexadecimal, um nome de ficheiro e o sujeito. Quando um campo não pode ser analisado, o comando indica o número da linha e para em vez de adivinhar o resto do registo.

Essa paragem é protectora e não pedante. Um registo que a ferramenta não consegue ler deixa-a incapaz de decidir se o sujeito pedido já existe, se um número de série já foi atribuído ou o que a próxima CRL deve conter. Continuar para lá de uma linha defeituosa produziria exactamente essa inconsistência silenciosa que surge meses depois, normalmente durante uma revogação que ninguém consegue explicar. Leia a mensagem como uma queixa sobre os dados, e a investigação fica dentro do diretório da CA.

Copie o estado da CA antes de tocar em nada

Tire uma imagem de todo o diretório da CA, não apenas do ficheiro da base de dados. O índice, o seu ficheiro de atributos, os ficheiros do número de série e do número de CRL, a chave privada e os certificados emitidos participam todos em operações posteriores, e uma reparação que restaura um e esquece os outros cria um segundo incidente. Utilize a rotina de cópia de segurança própria da CA quando exista, e suspenda a emissão programada durante o trabalho.

Registe a compilação do OpenSSL e o ficheiro de configuração que o comando falhado carregou realmente. As instalações guardam muitas vezes mais de um diretório de CA, e o erro só tem significado face à base de dados que a configuração escolhida nomeia.

Encontre a entrada e descodifique o campo de data

O número de linha indicado conta a partir do primeiro registo, pelo que sed -n '22p' index.txt cai sobre a entrada problemática depois de confirmar que não há linhas vazias nem comentários por cima. Imprima essa linha com delimitadores visíveis, porque as tabulações e os espaços finais são comuns e invisíveis numa janela de editor vulgar.

O campo de validade é um carimbo temporal cuja largura depende do ano. Os valores até 2049 são escritos em UTCTime como YYMMDDHHMMSSZ, enquanto os valores posteriores passam para GeneralizedTime com um ano de quatro dígitos. Um registo que mistura as duas formas, ou que traz um ano de dois dígitos onde o analisador agora espera quatro, falha exactamente neste ponto. O mesmo acontece com um campo truncado deixado por uma escrita interrompida.

Compare o registo com o certificado a que se refere e não com o ficheiro de outra CA. O certificado assinado é a autoridade sobre o que a validade deve dizer, e já existe como objecto analisável.

Repare o registo segundo o certificado assinado

Leia as datas reais com openssl x509 -in issued.pem -noout -dates -serial -subject. Converta notAfter para a largura de carimbo que a sua compilação escreve para esse ano, e confirme que o número de série corresponde à entrada que vai editar antes de mudar um único caractere.

Edite apenas o campo avariado, mantenha a letra de estado e o número de série, e deixe o resto da linha em paz. Se o registo não puder ser reconciliado com nenhum certificado assinado, trate-o como uma entrada extraviada e retire-o pelo caminho de revogação próprio da CA em vez de apagar a linha à mão.

Não repare cortando uma data para caber numa suposição sobre o ano. Um corte de dois caracteres não é portável entre compilações e altera em silêncio a validade que a base de dados comunica às futuras verificações de sujeito duplicado e de CRL. Quando o valor original é irrecuperável, volte a emitir com um novo número de série e anote porque o antigo foi abandonado. O rasto de auditoria faz parte da reparação, não é papelada à volta dela.

Verifique a emissão e a geração de CRL antes de sair

Execute uma emissão com a mesma configuração e confirme que termina sem queixa de número de linha. Depois gere uma CRL com openssl ca -gencrl -config openssl.cnf e verifique que é analisável, porque um registo danificado surge muitas vezes aí e não durante a assinatura.

Inspeccione o novo certificado com openssl x509 -noout -dates -serial e compare-o com a linha que a CA acabou de escrever. Confirme que a letra de estado e a data de validade concordam com o certificado, e confirme que openssl verify -CAfile ca.pem issued.pem regressa sem erro. Depois restabeleça a emissão programada e vigie a primeira execução, porque uma segunda linha malformada anunciar-se-á de imediato.