Conexão recusada não é problema de certificado: um manual de VPN

O cliente diz conexão recusada logo depois de você regenerar a CRL, então a CRL parece culpada. Não é. A recusa é uma resposta da camada de transporte, e a validação do certificado acontece depois, dentro do handshake do túnel. O momento é contexto, não prova.

Duas verificações separam os casos em menos de um minuto, e nenhuma delas toca nas configurações de confiança.

Leia o erro na camada que o produziu

Um ECONNREFUSED de connect significa que a tentativa de transporte foi recusada: algo respondeu com um reset, ou a pilha relatou uma porta inalcançável. Um problema de certificado não pode produzir esse erro, porque o handshake TLS nunca começa sem uma conexão de transporte. Se você vê uma recusa, o cliente nunca chegou longe o suficiente para apresentar um certificado. Esse único fato descarta a revogação como causa.

O contrário também vale. Um certificado revogado produz uma conexão TCP concluída e um handshake falho, registado no servidor como erro de verificação.

Recusa de TCP: ninguém está à escuta

Para TCP, verifique se a instância pretendida está a correr e ligada ao endereço e à porta do perfil. ss -lntp mostra os ouvintes, e a ausência de um é a explicação habitual. Uma firewall que recusa em vez de descartar produz a mesma mensagem do lado do cliente, por isso verifica ambos.

Verifique também a família de endereços. Um serviço ligado a 127.0.0.1 ou apenas a IPv6 recusará um cliente que resolve para a outra.

Depois leia o registo do serviço em vez de adivinhar. Um reinício após a manutenção da CA pode falhar num ficheiro ilegível ou em falta e nunca atingir o estado de escuta, e o registo indica o ficheiro. Isso é uma falha de arranque, um erro diferente de um certificado recusado.

O UDP não tem handshake para recusar

OpenVPN sobre UDP não estabelece uma conexão no sentido de TCP, por isso não há nada a recusar no momento do connect. No Linux, um erro mostrado por um socket UDP pode vir de um ICMP port-unreachable gerado por um datagrama anterior. A página de manual udp(7) descreve esse comportamento assíncrono.

É por isso que um cliente UDP pode imprimir uma recusa enquanto o processo do servidor está a correr mas não está ligado ao endereço esperado.

Onde uma CRL é realmente verificada

A CRL é consultada durante o handshake TLS, depois de o par apresentar o seu certificado, e apenas se a configuração do servidor o permitir. A opção crl-verify do OpenVPN aponta para o ficheiro, e uma falha aparece no registo do servidor como erro de verificação que nomeia o certificado.

Um cliente revogado, portanto, liga-se na camada de transporte e depois falha a autenticação. Mesmo servidor, mesma porta, mensagem completamente diferente.

Verifique o emissor e as datas de validade da CRL quando chegar a essa fase. Uma CRL assinada pela CA errada, ou uma que expirou antes de o cliente se ligar, produz erros de verificação que nada têm a ver com o certificado do próprio cliente.

Um manual curto para a próxima vez

Confirme primeiro o transporte: ouvinte presente, família de endereços correta, firewall que não recusa. Depois confirme que o serviço atingiu o estado de escuta lendo o registo de arranque. E só então olhe para erros de handshake à procura de mensagens de verificação. Mantenha essa ordem fixa, porque cada passo elimina toda uma classe de causas.

Anote o transporte, o destino resolvido, a porta e o texto exato do erro. Reinstalar o cliente destrói essa evidência e normalmente não muda nada.