Profil OpenVPN zawiera trzy bloki certyfikatów: który jest tajny?

Otwierasz plik .ovpn, aby zmienić jedną linię, i znajdujesz trzy bloki base64, które wszystkie wyglądają jak dane logowania. Jeden można bezpiecznie opublikować, drugi jest tak wrażliwy jak hasło, a trzeci to klucz publiczny, który nic nie znaczy, dopóki coś innego nie zostało podpisane jego parą. Ludzie wklejają cały plik w wątek pomocy, bo bloki wyglądają na wymienne, i tak klucz klienta trafia do publicznego archiwum. Rozróżnienie, który blok co robi, wyjaśnia większość zamieszania wokół tych profili i mówi też, które awarie masz naprawić sam.

Jeden plik, trzy bloki, różne zadania

Typowy profil osadza blok ca, blok cert i blok key między znacznikami BEGIN i END albo wskazuje te same trzy jako osobne pliki. Niektóre profile dodają czwarty blok dla klucza tls-auth lub tls-crypt, który jest wspólnym sekretem, a nie certyfikatem. Klient czyta każdy blok zgodnie z dyrektywą, która go nazywa, więc etykiety znaczą więcej niż kolejność występowania.

Traktuj złożony profil jako wrażliwy, dopóki naprawdę nie zajrzysz do środka. Publiczny certyfikat i klucz prywatny mogą leżeć kilka linii od siebie w tym samym pliku, a zrzut ekranu z nagłówkiem może zawierać oba. Ręczne zamazywanie widocznego base64 też jest zawodne, bo częściowy blok nadal ujawnia metadane certyfikatu nazywające twoje wdrożenie. Skopiowanie trzech dyrektyw bez ich wartości zwykle wystarcza, by zadać użyteczne pytanie.

Dyrektywy wokół bloków decydują, jak się ich używa. Zmień ca, a klient zaufa innemu organowi; zmień cert bez zmiany key, a uzgadnianie zawiedzie z niezgodnością, która nie ma nic wspólnego z zaufaniem.

Blok CA jest publiczny, klucz CA nigdy

Organ certyfikacji podpisuje certyfikaty wiążące klucz publiczny z tożsamością, a jego własny certyfikat jest kotwicą, na której klient opiera decyzję, czy łańcuch jest godny zaufania. Ten certyfikat jest publiczny z założenia: dołączanie go do każdego profilu jest normalne i właśnie dlatego wdrożenie z własnym podpisem może działać bez organu komercyjnego.

To, co nigdy nie może pojawić się w profilu klienta, to prywatny klucz podpisujący organu. Klient nie potrzebuje go do żadnej weryfikacji, a jego obecność oznacza, że każdy, kto ma profil, może tworzyć nowe tożsamości dla całego wdrożenia.

Zaufanie do organu jest też węższe, niż to brzmi. Klient, który akceptuje dowolny certyfikat podpisany przez CA, nadal zaakceptuje certyfikat wydany dla innej usługi w tej samej CA. Opcje przypinające oczekiwaną rolę lub nazwę serwera zamykają tę lukę, a Dokumentacja opcji TLS wymienia dyrektywy weryfikacji, które to robią.

Certyfikaty serwera i klienta wskazują przeciwne kierunki

Certyfikat serwera to ten, który klient sprawdza, aby potwierdzić, że dotarł do właściwego punktu końcowego. Twój certyfikat klienta działa w drugą stronę: serwer używa go, by stwierdzić, że to urządzenie lub użytkownik jest tym, którego zarejestrował. Ten sam format, przeciwny kierunek zaufania.

Adres nie jest tożsamością. Dotarcie do właściwego IP niczego nie dowodzi co do tego, kto odpowiedział, dlatego sprawdzanie nazwy hosta lub nazwy certyfikatu nadal należy do profilu. Hasło konta też nie zastępuje po cichu wymaganego certyfikatu klienta, bo oba są sprawdzane na różnych etapach, a wdrożenie może wymagać obu.

Klucz prywatny klienta to część, która musi pozostać prywatna. Jeśli mógł zostać ujawniony, usunięcie pliku z laptopa niczego nie zmienia na serwerze, który będzie nadal akceptować odpowiedni certyfikat, dopóki operator go nie unieważni. Poproszenie operatora o wymianę lub unieważnienie tej tożsamości to jedyne rozwiązanie, które podróżuje z tobą.

Dwa monity, które wyglądają identycznie i nie są

Klucz przechowywany w formie zaszyfrowanej prosi o frazę hasła, zanim klient będzie mógł go użyć. Usługa VPN może osobno poprosić o hasło konta, a oba monity mogą pojawić się w odstępie sekund z niemal tym samym sformułowaniem. Fraza hasła chroni plik na twoim dysku; hasło dowodzi konta przed serwerem. Mylenie ich wysyła ludzi do resetów hasła, które w żaden sposób nie mogą pomóc.

Przeczytaj monit, zanim cokolwiek zresetujesz. Reset hasła konta nic nie daje zapomnianej frazie hasła klucza, unieważnionemu lub wygasłemu certyfikatowi, a reset hasła, gdy awarią jest walidacja certyfikatu, zamienia dwuminutową poprawkę w zgłoszenie do pomocy. Jeśli skarga wspomina daty ważności, sprawdź najpierw zegar urządzenia, a potem własne okno wskazanego certyfikatu.

Kiedy certyfikat naprawdę wygasł, zamiennik musi pochodzić od tego, kto go wydał. Klucz należący do kogoś innego nie jest drogą odnowienia, podobnie jak pożyczenie działającego profilu od kolegi.

Co dowodzi czyste uzgadnianie, a czego nie

Osiągnięcie zakończonego uzgadniania TLS oznacza, że skonfigurowana relacja tożsamości się utrzymała: certyfikat serwera połączył się z twoim CA, a twój certyfikat został zaakceptowany. Nie mówi to nic o polityce rejestrowania operatora ani o tym, czy twoje aplikacje będą działać po podniesieniu tunelu.

Trasy i DNS to późniejsze etapy połączenia, więc nieosiągalny host intranetu po udanym logowaniu to problem łączności, a nie certyfikatu. Pracuj nad tą warstwą zamiast wymieniać dane logowania, a przekazując profil komuś, trzymaj razem jego pochodzenie, materiał prywatny i kontrole tożsamości.