Zakaj cryptoapicert v OpenVPN 3 in Connect v Windowsu ne deluje
Ta direktiva pripada enemu odjemalcu Windows, ne protokolu. Jedrna knjižnica ponuja povratne klice za podpisovanje, vmesnik pa ima svoj potek uvoza.
Kopirate delujoč profil OpenVPN 2 v novejši odjemalec Windows, in potrdilo, ki ga je stari odjemalec našel sam, ni več ponujeno. Vrstica, ki je to omogočila, je izbirnik, specifičen za Windows, ki pripada odjemalcu Community 2, novejša aplikacija pa je drug program z drugo potjo poverilnic. Profil je nespremenjen razen te vrstice, in prav zato je razliko težko opaziti.
V tem poročilu se mešajo tri plasti: odjemalec Community, jedrna knjižnica in vmesnik, ki ga je nekdo namestil. Le ena od njih je kdaj razumela direktivo.
Kaj možnost pomeni tam, kjer obstaja
V odjemalcu Community OpenVPN 2 v Windowsu cryptoapicert označuje potrdilo, ki naj ga odjemalec najde v shrambi potrdil Windows in ne v datoteki. To je priročnost, specifična za Windows, in deluje, ker ta odjemalec zna našteti shrambo in dobljeni ključ izročiti lastnemu skladu TLS. Direktiva je torej del konfiguracijskega jezika tega odjemalca, ne lastnost protokola OpenVPN. Nič v prenosnem formatu je ne nosi.
Kopirajte isto vrstico v drugo aplikacijo in kopirali ste besedo, ki jo nov program lahko razčleni, prezre ali zavrne. Direktiva ni lastnost protokola, in ta ni niti lastnost vsakega odjemalca, ki govori OpenVPN.
Kaj namesto tega ponuja jedrna knjižnica
OpenVPN 3 Core je knjižnica, ki jo vgrajujejo druge aplikacije, in zunanje poverilnice obravnava prek API-ja, ne z iskanjem po shrambi. Aplikacija, ki jo vgrajuje, priskrbi verigo potrdil in nato prosi knjižnico, da podpiše z zunanjim ključem, knjižnica pa v ta namen pokliče aplikacijo nazaj. To je splošnejša zasnova in pomeni, da vmesnik odloča, kateri ponudniki obstajajo. V lastni obdelavi možnosti knjižnice se cryptoapicert pojavi med direktivami, ki niso izvedene, kar je skladno s to delitvijo odgovornosti.
Obstoj teh povratnih klicev ne pomeni, da določena pakirana aplikacija našteje osebno shrambo trenutnega uporabnika, podpira določenega ponudnika ključev ali lahko dokonča poziv pametne kartice. To so lastnosti vmesnika in vsako od njih mora dokumentirati vmesnik.
Kaj namesto tega počne vmesnik Windows
OpenVPN Connect ubira drugo pot: operater uvozi datoteko PKCS#12, ki vsebuje potrdilo in njegov zasebni ključ, v OpenVPN Certificate Store, ustvarjen v ta namen, nato pa zunanje potrdilo dodeli profilu. To je nameren korak uvoza, ne samodejno odkrivanje tega, kar je v osebni shrambi. Razlika je pomembna, ko nekdo domneva, da se bo potrdilo, nameščeno za drug namen, preprosto pojavilo na seznamu odjemalca.
Uvoz ima posledice tudi za politiko ključev, ker je izvoz ključa v datoteko P12 natanko to, čemur naj bi ključ, ki ga ni mogoče izvoziti, preprečil. To je vprašanje politike, ne konfiguracije, in si zasluži odgovor, preden kdo poskusi z uvozom.
Izberite pot, ki ustreza politiki ključa
Če je poverilnica izvozljiva in politika dovoljuje dokumentirani uvoz, uporabite zaščiten postopek registracije organizacije in hranite začasni P12 ter njegovo geslo zunaj dnevnikov in skriptov. Če ključ nikoli ne sme zapustiti pametne kartice ali zaščitenega ponudnika, izberite kombinacijo odjemalca in ponudnika, ki to zahtevo izrecno podpira, ali pridobite potrditev ponudnika za različico, ki ste jo namestili. Nobena veja ni obhod za drugo.
Vračanje direktive v profil ne more zagotoviti integracije, ki je aplikacija nima. Tudi novejša različica odjemalca je ne doda nujno, ker zmožnost pripada lastni zasnovi vmesnika.
Ko lokalni ključ deluje, strežnik še vedno preverja identiteto potrdila, verigo in avtorizacijo. Uporaben lokalni ključ in sprejeta identiteta VPN sta ločena izida, in prav njuno ločevanje preprečuje, da bi se omejitev vmesnika spremenila v oslabljeno politiko potrdil.