Um certificado VPN próprio não é uma camada extra de criptografia

Instalar um certificado próprio num endpoint VPN parece acrescentar proteção, porque certificados e criptografia aparecem juntos em toda a parte. Na prática muda duas coisas: qual identidade o endpoint apresenta e em que emissor o seu par está disposto a confiar. Nenhuma das duas envolve os seus dados uma segunda vez. Se a necessidade real é um segundo canal protegido, precisa de um segundo canal com os seus próprios endpoints, não de outro certificado.

Três tarefas separadas num handshake TLS 1.3

RFC 8446 mantém estas coisas separadas, e essa separação é toda a resposta. A mensagem Certificate transporta a cadeia de certificados do endpoint. O CertificateVerify prova a posse da chave privada correspondente e liga a transcrição do handshake. A camada de registo protege o tráfego com as chaves de tráfego negociadas.

Troque o certificado e os dois primeiros itens mudam. A proteção de registo não corre duas vezes e não fica mais forte só porque o emissor agora é privado.

O que uma CA privada compra realmente

Compra um sistema de identidade controlado: você decide quem recebe a emissão, você decide que emissores os pares aceitam, e pode revogar segundo o seu próprio calendário. Isso é realmente útil quando gere ambas as pontas.

Mas também importa obrigações. A confiança tem de ser distribuída de forma deliberada, a verificação do par tem de continuar ativa e o ciclo de vida das credenciais tem de ter um responsável. Uma CA privada não é um atalho em torno de nenhuma dessas três.

Quando um segundo canal é a resposta certa

Suponha que uma aplicação abre HTTPS verificado para o seu próprio serviço enquanto os seus pacotes também passam por uma VPN. Esse desenho tem duas fronteiras com endpoints potencialmente diferentes, e é assim que se parece um segundo canal protegido.

A distinção importa no gateway. Se a sessão TLS da aplicação termina no gateway VPN em vez da aplicação, a proteção que julgava ter para lá do túnel não está lá. Escreva quem termina cada canal antes de reivindicar a propriedade.

Pergunte o que a instalação muda

Um pedido para instalar um certificado pode significar três coisas diferentes. Pode mudar a identidade do próprio cliente, uma âncora de confiança específica de uma aplicação, ou a confiança ao nível da plataforma para tudo no dispositivo. Não são equivalentes, e só a última afeta software não relacionado.

Pergunte qual das três se pretende e depois o que deve alcançar. Se a resposta for mais criptografia, a proposta aponta para o mecanismo errado.

Escreva as fronteiras

Para cada canal, registe os endpoints, a identidade que cada lado verifica e o que o operador no meio consegue ver. Depois registe o comportamento em falha: o que acontece quando a verificação falha e o que acontece quando o canal é recusado.

Duas linhas numa página costumam resolver uma discussão que uma rotação de certificados não consegue.

Decida com três perguntas

O problema é quem o endpoint diz ser, ou o que acontece aos dados? A proteção tem de continuar para lá do gateway VPN até uma aplicação específica? E consegue nomear os dois endpoints que terminariam um segundo canal?

Se a primeira pergunta for a verdadeira, corrija a identidade e a confiança. Se for a segunda ou a terceira, desenhe o segundo canal e deixe o certificado onde pertence.