Un perfil de OpenVPN ten tres bloques de certificado: cal é secreto?
Un perfil leva un certificado de CA, un certificado de cliente e unha clave privada que se parecen. Só un é secreto, e cada un falla dun xeito distinto.
Abres un ficheiro .ovpn para cambiar unha liña e atopas tres bloques de base64 que parecen credenciais. Un é seguro de publicar, outro é tan sensible como un contrasinal e outro é unha clave pública que non significa nada se outra cousa non se asinou coa súa parella. A xente pega o ficheiro enteiro nun fío de soporte porque os bloques parecen intercambiables, e así é como unha clave de cliente acaba nun arquivo público. Aclarar que fai cada bloque explica boa parte da confusión arredor destes perfís e tamén che di que fallos che toca arranxar a ti.
Un ficheiro, tres bloques, traballos distintos
Un perfil típico incrusta un bloque ca, un bloque cert e un bloque key entre os marcadores BEGIN e END, ou ben apunta aos mesmos tres como ficheiros separados. Algúns perfís engaden un cuarto bloque para unha clave tls-auth ou tls-crypt, que é un segredo compartido e non un certificado. O cliente le cada bloque segundo a directiva que o nomea, así que as etiquetas importan máis que a orde na que aparecen.
Trata o perfil montado como sensible ata que mirases de verdade dentro. Un certificado público e unha clave privada poden estar a poucas liñas un do outro no mesmo ficheiro, e unha captura de pantalla que inclúa a cabeceira pode incluír ambos. Tapar o base64 visible á man tampouco é fiable, porque un bloque parcial segue filtrando os metadatos do certificado que nomean o teu despregamento. Copiar as tres directivas sen os seus valores adoita abondar para facer unha pregunta útil.
As directivas arredor dos bloques deciden como se usan. Cambia ca e o cliente confía noutra autoridade; cambia cert sen cambiar key e o apretón de mans falla cunha discrepancia que non ten nada que ver coa confianza.
O bloque de CA é público, a clave de CA nunca
Unha autoridade de certificación asina certificados que ligan unha clave pública a unha identidade, e o seu propio certificado é a áncora que usa un cliente para decidir se unha cadea é fiable. Ese certificado é público por deseño: envialo dentro de cada perfil é normal, e é a razón pola que un despregamento autoasinado pode funcionar sen unha autoridade comercial.
O que nunca debe aparecer nun perfil de cliente é a clave privada de sinatura da autoridade. O cliente non a necesita para validar nada, e a súa presenza significa que quen teña o perfil pode cuñar identidades novas para todo o despregamento.
Confiar nunha autoridade tamén é máis estreito do que soa. Un cliente que acepta calquera certificado asinado pola CA seguirá aceptando un certificado emitido para outro servizo na mesma CA. As opcións que fixan o rol ou o nome esperado do servidor pechan esa fenda, e a Referencia de opcións de TLS enumera as directivas de verificación que o fan.
Os certificados de servidor e de cliente apuntan en direccións opostas
O certificado do servidor é o que o cliente inspecciona para confirmar que chegou ao punto final correcto. O teu certificado de cliente vai ao revés: o servidor úsao para decidir que este dispositivo ou usuario é un que el inscribiu. Mesmo formato, dirección de confianza oposta.
Un enderezo non é unha identidade. Chegar ao IP correcto non demostra nada sobre quen respondeu, por iso a comprobación do nome de host ou do nome do certificado segue pertencendo ao perfil. Un contrasinal de conta tampouco substitúe en silencio un certificado de cliente esixido, porque os dous se comproban en etapas distintas e un despregamento pode esixir ambos.
A clave privada do cliente é a parte que debe permanecer privada. Se puido quedar exposta, borrar o ficheiro do teu portátil non cambia nada no servidor, que seguirá aceptando o certificado correspondente ata que o operador o revogue. Pedirlle ao operador que substitúa ou revogue esa identidade é a única solución que viaxa contigo.
Dous avisos que parecen idénticos e non o son
Unha clave gardada en forma cifrada pide unha frase de contrasinal antes de que o cliente poida usala. O servizo de VPN pode pedir por separado un contrasinal de conta, e os dous avisos poden aparecer con segundos de diferenza e case o mesmo texto. A frase de contrasinal protexe un ficheiro do teu disco; o contrasinal demostra unha conta ante un servidor. Confundilas manda á xente a restablecementos que non poden axudar de ningunha maneira.
Le o aviso antes de restablecer nada. Un restablecemento de contrasinal de conta non fai nada por unha frase de contrasinal esquecida dunha clave, un certificado revogado ou un caducado, e restablecer o contrasinal cando o fallo é de validación do certificado converte unha solución de dous minutos nun caso de soporte. Se a queixa menciona datas de validez, comproba primeiro o reloxo do dispositivo e despois a xanela propia do certificado nomeado.
Cando o certificado caducou de verdade, a substitución ten que vir de quen o emitiu. Unha clave que pertence a outra persoa non é unha vía de renovación, e coller prestado un perfil que funciona dun colega tampouco.
Que demostra un apretón de mans limpo e que non
Chegar a un apretón de mans TLS completado significa que a relación de identidade configurada aguantou: o certificado do servidor encadeou coa túa CA e o teu certificado foi aceptado. Non di nada sobre a política de rexistros do operador, nin sobre se as túas aplicacións funcionarán unha vez levantado o túnel.
As rutas e o DNS son etapas posteriores da conexión, así que un host de intranet inalcanzable tras un inicio de sesión correcto é un problema de conectividade e non de certificado. Traballa esa capa en lugar de cambiar credenciais, e mantén xuntos a orixe do perfil, o seu material privado e as súas comprobacións de identidade cando llo pases a alguén.