Novos inícios de sessão VPN falham com certificados válidos: verifique a CRL

Certificados com meses pela frente e inícios de sessão que falham de imediato apontam para dois objetos distintos com dois relógios distintos. O servidor rejeita ligações porque a lista de certificados revogados que consulta passou a sua própria data de expiração, e não porque os certificados dos utilizadores tenham ficado obsoletos. Renovar um certificado de utilizador não faz nada por essa lista.

Separar os dois calendários é todo o diagnóstico, e altera a forma que a correção tem de assumir.

Dois relógios, e apenas um deles é o certificado

Um certificado transporta uma janela de validade. Uma lista de revogação de certificados transporta a sua própria janela, além de um emissor e uma assinatura, e os verificadores recusam confiar numa lista cujo momento da próxima atualização já passou. Quando isso acontece, o cliente apresenta um certificado perfeitamente válido e o servidor ainda assim corta a ligação com uma mensagem sobre a lista. Os utilizadores leem essa mensagem como «o certificado expirou», o que envia o pedido de renovação para o local errado.

Os dois objetos também têm proprietários diferentes: o certificado vem da CA que o emitiu, enquanto a lista é gerada segundo um calendário por quem opera essa CA. Um utilizador não a pode atualizar, e a reemissão de certificados não a pode prolongar.

Leia a lista que o serviço carrega realmente

Comece pela configuração em execução em vez de pelo ficheiro que espera. O caminho de crl-verify pode ser absoluto, relativo ao perfil ou uma cópia incorporada numa imagem, e o verificador lê essa cópia. Inspecione-o no local com openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate e compare as datas com o relógio do servidor.

Depois confirme que o ficheiro é realmente o que está em uso: verifique a assinatura com openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, que comunica um resultado de verificação em vez de imprimir os campos em silêncio. Uma lista assinada por outra CA, ou uma cópia antiga deixada num segundo diretório, falha exatamente como uma expirada.

Regenere a partir da base de dados de revogação, não do zero

A nova lista tem de vir da base de dados de revogação atual da CA, através do processo de assinatura aprovado. Gerar uma lista vazia, ou regenerar a partir de uma cópia de segurança antiga do índice, desfaz silenciosamente a revogação de cada identidade adicionada desde essa cópia. Isso transforma uma falha de início de sessão numa regressão de segurança, e ninguém percebe porque o sintoma desaparece.

Mantenha o passo de geração sob controlo de versões com o resto das ferramentas da CA, para que o intervalo e a chave de assinatura fiquem documentados em vez de memorizados. Uma entrada de runbook que nomeie o comando, o assinante e o alvo de publicação é suficiente. Assim qualquer pessoa de serviço pode regenerar sem adivinhar qual ficheiro de índice é o autoritativo. Guarde o número de série da lista e o momento da próxima atualização junto com o registo de implantação.

Implante onde o verificador olha

Copie a nova lista para o caminho que o serviço lê, defina a propriedade e o modo para que a conta de serviço a possa ler mas os outros não, e recarregue ou reinicie segundo o comportamento documentado. Se o daemon guarda a lista em cache no arranque, substituir o ficheiro sem recarregar não muda nada que o processo em execução vá notar. Confirme o carimbo temporal que o processo comunica após o recarregamento.

Se vários serviços verificam clientes, implante em cada um deles. Atualizar um endpoint e deixar outro com a cópia antiga produz uma falha que só aparece nos utilizadores que aterram no segundo. Mantenha uma lista curta desses endpoints no mesmo runbook. Após a implantação, verifique a data de lista comunicada por cada um em vez de assumir que a cópia chegou.

Torne o próximo prazo visível antes de passar

Um intervalo de publicação mais longo reduz a frequência deste incidente sem criar um processo. Escolha o intervalo segundo a política do operador e depois alerte no campo de próxima atualização da lista implantada com antecedência suficiente para regenerar e implantar. Alerte na cópia implantada, não no anfitrião da CA, porque a cópia implantada é a que falha.

Após a implantação, verifique os dois sentidos: um utilizador autorizado liga-se, e uma identidade revogada conhecida continua a falhar. A segunda verificação é a que apanha uma regeneração incompleta, e requer um único comando contra um perfil de teste que mantém exatamente para este propósito.