Samopodpisany certyfikat klienta? Serwer VPN nadal go odrzuca

Operator wysyła adres i nazwę użytkownika, a klient prosi o plik CA, certyfikat i klucz. Wygenerowanie tych trzech lokalnie wydaje się oczywistym następnym krokiem. Powstaje certyfikat, w który wierzy tylko twoja maszyna. Zaufanie serwera jest zakotwiczone w CA, której nie kontrolujesz, więc uścisk dłoni kończy się, zanim się zacznie.

Zaufanie mieszka na serwerze, nie w twoim profilu

Uwierzytelnianie certyfikatem to porównanie. Klient przedstawia certyfikat; brama sprawdza, czy podpisał go jeden z CA w jej konfiguracji.

Twój profil wskazuje plik CA, którego klient ma używać do weryfikacji serwera. Nie może wskazać CA, której serwer ma używać do weryfikacji ciebie. Ta połowa konfiguracji nie jest twoja.

Samodzielnie zrobiony certyfikat nie przechodzi tego porównania, nawet gdy jest technicznie doskonały. Ma ważny podpis, podmiot i daty, ale wystawcą jest CA, o której brama nigdy nie słyszała. Błąd pojawia się podczas uścisku dłoni, po tym jak serwer już poprosił o certyfikat. Nic w profilu klienta nie zmieni odpowiedzi.

Dlaczego samopodpisany certyfikat nie może go zastąpić

Samopodpisany certyfikat jest podpisany własnym kluczem. Podpis weryfikuje się wobec tego samego pliku, co czyni go spójnym wewnętrznie i bezużytecznym jako poświadczenie dla cudzej bramy.

Brama nie pyta, czy certyfikat jest wewnętrznie spójny. Pyta, czy podpisał go zaufany wystawca.

Dlatego komunikaty o błędach są mylące. Klient może zgłosić błąd weryfikacji, który brzmi jak problem serwera, podczas gdy serwer rejestruje nieznanego wystawcę. Oba opisują tę samą niezgodność z przeciwnych stron.

Ścieżka CSR zachowuje twój klucz prywatny

Większość pracy nadal możesz wykonać lokalnie. Wygeneruj parę kluczy, zbuduj żądanie podpisania certyfikatu wokół połowy publicznej i wyślij to żądanie do operatora. Z twojej maszyny wychodzi tylko żądanie. Połowa prywatna zostaje tam, gdzie ją wygenerowałeś.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

Operator podpisuje żądanie swoim CA i zwraca certyfikat. Twój klucz prywatny nigdy nie podróżował, a wynik prowadzi łańcuchowo do kotwicy, której ufa brama.

Usługi zarządzane często pomijają CSR i wydają cały pakiet. To rozsądna wymiana, gdy ten sam dostawca kończy tunel i ma CA. Przechowywanie klucza nie poprawia się przez trzymanie go, bo dostawca może w każdej chwili wykuć nowy.

Pakiety się importuje, nie instaluje

Pakiety dostawców o bezpiecznie brzmiących nazwach to często profile OpenVPN. Zawierają konfigurację i czasem certyfikaty, i niczego nie instalują. Zaimportuj plik do klienta mówiącego tym protokołem, a połączenie będzie skonfigurowane.

Zasada postępowania wynika z zawartości. Jeśli profil zawiera klucz prywatny, to poświadczenie i zasługuje na taką samą troskę jak hasło: żadnego e-maila, żadnego repozytorium, żadnego współdzielonego folderu pobierania. Gdy operator dostarcza ca.crt, client.crt i client.key osobno, przechowuj je razem z restrykcyjnymi uprawnieniami i wskaż na nie profil.

Dodaj sprawdzenia, które operator mógł pominąć

Profil wygenerowany przez router czasem nie ma weryfikacji peera. remote-cert-tls server wymaga, aby certyfikat peera miał przeznaczenie uwierzytelniania serwera, więc certyfikatu klienta nie można odtworzyć jako serwera. Ta jedna linia to mała zmiana z jasnym uzasadnieniem.

verify-x509-name idzie dalej, gdy operator może wskazać oczekiwany podmiot lub SAN. Oba są małymi dodatkami do profilu i oba są obronne. Sprawdź, co otrzymałeś, zanim to zaimportujesz.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Ustawienia weryfikacji nie są naprawą zerwanego łańcucha. Jeśli wystawca jest zły, odpowiedzią jest certyfikat od właściwej CA, a nie flaga wyłączająca sprawdzanie. Wyłączenie weryfikacji zamienia błąd uwierzytelniania w błąd niewykryty.

Poproś o jeden pakiet: certyfikat urzędu w formacie PEM, certyfikat klienta podpisany przez ten urząd, klucz, który wygenerowałeś lub który dotarł kanałem, któremu ufasz, oraz dokładną nazwę serwera, którą certyfikat ma przedstawić. Zapisz datę ważności w tej samej wiadomości, bo wygasły certyfikat wygląda jak awaria sieci miesiące później.