Por que o OpenVPN diz ca no Windows: um caminho sem aspas, não um certificado ruim

OpenVPN não inicia, e a mensagem de falha aponta uma linha que parece correta: Unrecognized option or missing or extra parameter(s) in office.ovpn:42: ca. O certificado não mudou, o arquivo abre em um editor, e nada no caminho parece errado. O analisador não contesta o nome da opção; contesta quantos argumentos chegaram com ela. Quatro verificações resolvem quase todos os casos, e vale executá-las por ordem de custo.

Por que o analisador culpa a opção

Cada linha de configuração é dividida em espaços e em aspas antes que qualquer opção a veja. Por isso um valor com espaço chega como vários argumentos se não estiver entre aspas, e a opção dona da linha relata a divergência. No Windows o diretório de instalação padrão torna isso certo, porque C:\Program Files fica no meio do caminho por construção. O certificado nunca é aberto nessa falha, então verificar se o arquivo existe não prova nada de útil.

O número da linha informado costuma estar certo, e a opção informada é a que consumiu a linha. Quando a opção nomeada é uma que você sabe que nunca escreveu, leia a linha acima, porque uma aspa perdida em um bloco anterior desloca a análise. É assim que um bloco de certificado acaba sendo culpado pela contagem de argumentos.

ca C:\Program Files\OpenVPN\config\office-ca.crt

Coloque aspas em todo caminho que contenha um espaço

Um par de aspas duplas em volta do valor é todo o reparo, e as barras inclinadas são aceitas no Windows, então o escape nunca passa a fazer parte do problema. Corrija todas as opções de caminho na mesma passada, porque o analisador para na primeira falha e a seguinte apenas espera o próximo reinício. O conjunto normalmente inclui ca, cert, key, tls-auth e auth-user-pass.

ca "C:/Program Files/OpenVPN/config/office-ca.crt"
cert "C:/Program Files/OpenVPN/config/office.crt"
key "C:/Program Files/OpenVPN/config/office.key"

Uma busca pelo nome do diretório encontra cada ocorrência mais rápido do que ler o arquivo. Execute-a antes de qualquer edição, para que a lista fique completa:

Select-String -Path .\office.ovpn -Pattern 'Program Files'

Mover o perfil para um caminho sem espaços é uma alternativa válida, e só é válida se todo caminho se mover junto. Um perfil migrado pela metade reproduz o mesmo erro com outro nome de arquivo, o que é mais difícil de perceber porque a mensagem agora aponta para um caminho que você acabou de criar. Escolha uma abordagem e conclua-a.

Recupere a declaração de modo antes dos certificados

A segunda causa comum produz outra mensagem com a mesma tarde perdida. Um perfil de cliente precisa declarar o modo perto do início, e essa declaração se perde facilmente quando só os blocos de certificado são colados em um arquivo novo. Sem ela, o OpenVPN lê o arquivo com outro conjunto de padrões, e o dano aparece muito depois como conflito entre opções ou falha de login. A linha ausente é barata de verificar e cara de esquecer.

client
dev tun
proto udp
remote vpn.example.net 1194

Mantenha uma diretiva por linha enquanto estiver aí. Linhas juntadas produzem exatamente o erro de contagem de argumentos da primeira seção, e a linha informada parece razoável porque a junção ocorreu onde o editor quebrou o texto. Leia a linha crua, não a exibida.

O dano de codificação parece um nome de opção

Um arquivo salvo como UTF-16, com marca de ordem de bytes, esconde sua primeira opção do analisador, e bytes perdidos podem colar-se ao nome da opção na mensagem. Salve o arquivo como UTF-8 sem marca de ordem de bytes, depois reabra-o e confirme que o primeiro caractere é uma letra normal. Editores, o redirecionamento do PowerShell e o texto colado de uma janela de chat mudam a codificação sem perguntar.

Format-Hex .\office.ovpn | Select-Object -First 1

A marca de ordem de bytes aparece como bytes marcadores iniciais antes de qualquer texto, e apagar esses caracteres à mão é uma jogada perdedora porque o editor os regrava no próximo salvamento. Salve o arquivo de novo com uma codificação explícita. As terminações de linha são mais tolerantes, mas um arquivo sem nova linha no fim ainda pode fundir a última diretiva na anterior depois de uma edição.

Qual verificação primeiro, e por quê

Comece pela codificação, porque custa um comando e invalida qualquer outra leitura do arquivo. Depois as aspas, em seguida a declaração de modo e as demais diretivas obrigatórias, e só depois os certificados, as chaves e as credenciais. Trabalhar nessa ordem mantém cada passo reversível, porque um certificado trocado para corrigir um problema de aspas deixa uma instalação funcionando com uma falha nova a duas edições do original. A ordem importa mais do que as verificações individuais.

Guarde uma cópia intacta do arquivo como o operador a entregou. Se uma edição posterior a quebrar, uma diferença em relação a essa cópia mostra se uma aspa, uma nova linha ou um byte de marca se moveu, o que é mais rápido do que reler o erro. A referência de opções de cada diretiva está no manual do OpenVPN da versão instalada.