Kial cryptoapicert malsukcesas en OpenVPN 3 kaj Connect sur Windows

Vi kopias funkciantan OpenVPN 2-profilon en pli novan Windows-klienton, kaj la atestilo, kiun la malnova kliento mem trovis, ne plu proponiĝas. La linio, kiu ebligis tion, estas Windows-specifa selektilo apartenanta al la Community 2-kliento, kaj la pli nova aplikaĵo estas alia programo kun alia vojo por akreditaĵoj. La profilo restas senŝanĝa krom tiu unu linio, kaj ĝuste tio malfaciligas vidi la diferencon.

Tri tavoloj miksiĝas en tiu raporto: la Community-kliento, la kernbiblioteko, kaj la fasado, kiun iu instalis. Nur unu el ili iam komprenis la direktivon.

Kion la opcio signifas tie, kie ĝi ekzistas

En la Community OpenVPN 2-kliento sur Windows, cryptoapicert nomas atestilon, kiun la kliento devus trovi en la Windows-atestila konservejo anstataŭ en dosiero. Ĝi estas Windows-specifa komfortaĵo, kaj ĝi funkcias ĉar tiu kliento scias kiel listigi la konservejon kaj transdoni la rezultan ŝlosilon al sia propra TLS-stako. La direktivo do estas parto de la agorda lingvo de tiu kliento, ne eco de la OpenVPN-protokolo. Nenio en la transiga formato portas ĝin.

Kopiu la saman linion al alia aplikaĵo kaj vi kopiis vorton, kiun la nova programo povas analizi, ignori aŭ malakcepti. Direktivo ne estas protokola trajto, kaj ĉi tiu eĉ ne estas trajto de ĉiu kliento, kiu parolas OpenVPN.

Kion la kernbiblioteko anstataŭe montras

OpenVPN 3 Core estas biblioteko, kiun aliaj aplikaĵoj enigas, kaj ĝi traktas eksterajn akreditaĵojn per API anstataŭ per konserveja serĉo. La eniganta aplikaĵo liveras atestilan ĉenon kaj poste petas al la biblioteko subskribi per ekstera ŝlosilo, kaj la biblioteko revokas la aplikaĵon por fari tion. Tio estas pli ĝenerala dezajno, kaj ĝi signifas, ke la fasado decidas, kiuj provizantoj ekzistas. En la propra opciotraktado de la biblioteko, cryptoapicert aperas inter la direktivoj, kiuj ne estas realigitaj, kio kongruas kun tiu divido de respondeco.

La ekzisto de tiuj revokoj ne signifas, ke difinita pakaĵa aplikaĵo listigas la personan konservejon de la nuna uzanto, subtenas difinitan ŝlosilprovizanton aŭ povas fini inteligentkartan peton. Tiuj estas ecoj de la fasado, kaj ĉiun el ili devas dokumenti la fasado.

Kion anstataŭe faras la Windows-fasado

OpenVPN Connect sekvas alian vojon: la operatoro importas PKCS#12-dosieron enhavantan la atestilon kaj ĝian privatan ŝlosilon en OpenVPN Certificate Store kreitan por tiu celo, kaj poste atribuas la eksteran atestilon al la profilo. Tio estas intenca importa paŝo, ne aŭtomata malkovro de tio, kio hazarde troviĝas en la persona konservejo. La distingo gravas, kiam iu supozas, ke atestilo instalita por alia celo simple aperos en la listo de la kliento.

La importo ankaŭ havas sekvon por la ŝlosila politiko, ĉar eksporti ŝlosilon en P12-dosieron estas ĝuste tio, kion neeksportebla ŝlosilo celas malhelpi. Tio estas politika demando, ne agorda, kaj ĝi meritas respondon antaŭ ol iu provas la importon.

Elektu vojon, kiu kongruas kun la politiko de la ŝlosilo

Se la akreditaĵo estas eksportebla kaj la politiko permesas la dokumentitan importon, uzu la protektitan registran procezon de la organizo kaj tenu la tempan P12 kaj ĝian pasvorton ekster protokoloj kaj skriptoj. Se la ŝlosilo neniam rajtas lasi inteligentan karton aŭ protektitan provizanton, elektu kombinaĵon de kliento kaj provizanto, kiu eksplicite subtenas tiun postulon, aŭ akiru konfirmon de la vendinto por la versio, kiun vi instalas. Neniu el la du branĉoj anstataŭas la alian.

Redoni la direktivon al la profilo ne povas provizi integriĝon, kiun la aplikaĵo ne havas. Nek pli nova klienta versio nepre aldonas ĝin, ĉar la kapablo apartenas al la propra dezajno de la fasado.

Post kiam la loka ŝlosilo funkcias, la servilo ankoraŭ kontrolas la atestilan identecon, la ĉenon kaj la rajtigon. Uzebla loka ŝlosilo kaj akceptita VPN-identeco estas apartaj rezultoj, kaj teni ilin apartaj estas tio, kio malhelpas, ke limigo de la fasado fariĝu malfortigita atestila politiko.