Autoselixado fronte a CA pública para unha VPN: que cambia realmente

Chegas á páxina de certificados dunha configuración de VPN, ves unha opción autoselixada gratuíta xunto a unha CA pública de pagamento, e a pregunta soa a unha decisión de seguridade. En realidade é unha decisión de audiencia. Ambas as opcións cifran o túnel coas mesmas primitivas, e ambas se volven inútiles se a clave privada se filtra. O que as separa é quen fai a afirmación sobre a identidade do servidor e quen está en posición de comprobar esa afirmación.

Un certificado fai dous traballos que se confunden

Un certificado liga unha clave pública a un nome, e a clave fai o traballo de cifrado e sinatura. A sinatura do certificado é unha declaración aparte: algunha autoridade comprobou que o nome pertence a este titular da clave. Un certificado autoselixado fai esa declaración sobre si mesmo, o que non é en absoluto unha afirmación de terceiros.

Os sitios web públicos necesitan a versión con terceiros, porque os visitantes chegan sen ningunha relación previa e dependen do almacén de confianza do navegador. Un cliente VPN non é un descoñecido. Dáslle o certificado da CA, ou fixas o certificado do servidor, dentro do perfil que instala, así que a verificación se executa contra exactamente a autoridade que escolliches. Ningunha CA comercial ten que participar para que esa comprobación signifique algo.

A forza da sesión resultante vén do tamaño da clave e do conxunto de cifrados, non do firmante. Por iso chamar "menos cifrado" a un certificado autoselixado é simplemente incorrecto; está menos amplamente avalado, que é unha propiedade distinta.

Onde unha CA pública gaña a súa tarifa

O caso máis claro é a páxina de administración. Se os colegas, os contratistas ou calquera outra persoa sen un perfil preparado teñen que abrir a interface web do servidor VPN sen un aviso do navegador, un certificado de confianza pública elimina esa fricción. O navegador xa confía no firmante, así que non hai nada que importar nin nada que explicar.

Esa comodidade ten custos que paga a pena nomear antes de comprar. A renovación ten que automatizarse ou o sitio rompe segundo un calendario, os certificados públicos expoñen o nome de host nos rexistros de transparencia de certificados, e os límites de taxa de emisión castigan un script que reintenta con demasiado entusiasmo. Nada diso é motivo para evitar unha CA pública, pero é traballo operativo que unha CA privada traslada a outro lugar.

O que un certificado público non fai é autenticar os teus usuarios. A identidade do cliente é unha decisión aparte, tomada con certificados de cliente, contrasinais ou un segundo factor, e a CA que asina o servidor non di nada sobre quen pode conectarse a el.

Onde encaixa unha CA privada nunha VPN

Para unha VPN privada cun conxunto coñecido de clientes, executar a túa propia CA é a opción convencional. Creas a CA unha vez, asinas o certificado do servidor cun nome que os clientes usarán e distribúes o certificado da CA dentro de cada perfil. Cada cliente verifica entón o servidor contra a túa autoridade, e ningunha parte externa coñece o nome de host.

Os custos son reais pero acoutados. Os navegadores avisarán cando alguén abra a páxina de administración directamente, porque o navegador non ten motivo para confiar na túa CA. A distribución de perfís pasa a formar parte da incorporación, e rotar a CA significa tocar cada cliente. Son prezos aceptables para un servizo con dez ou cincuenta usuarios coñecidos e dolorosos para un punto final público con miles.

Unha condición fai válido todo o arranxo: a verificación ten que ocorrer. Un cliente configurado para ignorar erros de certificado acepta calquera servidor que presente calquera certificado, así que a garantía de identidade desaparece mentres o cifrado permanece. Ese axuste é a debilidade real na maioría das historias de "autoselixado é inseguro".

A clave privada da CA decide que podes facer despois

A sorpresa adoita chegar meses despois, cando queres engadir un dispositivo. Emitir un certificado de cliente require a clave privada da CA, e producir unha lista de revogación tamén. Se herdaches un servidor que ten os ficheiros de certificado e clave pero non a clave da CA, non podes asinar nada novo. As túas opcións son reconstruír a PKI e entregar a cada cliente un certificado de CA novo, ou cambiar a autenticación por contrasinal, que é un modelo de seguridade distinto e non restaura o que se perdeu.

Dúas trampas menores viven no mesmo territorio. Os scripts de easy-rsa asumen que estás no directorio que os contén, así que un erro de ficheiro non atopado normalmente significa a localización equivocada e non unha instalación danada. E un deseño só con certificados é perfectamente lexítimo: podes esixir certificados de cliente sen unha clave precompartida, sempre que cada cliente teña un e o servidor verifique a cadea.

Emite un certificado por dispositivo en lugar dun certificado de cliente compartido para todo o equipo. Un portátil perdido custarache entón unha soa revogación en vez dunha reemisión para todos.

Comproba o que herdaches

Antes de planificar calquera cambio, le o certificado que xa tes:

$ 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 emisor é igual ao suxeito, o certificado é autoselixado, o que é unha elección de deseño e non un defecto. As datas dinche cando a renovación se converte no problema de alguén, e unha verificación correcta contra a CA que pensas despregar confirma que a cadea funciona antes de que un só cliente o intente.

Despois escolle por audiencia e distribución: CA pública cando navegadores descoñecidos deben confiar na páxina de administración, CA privada cando cada cliente recibe un perfil que controlas. Ningunha das dúas respostas está máis cifrada ca a outra.