Um perfil OpenVPN tem três blocos de certificado: qual é secreto?

Abre um ficheiro .ovpn para mudar uma linha e encontra três blocos de base64 que parecem todos credenciais. Um é seguro de publicar, outro é tão sensível como uma palavra-passe, e outro é uma chave pública que nada significa se outra coisa não tiver sido assinada com o seu par. As pessoas colam o ficheiro inteiro num tópico de apoio porque os blocos parecem intercambiáveis, e é assim que uma chave de cliente acaba num arquivo público. Distinguir o que faz cada bloco explica a maior parte da confusão em torno destes perfis, e também diz que falhas são suas para corrigir.

Um ficheiro, três blocos, tarefas diferentes

Um perfil típico incorpora um bloco ca, um bloco cert e um bloco key entre os marcadores BEGIN e END, ou aponta para os mesmos três como ficheiros separados. Alguns perfis acrescentam um quarto bloco para uma chave tls-auth ou tls-crypt, que é um segredo partilhado e não um certificado. O cliente lê cada bloco segundo a diretiva que o nomeia, por isso as etiquetas importam mais do que a ordem em que aparecem.

Trate o perfil montado como sensível até ter realmente olhado para dentro. Um certificado público e uma chave privada podem estar a poucas linhas um do outro no mesmo ficheiro, e uma captura de ecrã que inclua o cabeçalho pode incluir ambos. Tapar o base64 visível à mão também não é fiável, porque um bloco parcial ainda revela os metadados do certificado que nomeiam a sua implementação. Copiar as três diretivas sem os seus valores costuma bastar para fazer uma pergunta útil.

As diretivas à volta dos blocos decidem como são usados. Mude ca e o cliente confia noutra autoridade; mude cert sem mudar key e o aperto de mão falha com uma divergência que nada tem a ver com confiança.

O bloco de CA é público, a chave de CA nunca

Uma autoridade de certificação assina certificados que ligam uma chave pública a uma identidade, e o seu próprio certificado é a âncora que um cliente usa para decidir se uma cadeia é fidedigna. Esse certificado é público por conceção: enviá-lo dentro de cada perfil é normal, e é por isso que uma implementação autoassinada pode funcionar sem uma autoridade comercial.

O que nunca deve aparecer num perfil de cliente é a chave privada de assinatura da autoridade. O cliente não precisa dela para validar nada, e a sua presença significa que quem tiver o perfil pode criar novas identidades para toda a implementação.

Confiar numa autoridade também é mais estreito do que parece. Um cliente que aceita qualquer certificado assinado pela CA continuará a aceitar um certificado emitido para outro serviço na mesma CA. As opções que fixam o papel ou o nome esperado do servidor fecham essa lacuna, e a Referência de opções TLS lista as diretivas de verificação que o fazem.

Os certificados de servidor e de cliente apontam em direções opostas

O certificado do servidor é o que o cliente inspeciona para confirmar que chegou ao ponto final correto. O seu certificado de cliente vai no sentido inverso: o servidor usa-o para decidir que este dispositivo ou utilizador é um que ele inscreveu. Mesmo formato, direção de confiança oposta.

Um endereço não é uma identidade. Chegar ao IP correto não prova nada sobre quem respondeu, e por isso a verificação do nome de anfitrião ou do nome do certificado continua a pertencer ao perfil. Uma palavra-passe de conta também não substitui em silêncio um certificado de cliente exigido, porque os dois são verificados em fases diferentes e uma implementação pode exigir ambos.

A chave privada do cliente é a parte que deve permanecer privada. Se pode ter sido exposta, apagar o ficheiro do seu portátil não muda nada no servidor, que continuará a aceitar o certificado correspondente até o operador o revogar. Pedir ao operador que substitua ou revogue essa identidade é a única correção que viaja consigo.

Dois pedidos que parecem idênticos e não são

Uma chave guardada de forma cifrada pede uma frase-passe antes de o cliente a poder usar. O serviço de VPN pode pedir separadamente uma palavra-passe de conta, e os dois pedidos podem aparecer com segundos de diferença e quase o mesmo texto. A frase-passe protege um ficheiro no seu disco; a palavra-passe prova uma conta a um servidor. Confundi-las envia as pessoas para reposições que não podem ajudar de forma alguma.

Leia o pedido antes de repor o que quer que seja. Uma reposição da palavra-passe de conta não faz nada por uma frase-passe de chave esquecida, um certificado revogado ou um expirado, e repor a palavra-passe quando a falha é a validação do certificado transforma uma correção de dois minutos num caso de apoio. Se a queixa mencionar datas de validade, verifique primeiro o relógio do dispositivo e depois a janela própria do certificado indicado.

Quando o certificado expirou mesmo, a substituição tem de vir de quem o emitiu. Uma chave que pertence a outra pessoa não é um caminho de renovação, e pedir emprestado um perfil que funciona a um colega também não.

O que um aperto de mão limpo prova e o que não prova

Chegar a um aperto de mão TLS concluído significa que a relação de identidade configurada se manteve: o certificado do servidor encadeou na sua CA e o seu certificado foi aceite. Não diz nada sobre a política de registo do operador, nem se as suas aplicações funcionarão depois de o túnel estar levantado.

As rotas e o DNS são fases posteriores da ligação, por isso um anfitrião de intranet inalcançável após um início de sessão bem-sucedido é um problema de conetividade e não de certificado. Trabalhe essa camada em vez de trocar credenciais, e mantenha juntos a origem do perfil, o seu material privado e as suas verificações de identidade quando o entrega a alguém.