Dlaczego cryptoapicert nie działa w OpenVPN 3 i Connect w Windows

Kopiujesz działający profil OpenVPN 2 do nowszego klienta Windows, a certyfikat, który stary klient znajdował sam, nie jest już oferowany. Wiersz, który to umożliwiał, to selektor charakterystyczny dla Windows należący do klienta Community 2, a nowsza aplikacja to inny program z inną ścieżką poświadczeń. Profil jest niezmieniony poza tym jednym wierszem i właśnie to sprawia, że różnicę trudno zauważyć.

W tym raporcie mieszają się trzy warstwy: klient Community, biblioteka rdzeniowa i frontend, który ktoś zainstalował. Tylko jedna z nich kiedykolwiek rozumiała tę dyrektywę.

Co oznacza ta opcja tam, gdzie istnieje

W kliencie Community OpenVPN 2 w Windows cryptoapicert wskazuje certyfikat, który klient ma znaleźć w magazynie certyfikatów Windows, a nie w pliku. To wygoda charakterystyczna dla Windows i działa, ponieważ ten klient umie wyliczyć magazyn i przekazać uzyskany klucz swojemu stosowi TLS. Dyrektywa jest więc częścią języka konfiguracji tego klienta, a nie właściwością protokołu OpenVPN. Nic w formacie transmisji jej nie przenosi.

Skopiuj ten sam wiersz do innej aplikacji, a skopiowałeś słowo, które nowy program może przeanalizować, zignorować lub odrzucić. Dyrektywa nie jest cechą protokołu, a ta nie jest nawet cechą każdego klienta, który mówi OpenVPN.

Co zamiast tego udostępnia biblioteka rdzeniowa

OpenVPN 3 Core to biblioteka, którą osadzają inne aplikacje, i obsługuje poświadczenia zewnętrzne przez API, a nie przez wyszukiwanie w magazynie. Osadzająca aplikacja dostarcza łańcuch certyfikatów, a później prosi bibliotekę o podpisanie kluczem zewnętrznym, i biblioteka wywołuje w tym celu aplikację z powrotem. To ogólniejsza konstrukcja i oznacza, że to frontend decyduje, jacy dostawcy istnieją. We własnej obsłudze opcji biblioteki cryptoapicert pojawia się wśród dyrektyw, które nie są zaimplementowane, co jest spójne z tym podziałem odpowiedzialności.

Istnienie tych wywołań zwrotnych nie oznacza, że dana spakowana aplikacja wylicza osobisty magazyn bieżącego użytkownika, obsługuje konkretnego dostawcę kluczy lub potrafi dokończyć monit karty inteligentnej. To właściwości frontendu i każdą z nich musi udokumentować frontend.

Co zamiast tego robi frontend systemu Windows

OpenVPN Connect idzie inną drogą: operator importuje plik PKCS#12 zawierający certyfikat i jego klucz prywatny do magazynu OpenVPN Certificate Store utworzonego w tym celu, a następnie przypisuje certyfikat zewnętrzny do profilu. To świadomy krok importu, a nie automatyczne wykrycie tego, co akurat leży w magazynie osobistym. Rozróżnienie ma znaczenie, gdy ktoś zakłada, że certyfikat zainstalowany w innym celu po prostu pojawi się na liście klienta.

Import ma też konsekwencję dla polityki kluczy, ponieważ eksport klucza do pliku P12 jest dokładnie tym, czemu klucz nieeksportowalny ma zapobiegać. To kwestia polityki, a nie konfiguracji, i zasługuje na odpowiedź, zanim ktoś spróbuje importu.

Wybierz drogę zgodną z polityką klucza

Jeśli poświadczenie jest eksportowalne i polityka pozwala na udokumentowany import, użyj chronionego procesu rejestracji organizacji i trzymaj tymczasowy P12 oraz jego hasło poza logami i skryptami. Jeśli klucz nigdy nie może opuścić karty inteligentnej lub chronionego dostawcy, wybierz kombinację klienta i dostawcy, która wyraźnie wspiera to wymaganie, albo uzyskaj potwierdzenie od dostawcy dla zainstalowanej wersji. Żadna z gałęzi nie jest obejściem dla drugiej.

Dodanie dyrektywy z powrotem do profilu nie może zapewnić integracji, której aplikacja nie ma. Nowsza wersja klienta też niekoniecznie ją dodaje, ponieważ zdolność należy do własnej konstrukcji frontendu.

Gdy klucz lokalny działa, serwer nadal sprawdza tożsamość certyfikatu, łańcuch i autoryzację. Użyteczny klucz lokalny i zaakceptowana tożsamość VPN to odrębne wyniki, a trzymanie ich osobno jest tym, co nie pozwala ograniczeniu frontendu zmienić się w osłabioną politykę certyfikatów.