Waarom cryptoapicert mislukt in OpenVPN 3 en Connect op Windows

U kopieert een werkend OpenVPN 2-profiel naar een nieuwere Windows-client, en het certificaat dat de oude client zelf vond, wordt niet meer aangeboden. De regel die dat mogelijk maakte is een Windows-specifieke selectie die bij de Community 2-client hoort, en de nieuwere toepassing is een ander programma met een ander pad voor inloggegevens. Het profiel is ongewijzigd op die ene regel na, en dat is precies wat het verschil moeilijk zichtbaar maakt.

In dat rapport lopen drie lagen door elkaar: de Community-client, de kernbibliotheek en de frontend die iemand heeft geïnstalleerd. Slechts één ervan heeft de richtlijn ooit begrepen.

Wat de optie betekent waar ze bestaat

In de Community OpenVPN 2-client op Windows benoemt cryptoapicert een certificaat dat de client in het Windows-certificaatarchief moet vinden in plaats van in een bestand. Het is een Windows-specifiek gemak, en het werkt omdat die client het archief kan opsommen en de resulterende sleutel aan zijn eigen TLS-stack kan geven. De richtlijn maakt dus deel uit van de configuratietaal van die client, niet van een eigenschap van het OpenVPN-protocol. Niets in het transportformaat draagt haar.

Kopieer dezelfde regel naar een andere toepassing en u hebt een woord gekopieerd dat het nieuwe programma kan parseren, negeren of weigeren. Een richtlijn is geen protocolfunctie, en deze is zelfs geen functie van elke client die OpenVPN.

Wat de kernbibliotheek in plaats daarvan biedt

OpenVPN 3 Core is een bibliotheek die andere toepassingen insluiten, en ze behandelt externe inloggegevens via een API in plaats van een archiefzoekopdracht. De toepassing die haar insluit levert een certificaatketen en vraagt de bibliotheek later om met een externe sleutel te ondertekenen, en de bibliotheek roept daarvoor terug naar de toepassing. Dat is een algemener ontwerp, en het betekent dat de frontend bepaalt welke aanbieders bestaan. In de eigen optieverwerking van de kern verschijnt cryptoapicert bij de richtlijnen die niet zijn geïmplementeerd, wat past bij die taakverdeling.

Het bestaan van die callbacks betekent niet dat een bepaalde verpakte toepassing het persoonlijke archief van de huidige gebruiker opsomt, een bepaalde sleutelaanbieder ondersteunt of een smartcard-prompt kan voltooien. Dat zijn frontend-eigenschappen, en elk daarvan moet door de frontend worden gedocumenteerd.

Wat de Windows-frontend in plaats daarvan doet

OpenVPN Connect neemt een andere route: de operator importeert een PKCS#12-bestand met het certificaat en de bijbehorende persoonlijke sleutel in een OpenVPN Certificate Store die daarvoor is aangemaakt, en wijst daarna het externe certificaat aan het profiel toe. Dat is een bewuste importstap, geen automatische ontdekking van wat toevallig in het persoonlijke archief staat. Het onderscheid is belangrijk wanneer iemand aanneemt dat een certificaat dat voor een ander doel is geïnstalleerd gewoon in de lijst van de client zal verschijnen.

De import heeft ook gevolgen voor het sleutelbeleid, want een sleutel naar een P12-bestand exporteren is precies wat een niet-exporteerbare sleutel moet voorkomen. Dat is een beleidsvraag en geen configuratievraag, en ze verdient een antwoord voordat iemand de import probeert.

Kies een route die bij het beleid van de sleutel past

Als de inloggegevens exporteerbaar zijn en het beleid de gedocumenteerde import toestaat, gebruik dan het beveiligde registratieproces van de organisatie en houd de tijdelijke P12 en het bijbehorende wachtwoord buiten logboeken en scripts. Als de sleutel nooit een smartcard of een beveiligde aanbieder mag verlaten, kies dan een combinatie van client en aanbieder die aan die eis uitdrukkelijk voldoet, of vraag bevestiging van de leverancier voor de versie die u hebt geïnstalleerd. Geen van beide takken is een omweg voor de andere.

De richtlijn weer aan het profiel toevoegen kan geen integratie leveren die de toepassing niet heeft. Een nieuwere clientversie voegt haar ook niet noodzakelijk toe, omdat de mogelijkheid bij het eigen ontwerp van de frontend hoort.

Zodra de lokale sleutel werkt, controleert de server nog steeds de identiteit van het certificaat, de keten en de autorisatie. Een bruikbare lokale sleutel en een geaccepteerde VPN-identiteit zijn afzonderlijke uitkomsten, en ze gescheiden houden is wat voorkomt dat een beperking van de frontend een verzwakt certificaatbeleid wordt.