Per què OpenVPN encara demana un fitxer de clau privada quan hi ha un testimoni

Connecteu el testimoni, l’eina del propi proveïdor el veu, i el client VPN encara demana un fitxer de clau privada. Aquesta petició no és cap prova que el testimoni no sigui compatible. Normalment vol dir que el perfil no va dir mai al client que fes servir el testimoni, i per això va tornar a les entrades de certificat i clau que espera per defecte.

Dos valors separats han de ser correctes abans que aquesta reculada s’aturi: el proveïdor que exposa el testimoni i la identitat del certificat que hi ha a dins. Els subministren opcions diferents i és fàcil confondre’ls.

El client demana un fitxer perquè el perfil ho diu

Un perfil per defecte espera un fitxer de certificat i un fitxer de clau privada, o un sol paquet PKCS#12. Quan aquestes entrades falten, el client no té res per carregar i es comporta gairebé com ho faria amb un fitxer absent, i per això el símptoma es llegeix com un camí trencat i no com un mecanisme absent. El camí PKCS#11 substitueix aquestes entrades en lloc de complementar-les, així que un perfil que encara nomena un fitxer de clau continuarà fent servir el fitxer. Traieu les entrades de fitxer de manera deliberada i deixeu que el testimoni aporti les dues meitats.

L’opció del proveïdor nomena una biblioteca intermediària, no un dispositiu ni un certificat. Que un client empaquetat pugui carregar aquesta biblioteca depèn de com es va compilar, incloent-hi el suport opcional de p11-kit que algunes compilacions activen i d’altres deixen fora. Un tutorial genèric no us pot dir quina disposició té el vostre paquet.

La identitat serialitzada és un valor diferent

La identitat del certificat és una cadena serialitzada llarga que produeix el procés de descoberta, i no és el camí de la biblioteca, ni el PIN del testimoni, ni el nom del compte VPN. Sovint conté caràcters que cal entrecomillar, i un valor sense cometes es pot truncar o llegir malament sense cap error clar. Feu servir l’opció descoberta d’identitat del propi client per llistar què exposa el testimoni i, després, copieu exactament l’entrada que voleu. Triar el primer objecte de la llista és com un dispositiu acaba presentant el certificat equivocat.

La sortida de la descoberta també respon una pregunta prèvia: si el testimoni és visible a través d’aquell proveïdor. Si no llista res, el problema és aigües amunt del client VPN i pertany a la biblioteca intermediària.

El procés que connecta ha d’arribar al testimoni

Una operació amb el testimoni que funciona a la vostra sessió d’escriptori no demostra res sobre un servei del sistema. El servei pot executar-se com un altre usuari, en un espai de noms de muntatge diferent, amb un camí de mòduls que omet la biblioteca del proveïdor o sense permís per obrir el node del dispositiu. Identifiqueu quin procés té realment la connexió i proveu-ho des d’aquest context.

La gestió del PIN mereix una decisió pròpia. La implementació de referència ofereix una memòria cau de PIN i un camí d’autenticació protegit, i tots dos existeixen perquè un operador pugui triar un flux de treball en lloc d’inventar-ne un. No convertiu un requisit sense supervisió en un PIN en text pla dins d’un perfil compartit, perquè això canvia la protecció del testimoni per comoditat. On el testimoni prohibeix l’exportació de claus, la signatura es fa al dispositiu i el PIN és l’únic secret local. Tracteu-lo amb la cura que això implica.

Què no substitueix el testimoni

El testimoni autentica el client sota la política desplegada i no substitueix les comprovacions del client sobre el servidor. Un certificat triat amb èxit no és permís per acceptar un certificat de passarel·la inesperat, i les dues verificacions protegeixen direccions oposades.

L’enrolament encara ha de passar a l’emissor, i la passarel·la encara ha d’autoritzar la identitat.

Per a l’acceptació, separeu les etapes: el proveïdor es carrega, es troba el certificat previst, la clau privada s’usa amb autorització local, el VPN s’autentica i l’operació sobre el recurs té èxit. Atureu-vos a la primera etapa que falli en lloc de recórrer contrasenyes i reinstal·lar la pila criptogràfica.

Registreu les versions, la propietat dels mòduls, l’identificador públic triat i els errors sanejats, i deixeu els PIN i els paquets de credencials fora d’aquest registre.