Użyj istniejącego CA przedsiębiorstwa dla partnerów OpenVPN

Nic w OpenVPN nie wymaga, aby certyfikat pochodził z Easy-RSA, a flota, która ma już organizacyjne PKI, zwykle nie powinna budować drugiego. Prawdziwa praca nie polega na wyborze narzędzia, lecz na zdecydowaniu, co znaczą wydane tożsamości, których partnerów akceptuje tunel i jak odnowienie oraz unieważnienie docierają do weryfikatora. Przejdź przez pięć kroków poniżej w kolejności, ponieważ późniejszy krok nie naprawi decyzji o roli podjętej w pierwszym.

Wydaj dwie role zamiast jednej wspólnej tożsamości

Każdy partner potrzebuje własnego certyfikatu i pasującego klucza prywatnego. Poproś zespół PKI o tożsamość serwera z użyciem serwera i osobne tożsamości klientów z użyciem klienta, aby tunel mógł je rozróżnić podczas uzgadniania połączenia.

Oprzyj się skrótom, które pojawiają się pod presją terminów. Skopiowanie klucza serwera internetowego na laptopy usuwa rozróżnienie, na którym opiera się sprawdzanie roli, a klucz podpisywania CA zainstalowany na punkcie końcowym VPN zamienia jeden przejęty host w przejętą hierarchię. Pakiet PKCS12 może przenosić klucz punktu końcowego i jego łańcuch, ale nigdy nie daje pozwolenia na ponowne użycie tej tożsamości w innej roli.

Podłącz wejścia zaufania po każdej stronie

Klient i serwer potrzebują każdy swojej kotwicy zaufania, własnej tożsamości i wyraźnego oczekiwania co do roli. Fragment klienta, który wymienia wszystkie trzy, wygląda tak.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

Strona serwera odzwierciedla to za pomocą remote-cert-tls client i własnego certyfikatu, i właśnie to uniemożliwia przyjęcie certyfikatu klienta jako serwera. Sprawdzenie nazwy to decyzja odrębna od sprawdzenia roli. Przeczytaj wdrożoną konfigurację, aby zobaczyć, które pole jest porównywane, zamiast zakładać dopasowanie nazwy hosta w stylu przeglądarki. Obie strony powinny też jasno określać, któremu wystawcy ufają, ponieważ wspólna ścieżka pliku w całej flocie nie jest tym samym co wspólna polityka.

Dostarczaj certyfikaty pośrednie bez rozszerzania zaufania

Obie strony nie muszą dzielić jednego łańcucha wystawiania. Gdy partner przedstawia certyfikat podpisany przez certyfikat pośredni, strona weryfikująca potrzebuje tego pośredniego dostępnego, i OpenVPN rozróżnia wejście kotwicy zaufania od dodatkowych certyfikatów używanych do uzupełnienia lokalnie przedstawionego łańcucha. Dokumentacja opcji TLS OpenVPN 2.6 opisuje oba.

Pośredni CA sam w sobie nie jest problemem, ale szeroki korzeń przedsiębiorstwa wrzucony do pakietu zaufania już jest. Im szersza kotwica, tym więcej certyfikatów przechodzi test łańcucha, a sprawdzanie roli nie zamienia tego w listę upoważnionych pracowników. Zawęź kotwicę do wystawcy, który faktycznie podpisuje tożsamości VPN, tam gdzie hierarchia na to pozwala. Jeśli nie pozwala, udokumentuj szerszą kotwicę jako świadomie akceptowane ryzyko, zamiast pozostawiać je domyślnym.

Uzgodnij z zespołem PKI, jak odnowienie i unieważnienie docierają do weryfikatorów VPN, w tym którzy wystawcy mają znaczenie i kto publikuje listę. Punkt dystrybucji CRL osadzony w certyfikacie to instrukcja, a nie dowód, że coś go pobrało.

Zdecyduj, jak unieważnienie faktycznie dociera

crl-verify powoduje, że weryfikator konsultuje plik lub punkt końcowy, a taki układ potrzebuje właściciela i ścieżki odświeżania. Lista skopiowana raz podczas wdrożenia po cichu przestaje cię chronić przy pierwszym unieważnieniu certyfikatu.

Zapisz oczekiwany czas propagacji i przetestuj go certyfikatem, który jesteś gotów unieważnić. Jeśli listy nie można odświeżyć na hoście VPN, alternatywą jest krótszy okres ważności plus proces odnowienia, który naprawdę działa, a nie założenie, że unieważnienie działa, bo istnieje URL.

Udowodnij akceptację prawdziwym klientem

Podłącz klienta, który powinien zostać dopuszczony, i potwierdź w dzienniku wynegocjowane szczegóły certyfikatu. Następnie wypróbuj przypadki, które muszą zawieść: certyfikat klienta przedstawiony jako serwer, certyfikat od wystawcy spoza kotwicy zaufania i unieważniony certyfikat, jeśli masz jeden zapasowy.

Zapisz zaakceptowanego wystawcę, sprawdzenie roli i źródło unieważnienia obok profilu. Ten zapis jest tym, czego potrzebuje następny inżynier, gdy urządzenie, które działało w zeszłym miesiącu, przestaje się łączyć, i jest też dowodem, że CA przedsiębiorstwa jest używane w udokumentowanej granicy akceptacji, a nie jako składowisko zaufania ogólnego przeznaczenia.