Use a sua CA empresarial existente para os pares de OpenVPN

Nada no OpenVPN exige que o certificado venha do Easy-RSA, e uma frota que já tem uma PKI organizacional normalmente não deve construir uma segunda. O trabalho real não é escolher uma ferramenta, mas decidir o que significam as identidades emitidas, que pares o túnel aceita e como a renovação e a revogação chegam ao verificador. Percorra os cinco passos abaixo por ordem, porque um passo posterior não pode reparar uma decisão de função tomada no primeiro.

Emita duas funções em vez de uma identidade partilhada

Cada par precisa do seu próprio certificado e da chave privada correspondente. Peça à equipa de PKI uma identidade de servidor com utilização de servidor e identidades de cliente separadas com utilização de cliente, para que o túnel consiga distingui-las durante o aperto de mão.

Resista aos atalhos que aparecem sob pressão de prazos. Uma chave de servidor web copiada para portáteis apaga a distinção da qual depende a verificação de função, e uma chave de assinatura de CA instalada num ponto final de VPN transforma um anfitrião comprometido numa hierarquia comprometida. Um pacote PKCS12 pode transportar uma chave de ponto final e a sua cadeia, mas nunca concede permissão para reutilizar essa identidade noutra função.

Ligue as entradas de confiança de cada lado

O cliente e o servidor precisam cada um de uma âncora de confiança, da sua própria identidade e de uma expectativa de função explícita. Um fragmento de cliente que declare as três coisas parece-se com isto.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

O lado do servidor reflete-o com remote-cert-tls client e o seu próprio certificado, e é isso que impede que um certificado de cliente seja aceite como servidor. A verificação do nome é uma decisão separada da verificação de função. Leia a configuração implementada para ver que campo é comparado em vez de presumir uma correspondência de nome de anfitrião ao estilo do navegador. Ambos os lados devem também ser explícitos sobre em que emissor confiam, porque um caminho de ficheiro partilhado em toda a frota não é o mesmo que uma política partilhada.

Entregue os intermédios sem alargar a confiança

Os dois lados não têm de partilhar uma única cadeia de emissão. Quando um par apresenta um certificado assinado por um intermédio, o lado verificador precisa desse intermédio disponível, e o OpenVPN distingue a entrada da âncora de confiança dos certificados adicionais usados para completar uma cadeia apresentada localmente. A referência de opções TLS do OpenVPN 2.6 documenta ambos.

Uma CA intermédia não é um problema em si, mas uma raiz empresarial ampla atirada para o pacote de confiança é. Quanto mais ampla a âncora, mais certificados passam no teste da cadeia, e uma verificação de função não transforma isso numa lista de pessoal autorizado. Estreite a âncora até ao emissor que assina efetivamente as identidades de VPN onde a hierarquia o permite. Se não permitir, documente a âncora mais ampla como um risco aceite deliberadamente em vez de a deixar implícita.

Acorde com a equipa de PKI como a renovação e a revogação chegam aos verificadores de VPN, incluindo que emissores importam e quem publica a lista. Um ponto de distribuição de CRL incorporado num certificado é uma instrução, não uma prova de que algo o tenha obtido.

Decida como a revogação chega realmente

crl-verify faz com que o verificador consulte um ficheiro ou ponto final, e essa disposição precisa de um responsável e de um caminho de atualização. Uma lista copiada uma vez durante a implementação deixa silenciosamente de o proteger na primeira vez que um certificado é revogado.

Anote o tempo de propagação esperado e teste-o com um certificado que esteja disposto a revogar. Se a lista não puder ser atualizada no anfitrião de VPN, a alternativa é um período de validade mais curto mais um processo de renovação que realmente corra, não a suposição de que a revogação funciona porque existe um URL.

Prove a aceitação com um cliente real

Ligue um cliente que deveria ser permitido e confirme os detalhes do certificado negociado no registo. Depois experimente os casos que devem falhar: um certificado de cliente apresentado como servidor, um certificado de um emissor fora da âncora de confiança e um certificado revogado se tiver um a mais.

Registe o emissor aceite, a verificação de função e a fonte de revogação junto ao perfil. Esse registo é o que o próximo engenheiro precisa quando um dispositivo que funcionava no mês passado deixa de ligar, e é também a prova de que a CA empresarial é usada dentro de um limite de aceitação documentado em vez de como um aterro de confiança de uso geral.