Samopodpisany czy publiczny CA dla VPN: co naprawdę się zmienia

Trafiasz na stronę certyfikatów konfiguracji VPN, widzisz darmową opcję samopodpisaną obok płatnego publicznego CA, a pytanie brzmi jak wybór dotyczący bezpieczeństwa. W rzeczywistości to wybór publiczności. Obie opcje szyfrują tunel tymi samymi prymitywami i obie stają się bezwartościowe, jeśli klucz prywatny wycieknie. Oddziela je to, kto formułuje twierdzenie o tożsamości serwera i kto jest w stanie to twierdzenie sprawdzić.

Certyfikat wykonuje dwie prace, które bywają mylone

Certyfikat wiąże klucz publiczny z nazwą, a klucz wykonuje pracę szyfrowania i podpisywania. Podpis na certyfikacie jest osobnym oświadczeniem: jakaś władza sprawdziła, że nazwa należy do tego posiadacza klucza. Certyfikat samopodpisany składa to oświadczenie o sobie samym, co wcale nie jest twierdzeniem strony trzeciej.

Publiczne strony internetowe potrzebują wersji z stroną trzecią, ponieważ odwiedzający przychodzą bez wcześniejszej relacji i polegają na magazynie zaufania przeglądarki. Klient VPN nie jest obcy. Dajesz mu certyfikat CA albo przypinasz certyfikat serwera w profilu, który instaluje, więc weryfikacja przebiega dokładnie wobec wybranej przez ciebie władzy. Żaden komercyjny CA nie musi być zaangażowany, aby ta kontrola coś znaczyła.

Siła wynikowej sesji pochodzi z rozmiaru klucza i zestawu szyfrów, a nie od podpisującego. Dlatego nazywanie certyfikatu samopodpisanego "mniej zaszyfrowanym" jest po prostu błędne; jest mniej szeroko gwarantowany, co jest inną właściwością.

Gdzie publiczny CA zarabia na swoją opłatę

Najjaśniejszy przypadek to strona administracyjna. Jeśli współpracownicy, wykonawcy lub ktokolwiek bez przygotowanego profilu musi otworzyć interfejs webowy serwera VPN bez ostrzeżenia przeglądarki, publicznie zaufany certyfikat usuwa to tarcie. Przeglądarka już ufa podpisującemu, więc nie ma nic do zaimportowania i nic do wyjaśnienia.

Ta wygoda ma koszty, które warto wymienić przed zakupem. Odnawianie musi być zautomatyzowane, inaczej strona psuje się według harmonogramu, publiczne certyfikaty ujawniają nazwę hosta w dziennikach przejrzystości certyfikatów, a limity szybkości wydawania karzą skrypt, który zbyt gorliwie ponawia próbę. Żaden z nich nie jest powodem, by unikać publicznego CA, ale to praca operacyjna, którą prywatny CA przenosi gdzie indziej.

Czego publiczny certyfikat nie robi, to uwierzytelnianie twoich użytkowników. Tożsamość klienta to osobna decyzja, podejmowana za pomocą certyfikatów klienta, haseł lub drugiego czynnika, a CA podpisujący serwer nie mówi nic o tym, kto może się z nim połączyć.

Gdzie prywatny CA pasuje do VPN

Dla prywatnego VPN ze znanym zestawem klientów prowadzenie własnego CA jest konwencjonalnym wyborem. Tworzysz CA raz, podpisujesz certyfikat serwera nazwą, której będą używać klienci, i rozprowadzasz certyfikat CA w każdym profilu. Każdy klient weryfikuje wtedy serwer wobec twojej władzy, a żadna strona zewnętrzna nie poznaje nazwy hosta.

Koszty są realne, ale ograniczone. Przeglądarki będą ostrzegać, gdy ktoś otworzy stronę administracyjną bezpośrednio, ponieważ przeglądarka nie ma powodu ufać twojemu CA. Dystrybucja profili staje się częścią wdrażania, a rotacja CA oznacza dotknięcie każdego klienta. To akceptowalne ceny dla usługi z dziesięcioma lub pięćdziesięcioma znanymi użytkownikami i bolesne dla publicznego punktu końcowego z tysiącami.

Jeden warunek czyni cały układ ważnym: weryfikacja musi nastąpić. Klient skonfigurowany do ignorowania błędów certyfikatu akceptuje dowolny serwer prezentujący dowolny certyfikat, więc gwarancja tożsamości znika, podczas gdy szyfrowanie pozostaje. To ustawienie jest prawdziwą słabością w większości historii o tym, że "samopodpisany jest niebezpieczny".

Prywatny klucz CA decyduje, co możesz zrobić później

Niespodzianka zwykle przychodzi miesiące później, gdy chcesz dodać urządzenie. Wydanie certyfikatu klienta wymaga prywatnego klucza CA, podobnie jak utworzenie listy unieważnień. Jeśli odziedziczyłeś serwer, który ma pliki certyfikatu i klucza, ale nie ma klucza CA, nie możesz niczego nowego podpisać. Twoje opcje to odbudowa PKI i danie każdemu klientowi nowego certyfikatu CA albo przejście na uwierzytelnianie hasłem, które jest innym modelem bezpieczeństwa i nie przywraca utraconego.

Dwie mniejsze pułapki żyją na tym samym terytorium. Skrypty easy-rsa zakładają, że stoisz w katalogu, który je zawiera, więc błąd brakującego pliku zwykle oznacza złe miejsce, a nie uszkodzoną instalację. A projekt wyłącznie z certyfikatami jest całkowicie legalny: możesz wymagać certyfikatów klienta bez wcześniej współdzielonego klucza, pod warunkiem że każdy klient ma jeden, a serwer weryfikuje łańcuch.

Wydawaj jeden certyfikat na urządzenie, a nie jeden wspólny certyfikat klienta dla całego zespołu. Zgubiony laptop kosztuje cię wtedy jedno unieważnienie zamiast ponownego wydania dla wszystkich.

Sprawdź, co odziedziczyłeś

Przed zaplanowaniem jakiejkolwiek zmiany przeczytaj certyfikat, który już masz:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

Jeśli wystawca jest równy podmiotowi, certyfikat jest samopodpisany, co jest wyborem projektowym, a nie wadą. Daty mówią, kiedy odnowienie stanie się czyimś problemem, a udana weryfikacja wobec CA, który zamierzasz wdrożyć, potwierdza, że łańcuch działa, zanim jeden klient go wypróbuje.

Następnie wybierz według publiczności i dystrybucji: publiczny CA, gdy nieznane przeglądarki muszą zaufać stronie administracyjnej, prywatny CA, gdy każdy klient otrzymuje profil, który kontrolujesz. Żadna z odpowiedzi nie jest bardziej zaszyfrowana niż druga.