Certificado VPN revogado ainda se conecta? Verifique a aplicação da CRL

Você revogou o certificado, gerou uma lista nova, e o perfil antigo ainda levanta um túnel. Nada está quebrado na revogação em si: uma CRL é uma declaração assinada de que um número de série não é mais válido, e ela só muda o acesso quando o componente que encerra o TLS a carrega, para o emissor correto, antes de tomar a decisão de aceitação. É aí que está a maioria desses casos, e por isso revogação e negação são dois fatos distintos.

Percorra as cinco verificações abaixo em ordem, e pare na primeira que não se sustentar, porque cada verificação posterior pressupõe que as anteriores sejam verdadeiras.

Verifique qual componente toma a decisão de aceitação

Nomeie o processo que valida o certificado do cliente, porque só esse processo pode aplicar uma lista. Em um servidor OpenVPN é o próprio daemon, configurado com crl-verify. No ocserv é a linha crl em ocserv.conf. No strongSwan as entradas são as CRLs carregadas junto com strictcrlpolicy. Um proxy ou equipamento que encerra TLS na frente da VPN também pode ser o verificador real, e se for, o daemon atrás dele nunca vê o certificado do cliente.

O WireGuard pertence a outra categoria. Não tem certificados nem lista de revogação; um par é admitido pela sua chave pública na configuração, então encerrar o acesso significa remover essa chave. Se você procura uma CRL em uma implantação só com WireGuard, esse mecanismo não existe.

Atenção também para a armadilha do lado do cliente. Um cliente que se recusa a conectar porque não gosta do certificado do servidor está aplicando a cadeia do servidor, não revogando a própria credencial. Um certificado de usuário só é revogado onde esse certificado de usuário é validado, e isso é quase sempre o lado do servidor.

Verifique para qual emissor a lista foi assinada

Uma CRL é limitada a uma CA emissora. Com uma raiz e uma intermediária, os certificados folha vêm da intermediária, então a lista que importa é a CRL da intermediária; a lista da raiz não diz nada sobre essas folhas. Um verificador apontado para o arquivo errado a analisa alegremente, não encontra nenhuma entrada correspondente e aceita tudo.

Confirme o emparelhamento antes de tocar no daemon. O emissor do certificado deve coincidir com o subject da lista:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Quando ambos vêm da mesma CA, o número de série impresso para o certificado é o valor que deve aparecer na lista. Se não coincidirem, você está com a CRL errada ou com a cópia errada dela.

A validade pertence à mesma verificação. Um nextUpdate no passado torna a lista obsoleta, e um verificador que falha fechado vai rejeitar todos os clientes em vez de só o revogado.

Verifique se o número de série está na cópia que o daemon carregou

Revogar grava uma entrada no banco de dados da CA, e regenerar grava um arquivo novo. Nenhuma das duas ações chega a um daemon em execução que carregou a cópia antiga na inicialização. Despeje a lista e procure o número de série:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Depois verifique como sua implementação pega o arquivo. O OpenVPN lê um caminho passado para crl-verify uma vez na inicialização, então uma lista nova exige uma reinicialização ou um sinal de reinício; a mesma opção apontada para um diretório é relida a cada conexão, e é por isso que o modo de diretório existe. O strongSwan precisa recarregar suas credenciais, por exemplo com swanctl --load-creds. O arquivo no disco estar correto e o verificador usá-lo são dois fatos diferentes.

Verifique a política para uma lista ausente ou expirada

Esta é a decisão que muitas implantações nunca tomam explicitamente, e ela decide se a revogação protege você ou tranca todos para fora. Fail-closed significa que nenhuma informação de revogação utilizável produz uma rejeição; fail-open significa que o verificador segue sem ela. O strongSwan expõe a escolha como strictcrlpolicy. O OpenVPN com crl-verify se recusa a iniciar com um arquivo que não consegue ler ou analisar, e uma lista expirada aparece como erro de verificação TLS sobre uma CRL expirada em vez de como aceitação silenciosa.

Escolha a direção que escolher, a automação importa mais que a escolha: uma tarefa que regenere a CRL antes de nextUpdate e um alerta quando a cópia implantada envelhecer mantêm qualquer das duas políticas longe de virar incidente. A verificação online com OCSP transfere o frescor para um respondedor, mas a mesma regra se aplica, porque um verificador não configurado para checar a resposta não muda nada.

Verifique a sessão ativa e depois as cópias da chave

A revogação é avaliada durante a validação do certificado, que acontece na conexão e na renegociação. Uma sessão estabelecida continua até renegociar, e o padrão do OpenVPN é uma vez por hora com reneg-sec 3600. Se a pessoa precisa sair da rede agora, encerre a sessão além de publicar a lista, e depois confirme que a reconexão é recusada.

Separe a credencial das suas cópias. Apagar um perfil em um notebook não impede outra cópia da mesma chave privada de autenticar; a revogação é o que torna cada cópia inútil, e só quando as verificações anteriores se sustentam. Dê a um dispositivo substituto o próprio certificado para que um possa ser revogado sem tocar no outro.

Antes de dar por concluído: o componente validador está identificado, o emissor da lista coincide com o emissor da folha, o número de série revogado está na cópia que o daemon realmente carregou, a política para listas ausentes ou expiradas é deliberada e monitorada, e a sessão ativa foi encerrada em vez de esperada. Os formatos por trás de tudo isso estão especificados na RFC 5280.