Który plik CA trafia do profilu OpenVPN z samym hasłem?

Przejdź przez cztery pytania po kolei, a okno CA przestanie być dwuznaczne. Jaki materiał operator faktycznie wydał, co profil już zawiera, które pole pyta i co dzieje się po wczytaniu pliku? Zatrzymaj się przy pierwszym pytaniu, na które nie umiesz odpowiedzieć na podstawie instrukcji samego operatora, bo zgadywanie dalej to właśnie droga, na której publiczny certyfikat CA trafia w parę z kluczem prywatnym, który nigdy nie powinien opuścić serwera.

Kolejność ma znaczenie: ostatnie dwa pytania mają sens dopiero wtedy, gdy wiesz, jaki materiał powinien istnieć.

Zacznij od tego, co profil już zawiera

Otwórz profil w edytorze tekstu i poszukaj bloku ca, zanim zaczniesz szukać pliku. Wbudowany blok ca z publicznym CA operatora oznacza, że profil jest samowystarczalny, a klient, który nadal prosi o plik CA, może czytać inny profil albo niepełny import. Jeśli profil ma zamiast tego linię ca wskazującą ścieżkę, ścieżka ta jest w niektórych integracjach względna wobec katalogu roboczego klienta, a w innych bezwzględna. Zanotuj, którą formę masz, zanim cokolwiek zmienisz.

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

Sprawdź dostarczony pakiet pod kątem plików, do których odwołuje się profil: certyfikat CA, czasem osobny certyfikat klienta i klucz, a być może plik tls-auth lub tls-crypt. Profil odwołujący się do czterech plików, który przychodzi z dwoma, jest niekompletny i żadna ilość wskazywania pól tego nie naprawi. Poproś operatora o brakujący element, zamiast zastępować go certyfikatem, który akurat masz.

Rozdziel cztery rodzaje materiału

Certyfikat CA to materiał publiczny używany do weryfikacji tożsamości serwera. Certyfikat klienta identyfikuje użytkownika lub urządzenie wobec serwera. Klucz prywatny to tajna połowa tego certyfikatu klienta i nigdy nie może być kluczem podpisującym CA ani kluczem serwera. Materiał tls-auth lub tls-crypt to odrębny wspólny sekret chroniący kanał sterowania. Te cztery nie są wymienne, a skierowanie pola CA na certyfikat klienta daje błąd weryfikacji, który wygląda jak problem z zaufaniem.

Uwierzytelnianie tylko hasłem zmienia to, którego z czterech potrzebujesz, a nie co one oznaczają. Z auth-user-pass i remote-cert-tls server klient nadal weryfikuje serwer wobec CA, dlatego pole CA pojawia się nawet wtedy, gdy nie ma certyfikatu klienta. O tym, czy certyfikat klienta też jest wymagany, decyduje polityka operatora, i żadne okno dialogowe nie może ci tego powiedzieć.

Skieruj klienta na plik zaufania

Wybierz sam plik certyfikatu CA, nie folder, który go zawiera, i nie pakiet .p12 zawierający tożsamość klienta. W Windows składnia ścieżek i selektor plików zachowują się inaczej niż w przykładach linuksowych w większości poradników, więc używaj tego, co akceptuje zainstalowany klient, i potwierdź, że plik jest czytelny dla konta, które go uruchamia. Problem z uprawnieniami i brakujący plik wyglądają w oknie tak samo, ale dają różne linie dziennika. Po wybraniu otwórz ponownie ustawienia profilu, aby potwierdzić, że klient zachował wybór.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

Jeśli klient obsługuje bloki wbudowane, preferuj wbudowany profil operatora zamiast składanego ręcznie. Materiał wbudowany podróżuje z profilem i przetrwa ponowny import, natomiast ścieżka bezwzględna psuje się w chwili przeniesienia profilu na inną maszynę.

Czytaj następny błąd, a nie ten sam

Celem dostarczenia właściwego CA jest zmiana błędu, a nie sprawienie, by zniknął. Błąd tożsamości serwera po wczytaniu CA oznacza, że certyfikat nie pasował do oczekiwanej nazwy ani do oczekiwania remote-cert-tls, co jest inną naprawą niż odrzucenie hasła. Odrzucenie hasła oznacza, że warstwa TLS się powiodła, a dane logowania są błędne. Zachowaj pierwszy nowy komunikat; to on jest użyteczny.

Klient, który się łączy, ale nigdzie nie dociera, minął zaufanie całkowicie i staje teraz przed pytaniem o routing lub DNS.

Nigdy nie wyłączaj weryfikacji, aby przejść przez to okno. Klient, który akceptuje dowolny certyfikat, nie ma powodu prosić o CA, a tunel, który buduje, nie jest tym, który miał na myśli operator.