Certificado VPN autosinado: que significa e en que confía

Aquí fan máis dano dúas crenzas: que un certificado VPN autosinado significa que o túnel non está cifrado, e que instalar o que pedise o cliente VPN só afecta a VPN. Ningunha sobrevive ao contacto cun despregamento real. Un certificado autosinado describe unha relación de sinatura, non un veredicto de seguridade, e o alcance da confianza que engade depende de en que almacén aterrice. Vín un servizo de asistencia importar unha raíz de provedor nunha máquina Windows para silenciar unha advertencia e despois pasar unha tarde explicando por que o navegador deixara de queixarse dun portal sen relación. As dúas metades desta pregunta van xuntas, así que tráteas como unha soa.

Un certificado non é un almacén de confianza

O ficheiro que presenta o servidor leva unha chave pública, un nome de suxeito, un nome de emisor, datas de validez e extensións. Autosinado significa que o suxeito e o emisor son a mesma entidade e que a sinatura se verifica coa propia chave do certificado. Nada nesa definición di que a conexión sexa débil, nin nada di que o cliente vaia aceptala.

A aceptación vén doutro sitio: un ficheiro CA ao que apunta o cliente, unha pegada que compara a man ou unha raíz que xa está nun almacén que o cliente le. Un despregamento pode ser perfectamente sólido mentres o seu certificado suspendería todos os exames públicos. openssl verify contra o paquete do sistema informará dun emisor descoñecido, e ese informe é correcto, non un fallo.

A opción ca de OpenVPN é o caso máis claro de confianza limitada á aplicación. Ese ficheiro nomea as áncoras que o cliente aceptará, e pode conter unha CA privada ou, nun despregamento pequeno, o propio certificado autosinado do servidor. A versión 2.6 tamén acepta --peer-fingerprint para fixar unha pegada SHA-256 en lugar de distribuír un ficheiro CA. WireGuard queda aínda máis lonxe: non ten ningún certificado, só unha chave pública estática por par, así que a pregunta autosinada non se lle aplica.

Onde instala a confianza decide quen a herda

Poña o mesmo certificado en tres lugares e obterá tres radios de explosión distintos. Un paquete que só le o cliente VPN afecta ese cliente. Unha raíz no almacén do sistema operativo afecta todos os programas que consultan ese almacén. Un navegador coa súa propia base de datos de confianza pode ignorar ambos, e por iso unha advertencia pode sobrevivir a unha importación que parecía funcionar.

En Debian ou Ubuntu, deixar un ficheiro en /usr/local/share/ca-certificates/ e executar update-ca-certificates altera o paquete de todo o sistema. En Windows, certutil -addstore -f Root escribe no almacén da máquina e necesita unha consola elevada, mentres que engadir -user apunta ao almacén do usuario actual; os dous non son intercambiables. Firefox mantén a súa propia base de datos NSS, así que unha importación a nivel do sistema operativo pode que nunca apareza alí.

O alcance importa polo que pode facer unha autoridade. Unha CA emisora pode asinar nomes cos que non ten ningunha relación, así que todo o que confíe nese almacén aceptará esas sinaturas. Unha soa folla fixada non pode facelo; autentica exactamente unha identidade de par. Se o obxectivo é facer que unha VPN conecte, unha CA limitada á aplicación ou unha folla fixada conseguen, mentres que unha raíz para toda a máquina é unha concesión moito maior do que esixe o síntoma.

Segue cifrando sen unha CA pública

O aperto de mans TLS deriva chaves de sesión tanto se o certificado do par encadea con algo en que xa confía como se non. Autosinado non significa texto plano, nin significa que o tráfico sexa lexible en voo. Significa que o cliente non ten ningunha razón a priori para crer que a chave pertence ao servidor que pediu.

Nesa fenda viven os ataques reais. Un cliente configurado para aceptar calquera certificado, xa sexa mediante un axuste de verificación desactivado ou un botón de confiar-aínda-así pulsado unha vez e esquecido, cifrará contento a quen responda. A interceptación ocorre no paso de autenticación, antes de que se movan os datos da aplicación. O cifrado sen comprobación de identidade mantén fóra un observador pasivo e fai pouco máis.

Confiar no emisor non se salta a comprobación do nome

A validación da cadea, a coincidencia do nome e o propósito do certificado son decisións separadas. Unha cadea pode ser válida mentres o nome é incorrecto, e un nome pode coincidir mentres o certificado se emitiu para outro papel. RFC 5280 define os campos que levan esas restricións, e ata que punto un cliente as aplica é cuestión de cada aplicación.

OpenVPN fai visible a separación. verify-x509-name fixa o suxeito esperado mediante a coincidencia de name, name-prefix ou subject. remote-cert-tls server esixe que o certificado do par poida usarse como certificado de servidor, o que rexeita un certificado só de cliente mesmo cando o emisor é de confianza. Ningún dos dous axustes se substitúe enviando un ficheiro CA.

Inspeccione o certificado antes de decidir nada:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName mostra quen o emitiu, para que nomes e ata cando.
• openssl verify -CAfile ca.crt server.crt comproba se a cadea que pensa enviar valida realmente a folla.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error funciona para puntos finais TLS como un portal web; o protocolo OpenVPN no 1194 non é un fluxo TLS simple, así que esa proba non se aplica alí.

Un certificado cunha data caducada, sen subjectAltName para o nome ao que se conecta ou sen o uso serverAuth falla independentemente de con canto coidado se instalou a áncora.

Cinco comprobacións antes de aceptar un

Compare a pegada por unha canle que non sexa a conexión que intenta reparar: unha consola, un instalador que xa teña, un ficheiro de configuración asinado. openssl x509 -in server.crt -noout -fingerprint -sha256 no servidor e o mesmo valor no rexistro do cliente abondan para saber que está a mirar un só obxecto.

Despois, decida que está instalando: unha folla ou unha autoridade que pode acuñar máis. Logo decida onde vai, e nomee as aplicacións que len ese almacén. Anote a ruta de retirada mentres aínda a lembra, porque confiar-e-seguir é como unha importación temporal se volve permanente.

Por último, planifique o cambio. Un certificado ou unha pegada fixados deben actualizarse pola mesma canle de confianza cando o certificado rote, e unha CA privada ten o seu propio ciclo de vida de emisión e revogación. Se a chave privada se filtra, volver confiar nunha copia do mesmo certificado non repara nada; hai que substituír a identidade.

Se unha advertencia sobrevive ás cinco comprobacións, a pregunta útil non é que botón a silencia senón que almacén le realmente o cliente e de onde veu esa raíz. Responda iso, e a importación que está a piques de facer convértese nunha decisión en lugar dun reflexo.