De ce cryptoapicert eșuează în OpenVPN 3 și Connect pe Windows

Copiați un profil OpenVPN 2 funcțional într-un client Windows mai nou, iar certificatul pe care clientul vechi îl găsea singur nu mai este oferit. Linia care făcea asta posibil este un selector specific Windows care aparține clientului Community 2, iar aplicația mai nouă este un alt program cu o altă cale de acreditări. Profilul este neschimbat în afară de acea linie, și exact asta face diferența greu de observat.

În acel raport se amestecă trei straturi: clientul Community, biblioteca de bază și interfața pe care a instalat-o cineva. Doar unul dintre ele a înțeles vreodată directiva.

Ce înseamnă opțiunea acolo unde există

În clientul Community OpenVPN 2 pe Windows, cryptoapicert numește un certificat pe care clientul trebuie să îl găsească în magazinul de certificate Windows, nu într-un fișier. Este o comoditate specifică Windows și funcționează pentru că acel client știe să enumere magazinul și să predea cheia rezultată propriului stivă TLS. Prin urmare, directiva face parte din limbajul de configurare al acelui client, nu dintr-o proprietate a protocolului OpenVPN. Nimic din formatul de transmisie nu o transportă.

Copiați aceeași linie într-o altă aplicație și ați copiat un cuvânt pe care noul program îl poate analiza, ignora sau respinge. O directivă nu este o caracteristică a protocolului, iar aceasta nu este nici măcar o caracteristică a fiecărui client care vorbește OpenVPN.

Ce expune în schimb biblioteca de bază

OpenVPN 3 Core este o bibliotecă pe care alte aplicații o încorporează și tratează acreditările externe printr-un API, nu printr-o căutare în magazin. Aplicația care o încorporează furnizează un lanț de certificate și apoi cere bibliotecii să semneze cu o cheie externă, iar biblioteca apelează înapoi aplicația pentru a face asta. Este un design mai general și înseamnă că interfața decide ce furnizori există. În propria procesare de opțiuni a bibliotecii, cryptoapicert apare printre directivele care nu sunt implementate, ceea ce este consecvent cu acea împărțire a responsabilităților.

Existența acelor apeluri inverse nu înseamnă că o anumită aplicație împachetată enumera magazinul personal al utilizatorului curent, acceptă un anumit furnizor de chei sau poate finaliza o solicitare de card inteligent. Acestea sunt proprietăți ale interfeței, iar fiecare trebuie documentată de interfață.

Ce face în schimb interfața Windows

OpenVPN Connect urmează o altă cale: operatorul importă un fișier PKCS#12 care conține certificatul și cheia sa privată într-un OpenVPN Certificate Store creat în acest scop, apoi atribuie certificatul extern profilului. Este un pas de import deliberat, nu o descoperire automată a ceea ce se află în magazinul personal. Distincția contează când cineva presupune că un certificat instalat pentru alt scop va apărea pur și simplu în lista clientului.

Importul are și o consecință pentru politica de chei, pentru că exportul unei chei într-un fișier P12 este exact ceea ce o cheie neexportabilă este concepută să împiedice. Este o chestiune de politică, nu de configurare, și merită un răspuns înainte ca cineva să încerce importul.

Alegeți o cale care se potrivește cu politica cheii

Dacă acreditarea este exportabilă și politica permite importul documentat, folosiți procesul de înregistrare protejat al organizației și țineți P12 temporar și parola acestuia în afara jurnalelor și scripturilor. Dacă cheia nu trebuie să părăsească niciodată un card inteligent sau un furnizor protejat, alegeți o combinație de client și furnizor care susține explicit această cerință, sau obțineți confirmarea furnizorului pentru versiunea pe care ați instalat-o. Niciuna dintre cele două ramuri nu este o soluție alternativă pentru cealaltă.

Adăugarea din nou a directivei în profil nu poate oferi o integrare pe care aplicația nu o are. Nici o versiune mai nouă a clientului nu o adaugă neapărat, pentru că abilitatea aparține designului propriu al interfeței.

După ce cheia locală funcționează, serverul verifică în continuare identitatea certificatului, lanțul și autorizarea. O cheie locală utilizabilă și o identitate VPN acceptată sunt rezultate separate, iar păstrarea lor separate este ceea ce împiedică o limitare a interfeței să devină o politică de certificate slăbită.