Dodawanie klienta VPN bez przebudowy CA

Potrzebujesz jeszcze jednego certyfikatu dla jeszcze jednego laptopa, ale pierwszy poradnik w wynikach wyszukiwania zaczyna się od polecenia, które usuwa katalog PKI. To polecenie należy do pierwszego ustawienia, nie do rejestracji, a jego uruchomienie kosztuje CA, historię wydawania i każdy profil klienta, który ufał staremu wystawcy. Decyzja jest węższa: czy wystawca ma jeszcze użyteczny stan i czy nowe urządzenie pasuje do twojej polityki rejestracji? Trzy warunki to rozstrzygają, a tylko jeden uzasadnia przebudowę.

Co przebudowa naprawdę niszczy

Ponowna inicjalizacja PKI zastępuje katalog pustą strukturą: nowym kluczem i certyfikatem CA, pustą bazą wydawania i nowym licznikiem serii. Klienci nie podążają sami; ich profile przypinają starą CA, więc każde urządzenie musi się zarejestrować ponownie, a nieosiągalne ręcznie.

Cichszą stratą jest księgowość. Odwołanie zależy od wiedzy, jakie numery serii komu wydałeś. Wyczyść indeks i nadal możesz podpisywać, ale nie powiesz z pewnością, które z wydanych certyfikatów chciałeś odwołać. Katalog CA z certyfikatami bez odpowiadającego stanu wystawcy to kopia zapasowa przywracająca złą połowę systemu.

Kopiowanie prywatnego klucza CA obok działającego serwera to drugi skrót, którego warto odmówić: zamienia urząd podpisu, który powinien stać poza siecią, w kolejny plik na hoście z niezaufanym ruchem.

Pierwszy warunek: czy stan wystawcy jest jeszcze osiągalny?

Przed decyzją znajdź katalog, któremu serwer naprawdę ufa. Porównaj certyfikat, który serwer przedstawia jako CA, z tym w katalogu PKI po odcisku palca, nie po nazwie pliku:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

Jeśli odciski się zgadzają, rejestracja jest przyrostowa i niczego nie przebudowuj. Jeśli się różnią, podpisujesz CA, której serwer nie ufa: certyfikat instaluje się czysto i zawodzi przy uścisku, a ten błąd bywa godzinami błędnie diagnozowany jako usterka klienta.

Potem poszukaj stanu wydawania: pliku indeksu, licznika serii i pliku numeru CRL. Jeśli indeksu nie ma, a klucz przetrwał, możesz wydawać, ale dziedziczysz problem z zapisem odwołań. Zapisz to w rejestrze zmian, bo następne żądanie odwołania to ujawni.

Drugi warunek: kto trzyma nowy klucz prywatny?

To decyzja, którą odczuwają użytkownicy, więc podejmij ją wprost. Klucz wygenerowany na kliencie i przesłany jako żądanie trzyma prywatną połowę na urządzeniu od pierwszego polecenia, a administrator nigdy jej nie dotyka. Klucz wygenerowany na serwerze jest łatwiejszy dla urządzeń bez narzędzi, ale czyni administratora opiekunem każdego klucza i zwiększa skutki kompromitacji serwera.

Z Easy-RSA 3 wobec istniejącej CA import i podpisanie żądania to dwa polecenia:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

Wybierz typ certyfikatu świadomie. Żądanie podpisane jako certyfikat serwera zamiast klienta daje plik, który wygląda dobrze i jest odrzucany przez partnera, a komunikat błędu rzadko mówi dlaczego. Przy openssl ca ten sam wybór żyje w rozszerzeniach, które przekazujesz, nie w sekcji domyślnej.

Trzeci warunek: czy serwer potrzebuje więcej niż certyfikatu?

Dla zwykłego serwera OpenVPN z uwierzytelnianiem certyfikatem certyfikat jest samą rejestracją: nazwa wspólna staje się tożsamością klienta, a katalog, wypychana trasa czy adres statyczny zależą od tej nazwy. Dodaj certyfikat i zapomnij konfiguracji, tunel się połączy, ale potrzebne trasy się nie pojawią.

Platformy to zmieniają. OpenVPN Access Server prowadzi własną bazę użytkowników, więc podpisany certyfikat nie jest kontem; konto musi istnieć i być dozwolone. Inne bramy wiążą łańcuch tożsamości z grupą. Rejestracja jednego urządzenia zwykle dotyka dwóch systemów, a certyfikat jest tylko pierwszy.

Procedura przyrostowa i kiedy przebudowa jest właściwa

Kolejność dodająca jedno urządzenie bez szkód: potwierdź wystawcę po odcisku, zrób świeżą kopię katalogu PKI, zaimportuj i podpisz żądanie dla roli klienta, dostarcz certyfikat z łańcuchem zatwierdzonym kanałem, a potem zweryfikuj przed połączeniem użytkownika:

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

Linia przeznaczenia powinna pokazywać SSL client. Zakończ aktualizacją kopii CA po wydaniu, bo kopia sprzed zapisania nowej serii przywraca stan bez właśnie dodanego urządzenia.

Przebudowa jest właściwa w trzech przypadkach: klucz CA jest skompromitowany, stan wydawania został nieodwracalnie utracony albo świadomie zmieniasz algorytm klucza lub politykę certyfikatów. Wszystkie trzy to projekty z planem ponownej rejestracji każdego klienta, nie kroki w żądaniu dla jednego urządzenia. Jeśli nic nie zachodzi, rejestruj przyrostowo i zostaw wystawcę w spokoju.