Un perfil OpenVPN té tres blocs de certificat: quin és secret?
Un perfil porta un certificat de CA, un certificat de client i una clau privada que es semblen. Només un és secret, i cadascun falla d'una manera diferent.
Obriu un fitxer .ovpn per canviar una línia i trobeu tres blocs de base64 que semblen credencials. Un és segur de publicar, un és tan sensible com una contrasenya, i un és una clau pública que no significa res si una altra cosa no ha estat signada amb la seva parella. La gent enganxa el fitxer sencer en un fil de suport perquè els blocs semblen intercanviables, i així és com una clau de client acaba en un arxiu públic. Aclarir què fa cada bloc explica bona part de la confusió al voltant d'aquests perfils, i també us diu quines fallades us toca arreglar.
Un fitxer, tres blocs, feines diferents
Un perfil típic incrusta un bloc ca, un bloc cert i un bloc key entre els marcadors BEGIN i END, o bé apunta als mateixos tres com a fitxers separats. Alguns perfils afegeixen un quart bloc per a una clau tls-auth o tls-crypt, que és un secret compartit i no un certificat. El client llegeix cada bloc segons la directiva que el nomena, així que les etiquetes importen més que l'ordre en què apareixen.
Tracteu el perfil muntat com a sensible fins que hàgiu mirat realment a dins. Un certificat públic i una clau privada poden estar a poques línies l'un de l'altre dins del mateix fitxer, i una captura de pantalla que inclogui la capçalera pot incloure tots dos. Tapar el base64 visible a mà tampoc no és fiable, perquè un bloc parcial encara filtra les metadades del certificat que nomenen el vostre desplegament. Copiar les tres directives sense els seus valors sol ser prou per fer una pregunta útil.
Les directives al voltant dels blocs decideixen com s'utilitzen. Canvieu ca i el client confia en una altra autoritat; canvieu cert sense canviar key i l'apretada de mà falla amb una discrepància que no té res a veure amb la confiança.
El bloc de CA és públic, la clau de CA mai no ho és
Una autoritat de certificació signa certificats que lliguen una clau pública a una identitat, i el seu propi certificat és l'àncora que fa servir un client per decidir si una cadena és fiable. Aquest certificat és públic per disseny: enviar-lo dins de cada perfil és normal, i és la raó per la qual un desplegament autosignat pot funcionar sense una autoritat comercial.
El que no ha d'aparèixer mai en un perfil de client és la clau privada de signatura de l'autoritat. El client no la necessita per validar res, i la seva presència vol dir que qui tingui el perfil pot encunyar identitats noves per a tot el desplegament.
Confiar en una autoritat també és més estret del que sembla. Un client que accepta qualsevol certificat signat per la CA encara acceptarà un certificat emès per a un altre servei a la mateixa CA. Les opcions que fixen el rol o el nom esperat del servidor tanquen aquesta escletxa, i la Referència d'opcions de TLS llista les directives de verificació que ho fan.
Els certificats de servidor i de client apunten en direccions oposades
El certificat del servidor és el que el client inspecciona per confirmar que ha arribat al punt final correcte. El vostre certificat de client va en l'altre sentit: el servidor el fa servir per decidir que aquest dispositiu o usuari és un que ell ha inscrit. Mateix format, sentit de confiança oposat.
Una adreça no és una identitat. Arribar a la IP correcta no demostra res sobre qui ha respost, i per això la comprovació del nom d'amfitrió o del nom del certificat continua pertanyent al perfil. Una contrasenya de compte tampoc no substitueix en silenci un certificat de client exigit, perquè tots dos es comproven en etapes diferents i un desplegament pot exigir els dos.
La clau privada del client és la part que ha de romandre privada. Si pot haver quedat exposada, esborrar el fitxer del vostre portàtil no canvia res al servidor, que continuarà acceptant el certificat corresponent fins que l'operador el revoqui. Demanar a l'operador que reemplaci o revoqui aquesta identitat és l'única solució que viatja amb vosaltres.
Dos avisos que semblen idèntics i no ho són
Una clau desada en forma xifrada demana una contrasenya de pas abans que el client la pugui fer servir. El servei de VPN pot demanar per separat una contrasenya de compte, i els dos avisos poden aparèixer amb segons de diferència i gairebé el mateix redactat. La contrasenya de pas protegeix un fitxer del vostre disc; la contrasenya de compte demostra un compte a un servidor. Confondre-les envia la gent a restabliments de contrasenya que no poden ajudar de cap manera.
Llegiu l'avís abans de restablir res. Un restabliment de contrasenya de compte no fa res per una contrasenya de pas oblidada d'una clau, un certificat revocat o un d'expirada, i restablir la contrasenya quan la fallada és de validació del certificat converteix una solució de dos minuts en un cas de suport. Si la queixa esmenta dates de validesa, comproveu primer el rellotge del dispositiu i després la finestra pròpia del certificat esmentat.
Quan el certificat realment ha expirat, el reemplaçament ha de venir de qui el va emetre. Una clau que pertany a algú altre no és un camí de renovació, i manllevar un perfil que funciona d'un col·lega tampoc no ho és.
Què demostra una apretada de mà neta i què no
Arribar a una apretada de mà TLS completada vol dir que la relació d'identitat configurada s'ha mantingut: el certificat del servidor encadenat a la vostra CA i el vostre certificat acceptat. No diu res sobre la política de registres de l'operador, ni sobre si les vostres aplicacions funcionaran quan el túnel estigui aixecat.
Les rutes i el DNS són etapes posteriors de la connexió, així que un amfitrió d'intranet inaccessible després d'un inici de sessió correcte és un problema de connectivitat i no de certificat. Treballeu aquesta capa en lloc d'intercanviar credencials, i manteniu junts l'origen del perfil, el seu material privat i les seves comprovacions d'identitat quan el passeu a algú.