Revogou o certificado VPN errado? Opções de recuperação e limites

Alguém revogou um certificado no console da CA e agora um usuário não consegue conectar. O primeiro instinto é procurar o desfazer, e para a maioria das PKIs ele não existe: a revogação é um fato declarado sobre um número de série, e o caminho de volta suportado é um certificado novo, não um registro invertido. Percorra as verificações abaixo em ordem, porque qual reparo é permitido depende do código de motivo e de a chave ter sido exposta alguma vez.

Identifique o certificado, não a pessoa

Nomes comuns se repetem. Um usuário que se inscreveu de novo no trimestre passado pode ter dois certificados com o mesmo CN e números de série diferentes, e revogar um deixa o outro funcionando. Estabeleça primeiro o objeto exato:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

Anote o número de série, o emissor, a data de revogação e o motivo registrado na CRL. Depois confirme quais dispositivos apresentam esse número de série, porque um certificado revogado ainda pode estar instalado num portátil, num telefone e num router de reserva, e uma substituição que só chega a um deles produz um segundo incidente.

Uma verificação rápida de comportamento confirma o estado sem mudar nada:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

Se ela reporta o certificado como revogado, a CRL e o cliente concordam; se verifica limpo, o cliente que você tem não é o revogado, e a busca continua.

Verifique se a CA usou suspensão ou revogação permanente

A RFC 5280 define certificateHold como um estado temporário e removeFromCRL como o sinal que o liberta. Esse ciclo de vida é real, mas não é um botão de desfazer geral. Ler o código de motivo diz se o emissor alguma vez pretendeu suportar a libertação.

A armadilha é presumir que uma intenção temporária implica um registro temporário. Se a entrada da CA trouxer keyCompromise ou cessationOfOperation, o certificado está revogado permanentemente, faça o que fizer a pessoa que clicou no botão. Por outro lado, uma entrada marcada certificateHold numa CA que não implementa a libertação de suspensão é permanente na prática, porque nada publicará jamais a libertação.

As CA baseadas em OpenSSL ilustram o limite. O comando ca aceita valores de -crl_reason, incluindo certificateHold e removeFromCRL, mas não gera CRL delta — a documentação do OpenSSL CA indica essa limitação para a sua saída de CRL. Uma CRL completa que simplesmente omite o número de série é um modelo de publicação diferente de uma delta que diz "esta entrada foi libertada", portanto colar removeFromCRL numa CA VPN baseada em OpenSSL não produz a libertação definida pelas normas.

Se a chave pode ter sido exposta, substitua-a

Um certificado revogado é a declaração de que esta chave pode já não ser de confiança. Se a revogação estava correta em substância — portátil perdido, chave copiada para um disco partilhado, chave privada colada num ticket — restaurar o mesmo certificado inverte uma decisão de segurança que funcionava como previsto.

Emita um novo par de chaves através do processo de inscrição, distribua o novo perfil e deixe o número de série antigo revogado durante toda a sua vida. Atualize tudo o que fixa a identidade por número de série ou impressão digital, incluindo listas de admissão, inventários de dispositivos e monitorização que espera um certificado específico.

O argumento da conveniência para restaurar o antigo é real, mas deve ser respondido explicitamente e não em silêncio. "O utilizador precisa de acesso hoje" é uma razão para acelerar a emissão, não para desfazer a revogação de uma chave da qual não pode dar contas.

Se foi um erro administrativo, substitua sob controlo

Quando a revogação era simplesmente errada e a chave nunca foi exposta, a reparação continua a ser uma substituição controlada e não uma edição. Use o processo suportado do emissor, mantenha o número de série e o historial de emissão intactos, e evite os dois atalhos tentadores: inverter o caráter de estado em index.txt de R para V, e apagar a linha de emissão para que um novo certificado possa reutilizar o número de série.

Numa CA OpenSSL a base de dados está separada por tabulações e é fácil de ler mal, o que torna a edição manual tentadora:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

Leia-a, não a escreva. Editar o ficheiro altera a CRL seguinte sem qualquer rasto de auditoria, e qualquer segunda instância de CA ou cópia de segurança que ainda detenha a linha original discordará dela mais tarde.

Depois de emitir a substituição, publique uma CRL nova através do mecanismo habitual e deixe os clientes recolhê-la. Remover uma CRL, encurtar a sua vida até nada ou desativar a verificação de revogação no perfil do cliente corrige um utilizador enfraquecendo todas as outras revogações que a CA alguma vez publicou.

Confirme uma admissão nova e conserve o registo

Teste com uma ligação nova, não com a sessão que já estava aberta. Um túnel vivo pode não voltar a executar as verificações de admissão que um handshake novo realiza, e as caches de CRL fazem com que um cliente possa continuar a ligar-se até se atualizar. Desligue, volte a ligar e confirme no registo do servidor qual número de série foi admitido.

Registe o que aconteceu enquanto ainda está fresco: qual número de série foi revogado, por quem, com que motivo, que substituição foi emitida e quando a CRL foi republicada. Esse registo é o que torna possível a revisão de revogação seguinte, e é também a prova de que o erro foi tratado em vez de escondido.

Para suspensões curtas no futuro, use um mecanismo de pausa de admissão se a implementação tiver um — uma conta desativada na camada de identidade, uma pertença a grupo removida, um perfil de cliente retido. Isso mantém uma decisão de política temporária separada da questão de saber se um certificado emitido ainda é fiável, e é exatamente a distinção que se perdeu da primeira vez.