De ce OpenVPN mai cere un fișier de cheie privată atunci când există un token
Profilul probabil nu a numit niciodată tokenul. Separați biblioteca furnizorului de identitatea serializată a certificatului, apoi testați din procesul care se conectează.
Conectați tokenul, instrumentul furnizorului însuși îl vede, iar clientul VPN cere în continuare un fișier de cheie privată. Acea solicitare nu este dovada că tokenul nu este acceptat. De obicei înseamnă că profilul nu i-a spus niciodată clientului să folosească tokenul, așa că a revenit la intrările de certificat și cheie pe care le așteaptă implicit.
Două valori separate trebuie să fie corecte înainte ca această revenire să se oprească: furnizorul care expune tokenul și identitatea certificatului din interiorul lui. Ele sunt furnizate prin opțiuni diferite și este ușor să le confundați.
Clientul cere un fișier pentru că profilul îi spune asta
Un profil implicit așteaptă un fișier de certificat și un fișier de cheie privată, sau un singur pachet PKCS#12. Când aceste intrări lipsesc, clientul nu are ce încărca și se comportă aproape ca la un fișier absent, motiv pentru care simptomul este citit ca o cale defectă și nu ca un mecanism lipsă. Calea PKCS#11 înlocuiește acele intrări în loc să le completeze, așa că un profil care încă numește un fișier de cheie va continua să folosească fișierul. Eliminați deliberat intrările de fișier și lăsați tokenul să furnizeze ambele jumătăți.
Opțiunea furnizorului numește o bibliotecă de middleware, nu un dispozitiv și nu un certificat. Dacă un client împachetat poate încărca acea bibliotecă depinde de modul în care a fost construit, inclusiv de suportul opțional pentru p11-kit pe care unele compilări îl activează, iar altele îl omit. Un tutorial generic nu vă poate spune ce aranjament are pachetul dumneavoastră.
Identitatea serializată este o altă valoare
Identitatea certificatului este un șir serializat lung produs de procesul de descoperire și nu este calea bibliotecii, nici PIN-ul tokenului, nici numele contului VPN. Conține adesea caractere care necesită ghilimele, iar o valoare fără ghilimele poate fi trunchiată sau citită greșit fără o eroare clară. Folosiți opțiunea descoperire a identității a clientului pentru a lista ce expune tokenul, apoi copiați exact intrarea dorită. Alegerea primului obiect din listă este modul în care un dispozitiv ajunge să prezinte certificatul greșit.
Rezultatul descoperirii răspunde și la o întrebare anterioară: dacă tokenul este vizibil prin acel furnizor. Dacă nu listează nimic, problema se află deasupra clientului VPN și aparține middleware-ului.
Procesul care se conectează trebuie să ajungă la token
O operație cu tokenul care funcționează în sesiunea dumneavoastră de desktop nu dovedește nimic despre un serviciu de sistem. Serviciul poate rula ca alt utilizator, într-un spațiu de nume de montare diferit, cu o cale de module care omite biblioteca furnizorului sau fără permisiunea de a deschide nodul dispozitivului. Identificați ce proces deține efectiv conexiunea și testați din acel context.
Gestionarea PIN merită o decizie proprie. Implementarea de referință oferă un cache de PIN și o cale de autentificare protejată, iar ambele există pentru ca un operator să aleagă un flux de lucru în loc să inventeze unul. Nu transformați o cerință nesupravegheată într-un PIN în text simplu într-un profil partajat, pentru că asta schimbă protecția tokenului pe confort. Acolo unde tokenul interzice exportul cheii, semnarea are loc pe dispozitiv, iar PIN-ul este singurul secret local. Tratați-l cu grija pe care o implică.
Ce nu înlocuiește tokenul
Tokenul autentifică clientul conform politicii implementate și nu înlocuiește verificările clientului asupra serverului. Un certificat selectat cu succes nu este permisiunea de a accepta un certificat de gateway neașteptat, iar cele două verificări protejează direcții opuse.
Înregistrarea trebuie să aibă loc în continuare la emitent, iar gateway-ul trebuie să autorizeze în continuare identitatea.
Pentru acceptare, separați etapele: furnizorul se încarcă, certificatul dorit este găsit, cheia privată este folosită cu autorizare locală, VPN-ul se autentifică și operația asupra resursei reușește. Opriți-vă la prima etapă care eșuează în loc să parcurgeți parole și să reinstalați stiva criptografică.
Înregistrați versiunile, proprietatea modulelor, identificatorul public ales și erorile curățate, și lăsați PIN-urile și pachetele de acreditări în afara acelei evidențe.