Miksi cryptoapicert epäonnistuu OpenVPN 3:ssa ja Connectissa Windowsissa

Kopioit toimivan OpenVPN 2 -profiilin uudempaan Windows-asiakasohjelmaan, eikä sertifikaattia, jonka vanha asiakasohjelma löysi itse, enää tarjota. Rivin, joka mahdollisti sen, on Windows-kohtainen valitsin, joka kuuluu Community 2 -asiakasohjelmalle, ja uudempi sovellus on toinen ohjelma, jolla on eri tunnistetietopolku. Profiili on muuttumaton lukuun ottamatta tuota yhtä riviä, ja juuri siksi ero on vaikea nähdä.

Tuossa raportissa sekoitetaan kolme kerrosta: Community-asiakasohjelma, ydinkirjasto ja käyttöliittymä, jonka joku asensi. Vain yksi niistä on koskaan ymmärtänyt direktiivin.

Mitä asetus tarkoittaa siellä, missä se on olemassa

Windowsin Community OpenVPN 2 -asiakasohjelmassa cryptoapicert nimeää sertifikaatin, joka asiakasohjelman pitää löytää Windowsin sertifikaattivarastosta eikä tiedostosta. Se on Windows-kohtainen mukavuus, ja se toimii, koska asiakasohjelma osaa luetella varaston ja antaa tuloksena olevan avaimen omalle TLS-pinollensa. Direktiivi on siis osa kyseisen asiakasohjelman konfigurointikieltä, ei OpenVPN-protokollan ominaisuus. Mikään siirtoformaatiossa ei kanna sitä.

Kopioi sama rivi toiseen sovellukseen, niin olet kopioinut sanan, jonka uusi ohjelma voi jäsentää, jättää huomiotta tai hylätä. Direktiivi ei ole protokollan ominaisuus, eikä tämä ole edes jokaisen asiakasohjelman ominaisuus, joka puhuu OpenVPN.

Mitä ydinkirjasto tarjoaa sen sijaan

OpenVPN 3 Core on kirjasto, jota muut sovellukset upottavat, ja se käsittelee ulkoiset tunnistetiedot API:n kautta varastohaun sijaan. Upottava sovellus toimittaa sertifikaattiketjun ja pyytää myöhemmin kirjastoa allekirjoittamaan ulkoisella avaimella, ja kirjasto kutsuu takaisin sovellukseen tehdäkseen sen. Se on yleisempi suunnittelu, ja se tarkoittaa, että käyttöliittymä päättää, mitä tarjoajia on olemassa. Kirjaston omassa asetuskäsittelyssä cryptoapicert esiintyy direktiivien joukossa, joita ei ole toteutettu, mikä on sopusoinnussa tämän vastuunjaon kanssa.

Näiden takaisinkutsujen olemassaolo ei tarkoita, että tietty paketoitu sovellus luettelee nykyisen käyttäjän henkilökohtaisen varaston, tukee tiettyä avaintarjoajaa tai voi saattaa älykorttipyynnön loppuun. Ne ovat käyttöliittymän ominaisuuksia, ja käyttöliittymän on dokumentoitava jokainen niistä.

Mistä Windows-käyttöliittymä huolehtii sen sijaan

OpenVPN Connect ottaa toisen reitin: käyttäjä tuo PKCS#12-tiedoston, joka sisältää sertifikaatin ja sen yksityisen avaimen, tätä tarkoitusta varten luotuun OpenVPN Certificate Storeen ja osoittaa sitten ulkoisen sertifikaatin profiilille. Se on tarkoituksellinen tuontivaihe, ei automaattinen löytö siitä, mitä henkilökohtaisessa varastossa sattuu olemaan. Ero on merkityksellinen, kun joku olettaa, että toiseen tarkoitukseen asennettu sertifikaatti yksinkertaisesti ilmestyy asiakasohjelman luetteloon.

Tuonnilla on seuraus myös avainkäytännölle, koska avaimen vienti P12-tiedostoon on juuri se, mitä ei-vietävä avain on suunniteltu estämään. Se on käytäntökysymys eikä konfigurointikysymys, ja se ansaitsee vastauksen ennen kuin kukaan yrittää tuontia.

Valitse polku, joka vastaa avaimen käytäntöä

Jos tunnistetieto on vietävä ja käytäntö sallii dokumentoidun tuonnin, käytä organisaation suojattua rekisteröintiprosessia ja pidä väliaikainen P12 ja sen salasana poissa lokeista ja skripteistä. Jos avain ei saa koskaan poistua älykortilta tai suojatulta tarjoajalta, valitse asiakasohjelman ja tarjoajan yhdistelmä, joka tukee tätä vaatimusta nimenomaisesti, tai hanki toimittajalta vahvistus asentamallesi versiolle. Kumpikaan haara ei ole toisen korvike.

Direktiivin lisääminen takaisin profiiliin ei voi tarjota integraatiota, jota sovelluksella ei ole. Eikä uudempi asiakasohjelmaversio välttämättä lisää sitä, koska kyky kuuluu käyttöliittymän omaan suunnitteluun.

Kun paikallinen avain toimii, palvelin tarkistaa edelleen sertifikaatin identiteetin, ketjun ja valtuutuksen. Käyttökelpoinen paikallinen avain ja hyväksytty VPN-identiteetti ovat erillisiä tuloksia, ja niiden pitäminen erillään on se, mikä estää käyttöliittymän rajoituksen muuttumisen heikentyneeksi sertifikaattikäytännöksi.