Autoassinado ou CA pública para uma VPN: o que realmente muda

Você chega à página de certificados de uma configuração de VPN, vê uma opção autoassinada gratuita ao lado de uma CA pública paga, e a pergunta soa como uma escolha de segurança. Na verdade é uma escolha de público. As duas opções cifram o túnel com as mesmas primitivas, e ambas se tornam inúteis se a chave privada vazar. O que as separa é quem faz a afirmação sobre a identidade do servidor e quem está em posição de verificar essa afirmação.

Um certificado faz dois trabalhos que se confundem

Um certificado liga uma chave pública a um nome, e a chave faz o trabalho de cifragem e assinatura. A assinatura no certificado é uma declaração separada: alguma autoridade verificou que o nome pertence a este titular da chave. Um certificado autoassinado faz essa declaração sobre si mesmo, o que não é de modo algum uma afirmação de terceiros.

Sites públicos precisam da versão de terceiros, porque os visitantes chegam sem nenhuma relação prévia e dependem do armazenamento de confiança do navegador. Um cliente VPN não é um estranho. Você entrega a ele o certificado da CA, ou fixa o certificado do servidor, dentro do perfil que ele instala, de modo que a verificação corre contra exatamente a autoridade que você escolheu. Nenhuma CA comercial precisa estar envolvida para que essa verificação signifique algo.

A força da sessão resultante vem do tamanho da chave e do conjunto de cifras, não do signatário. Por isso chamar um certificado autoassinado de "menos cifrado" é simplesmente errado; ele é menos amplamente garantido, o que é uma propriedade diferente.

Onde uma CA pública ganha a sua taxa

O caso mais claro é a página de administração. Se colegas, fornecedores ou qualquer outra pessoa sem um perfil preparado precisam abrir a interface web do servidor VPN sem um aviso do navegador, um certificado de confiança pública elimina esse atrito. O navegador já confia no signatário, então não há nada para importar e nada para explicar.

Essa conveniência tem custos que vale a pena nomear antes de comprar. A renovação precisa ser automatizada ou o site quebra conforme um calendário, certificados públicos expõem o nome do host nos registos de transparência de certificados, e limites de taxa de emissão punem um script que tenta novamente com demasiado entusiasmo. Nada disso é motivo para evitar uma CA pública, mas é trabalho operacional que uma CA privada transfere para outro lugar.

O que um certificado público não faz é autenticar os seus utilizadores. A identidade do cliente é uma decisão separada, tomada com certificados de cliente, palavras-passe ou um segundo fator, e a CA que assina o servidor não diz nada sobre quem pode ligar-se a ele.

Onde uma CA privada encaixa numa VPN

Para uma VPN privada com um conjunto conhecido de clientes, executar a sua própria CA é a opção convencional. Cria a CA uma vez, assina o certificado do servidor com um nome que os clientes usarão e distribui o certificado da CA dentro de cada perfil. Cada cliente verifica então o servidor contra a sua autoridade, e nenhuma parte externa fica a conhecer o nome do host.

Os custos são reais mas limitados. Os navegadores avisarão quando alguém abrir a página de administração diretamente, porque o navegador não tem motivo para confiar na sua CA. A distribuição de perfis passa a fazer parte do onboarding, e rodar a CA significa tocar em cada cliente. São preços aceitáveis para um serviço com dez ou cinquenta utilizadores conhecidos e dolorosos para um endpoint público com milhares.

Uma condição torna todo o arranjo válido: a verificação tem de acontecer. Um cliente configurado para ignorar erros de certificado aceita qualquer servidor que apresente qualquer certificado, pelo que a garantia de identidade desaparece enquanto a cifragem permanece. Essa definição é a verdadeira fraqueza na maioria das histórias de "autoassinado é inseguro".

A chave privada da CA decide o que poderá fazer mais tarde

A surpresa costuma chegar meses depois, quando quer adicionar um dispositivo. Emitir um certificado de cliente requer a chave privada da CA, e produzir uma lista de revogação também. Se herdou um servidor que tem os ficheiros de certificado e chave mas não a chave da CA, não pode assinar nada novo. As suas opções são reconstruir a PKI e entregar a cada cliente um novo certificado de CA, ou mudar para autenticação por palavra-passe, que é um modelo de segurança diferente e não restaura o que se perdeu.

Duas armadilhas menores vivem no mesmo território. Os scripts easy-rsa assumem que está no diretório que os contém, pelo que um erro de ficheiro em falta normalmente significa o local errado e não uma instalação danificada. E um design só com certificados é perfeitamente legítimo: pode exigir certificados de cliente sem uma chave pré-partilhada, desde que cada cliente tenha um e o servidor verifique a cadeia.

Emita um certificado por dispositivo em vez de um certificado de cliente partilhado para toda a equipa. Um portátil perdido custa-lhe então uma única revogação em vez de uma reemissão para todos.

Verifique o que herdou

Antes de planear qualquer alteração, leia o certificado que já tem:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

Se o emissor for igual ao sujeito, o certificado é autoassinado, o que é uma escolha de design e não um defeito. As datas dizem-lhe quando a renovação se torna o problema de alguém, e uma verificação bem-sucedida contra a CA que pretende implementar confirma que a cadeia funciona antes de um único cliente a experimentar.

Depois escolha por público e distribuição: CA pública quando navegadores desconhecidos têm de confiar na página de administração, CA privada quando cada cliente recebe um perfil que controla. Nenhuma das respostas é mais cifrada do que a outra.