Certificado OpenVPN expirado? Verifique o relógio primeiro, depois o certificado
Um relógio errado pode fazer um certificado válido parecer expirado. Leia o erro TLS exato, encontre o certificado que falha e renove-o através do emissor.
O cliente conecta-se, negocia durante um segundo e depois relata que um certificado expirou. Antes de pedir a alguém para reemitir qualquer coisa, olhe para a data no dispositivo à sua frente: um portátil que dormiu um mês, um telefone com relógio manual e um router sem uma fonte NTP funcional todos reportam o momento errado a uma pilha TLS. Um certificado só é válido dentro de uma janela, e a verificação compara essa janela com o que o relógio local afirma. Acerte o relógio e depois decida se o problema é real.
Comece pelo relógio do dispositivo
Abra um terminal e leia a ideia que o sistema tem do UTC, não o widget do relógio do ambiente de trabalho, que pode mostrar uma vista ajustada ao fuso horário ou um valor obsoleto em cache pela interface gráfica.
date -u
timedatectl statusUm relógio muito adiantado faz um certificado válido parecer expirado, e um muito atrasado fá-lo parecer ainda não válido, o que alguns clientes reportam com a mesma falha genérica de handshake. Se a sincronização estiver desativada ou a fonte de tempo inacessível, corrija isso primeiro e volte a testar antes de tocar em qualquer ficheiro. Recuar o relógio para contornar uma expiração não é solução: quebra outros serviços no dispositivo e deixa o problema de identidade exatamente onde estava.
Se o relógio estiver correto, a expiração é real e o resto deste guia aplica-se. Repare em que fuso horário o registo do cliente usa antes de comparar marcas temporais de dois dispositivos. Um servidor noutro fuso pode fazer uma renovação parecer precoce ou tardia quando não era nenhuma das duas. Compare com a marca temporal na linha de registo do próprio cliente em vez do relógio de parede da sua secretária.
Leia a linha de erro antes do perfil
Guarde o texto exato. A falha de verificação do OpenVPN indica uma profundidade e um motivo, e esses dois campos dizem-lhe quem tem de agir.
Um VERIFY ERROR com error=certificate has expired é uma falha de validade num ponto específico da cadeia. Não é uma rejeição de palavra-passe nem um tempo limite, e os três exigem respostas diferentes.
Copie a linha inteira para as suas notas juntamente com a versão do cliente. Se a mensagem disser em vez disso que o certificado ainda não é válido, volta à questão do relógio. Se disser que o emissor é desconhecido, tem um problema de confiança e não de duração, e nenhuma renovação o mudará.
Descubra qual certificado expirou
A profundidade zero é o certificado apresentado pelo par a que se ligou, e profundidades maiores caminham para a raiz. Uma VPN de trabalho costuma deixar expirar uma identidade de cliente ou um certificado de servidor, e por vezes um intermédio que a organização esqueceu que possuía.
Imprima as datas dos ficheiros a que o perfil faz realmente referência, começando pelo da profundidade indicada no erro.
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl x509 -in ca.crt -noout -subject -datesSe o perfil incorpora os certificados como blocos incorporados em vez de apontar para ficheiros, os ficheiros separados no disco podem ser mais antigos ou mais recentes do que o que o cliente usa, e é por isso que associar o erro a um ficheiro exige ler o perfil e não a listagem do diretório.
Renove através do emissor
Um certificado de cliente é substituído por quem o emitiu, e repor a palavra-passe da conta não renova nada. Para uma ligação de trabalho, use o canal de renovação que a sua organização publica; para um serviço alojado, inicie sessão no portal do fornecedor através de um endereço verificado em vez de abrir um anexo que afirma conter um novo perfil. Um pacote não solicitado não é fiável só porque o nome do ficheiro menciona VPN.
Se gere o servidor, verifique os detalhes públicos e os registos de emissão antes de substituir material, porque uma alteração de CA afeta todos os clientes que confiam nela.
Renovar uma identidade não deve exigir substituir a hierarquia de confiança. Se alguém propuser uma nova CA para corrigir uma única folha expirada, pergunte primeiro o que mais depende da antiga. As RFC 5280 regras de validade e de caminho são o modelo que ambos os lados seguem.
Faça com que o cliente use a substituição
Descarregar um ficheiro não é importá-lo. Verifique a entrada de ligação que realmente seleciona e se o perfil referencia caminhos de certificados externos que esqueceu de substituir.
Mantenha a entrada antiga visível até a nova ligar e depois remova-a para que ninguém escolha o perfil expirado por hábito. Volte a ligar e confirme que o erro de expiração específico desapareceu.
Se restar outro erro TLS, trate-o como um problema novo em vez de enfraquecer as definições de verificação para o ultrapassar. Uma rejeição de conta ou uma rota em falta após uma renovação bem-sucedida é uma falha separada com uma solução separada.