Pedido de chave do OpenVPN após o OpenSSL 3: verifique o provedor

Ninguém tocou no perfil, e no entanto o mesmo cliente passou a pedir uma frase-passe para a chave privada em cada arranque. Quando essa mudança surge poucos dias depois de uma atualização da distribuição, a atualização é a causa provável: o OpenSSL 3 reorganizou o suporte de algoritmos, e uma chave que a biblioteca antiga lia sem problemas pode tornar-se ilegível sem que um único byte mude. Faça as verificações por ordem, porque duas delas parecem idênticas se olhar apenas para o pedido.

A primeira pergunta é se a chave está cifrada, e a segunda é se esta compilação consegue decifrá-la. As alterações de configuração só fazem sentido depois de ambas as respostas serem conhecidas.

Verifique se a chave está cifrada

Leia a primeira linha do ficheiro e depois deixe a biblioteca analisá-la, porque um nome de ficheiro não prova nada. Um bloco PEM com o rótulo ENCRYPTED PRIVATE KEY é PKCS#8 cifrado, e um bloco RSA PRIVATE KEY mais antigo que leva Proc-Type: 4,ENCRYPTED é a forma tradicional, e ambos esperam uma frase-passe. Um bloco PRIVATE KEY não cifrado não deveria pedir nenhuma. Execute a análise com a conta que possui o ficheiro, porque um problema de permissões produz um erro diferente e muito menos interessante.

Se a chave não estiver mesmo cifrada e o cliente continuar a perguntar, deixe de olhar para a criptografia e verifique se o perfil indica um ficheiro askpass que o serviço ainda consegue ler.

Verifique se esta compilação consegue decifrá-la

O OpenSSL 3 dividiu o suporte de algoritmos em provedores, e um conjunto de cifras antigas passou a residir no provedor legacy em vez do predefinido. Uma chave cifrada com uma dessas cifras continua válida, mas uma biblioteca carregada sem o provedor legacy não a consegue descodificar. Em alguns clientes isso manifesta-se como um pedido que se repete, noutros como uma falha dura logo após a frase-passe.

Analise a mesma chave duas vezes com o mesmo binário: primeiro só com o provedor predefinido, depois com legacy e predefinido ambos pedidos na linha de comandos. Se a segunda tentativa tiver êxito onde a primeira falhou, o diagnóstico assenta em provas e não no momento da atualização. Se ambas falharem de forma idêntica, a frase-passe está errada ou o ficheiro está danificado, e nenhuma definição de provedor repara qualquer dos casos.

Verifique a correção mais estreita disponível

Prefira uma alteração limitada ao cliente a uma de âmbito sistémico. Algumas compilações 2.6 aceitam uma opção de perfil que carrega ambos os provedores para o processo desse daemon, por isso confirme a diretiva no manual para a sua versão exata antes de confiar nela; editar o openssl.cnf do sistema em vez disso afeta todos os programas OpenSSL do anfitrião. A definição mais estreita também é muito mais fácil de reverter depois de a chave ser recodificada.

Não elimine a frase-passe para fazer desaparecer o pedido. Isso converte uma credencial protegida num ficheiro de texto simples e altera em silêncio o risco de cada cópia de segurança, cópia e pacote de suporte em que apareça. A distinção que importa é entre uma chave que precisa da sua frase-passe e uma chave que esta biblioteca não consegue descodificar.

Verifique o contexto do serviço e recodifique em seguida

Assim que a chave puder ser desbloqueada, cifre-a de novo com um algoritmo atual para que a dependência desapareça. Escreva o novo ficheiro com uma cifra moderna, verifique que é analisado, atualize o perfil e mantenha a cópia antiga apenas até uma ligação ter êxito. Nunca coloque a frase-passe numa linha de comandos, onde qualquer utilizador local a pode ler na lista de processos. Remova o ficheiro antigo só depois de o novo se ter ligado a partir da conta de serviço, não apenas a partir da sua shell.

Depois verifique a unidade que realmente executa o cliente. Uma chave legível na sua shell pode ser ilegível para um serviço executado com outra conta ou com uma definição endurecida do diretório pessoal.

Registe a definição do provedor junto ao perfil e guarde o teste de dois comandos com ela. Quando uma atualização posterior remover o provedor legacy, execute novamente esse teste para ver se a chave ainda precisa dele ou se o perfil pode sair da solução alternativa.

Um pedido é um sintoma com pelo menos três causas, e só uma delas é uma frase-passe em falta.