Co się dzieje, gdy wymieniasz urząd certyfikacji VPN

Wymiana urzędu certyfikacji VPN nie jest podmianą pliku. W chwili, gdy nowa CA podpisuje swój pierwszy certyfikat, każdy walidator, który wciąż ufa tylko staremu, musi podjąć decyzję, a hosty, które nigdy nie otrzymają nowej kotwicy, nadal odrzucają dobrych partnerów. Widziałem, jak to się psuje w obu kierunkach: brama poznała nową CA, a klienci nie, więc nowe połączenia zawodziły, podczas gdy tunele już nawiązane zostawały i sprawiały, że awaria wyglądała jak problem z routingiem. Oto co się zmienia, w kolejności, w jakiej pojawiają się błędy.

Jedna wymiana, dwie osobne zmiany

Urząd certyfikacji to nazwa, klucz publiczny i klucz prywatny, który podpisuje. Walidatory nigdy nie ufają „CA” w abstrakcji. Ufają jednemu konkretnemu certyfikatowi, który już leży w magazynie zaufania, i akceptują wystawcę tylko wtedy, gdy łańcuch podpisów dotrze do tej zapisanej kopii. Wymiana CA zmienia więc dwie rzeczy, które zawodzą niezależnie: jakie kotwice są akceptowane i jakie tożsamości partnerów zostały pod nimi wydane.

Większość wdrożeń VPN waliduje w obu kierunkach. Klient uwierzytelnia certyfikat bramy, a brama certyfikat klienta. Rotacja, która odświeża tylko pakiet klienta, zostawia serwer odrzucający każdego klienta, który nadal przedstawia tożsamość starej CA, a odwrotna sytuacja jest równie częsta. Najpierw zinwentaryzuj punkty egzekwowania: magazyny zaufania klientów, plik ca bramy, dowolny proxy kończący TLS przed nią i sonda sprawdzająca punkt końcowy z zewnątrz.

Co sprawdza walidator, po kolei

Walidacja ścieżki wspina się od certyfikatu partnera przez wszelkie poświadczenia pośrednie, aż dotrze do zaufanej kotwicy. Na każdym kroku weryfikuje podpis, sprawdza, czy każdy certyfikat mieści się w swoim oknie ważności, i potwierdza, że podstawowe ograniczenia i przeznaczenie klucza pozwalają wystawcy podpisywać. Dopiero potem aplikacja patrzy na certyfikat liścia: nazwy alternatywne podmiotu muszą obejmować wywołaną nazwę, a rozszerzone przeznaczenie klucza musi pozwalać na uwierzytelnianie serwera lub klienta.

Aby powtórzyć ten przebieg offline, wskaż -CAfile dokładnie ten pakiet, który wdrożysz, a nie magazyn systemowy. Inaczej testujesz host, a nie zmianę:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

To polecenie działa tylko wobec zwykłego odbiornika TLS, jak strona administracyjna HTTPS bramy; kanał sterujący OpenVPN poprzedza TLS, więc s_client nie może zbadać uścisku dłoni tunelu.

Zasady budowy ścieżki stojące za tymi błędami są w RFC 5280 sekcja 6. Wyjaśniają awarie, które inaczej wyglądają arbitralnie: wygasłe poświadczenie pośrednie, o którym nikt nie pamiętał, certyfikat, którego przeznaczenie klucza zabrania podpisywania, albo ograniczenie nazwy wykluczające testowany host.

Dlaczego stary tunel nadal działa

TLS i OpenVPN utrzymują nawiązaną sesję przy życiu po zakończeniu uścisku dłoni. Nic nie waliduje ponownie certyfikatu partnera przy każdym pakiecie, więc klient połączony przed zmianą nadal przepuszcza ruch, dopóki nie wynegocjuje ponownie, nie połączy się albo tunel nie padnie. Właśnie ta luka sprawia, że wymiana CA może przez godzinę wyglądać dobrze, a potem zawieść w najgorszym momencie: laptop budzi się z uśpienia, mapowanie NAT wygasa, brama restartuje się.

Wznawianie sesji jeszcze rozciąga tę iluzję. Bilet sesji TLS pozwala klientowi wrócić bez ponownego wysyłania certyfikatów, a wznowienie pomija walidację ścieżki, bo pierwszy uścisk dłoni już ją wykonał. Uczciwym testem jest więc pełny uścisk dłoni w nowym procesie. Zrestartuj klienta zamiast ponownie łączyć tunel, a w profilu testowym rozważ wyłączenie biletów, aby ścieżka wznowienia nie mogła ukryć zerwanego łańcucha.

Warstwę klucza statycznego trzymaj osobno. tls-auth dodaje HMAC do kanału sterującego, tls-crypt szyfruje go i uwierzytelnia, a żaden z nich nie przenosi materiału certyfikatu, więc rotacja któregokolwiek jest osobną zmianą z własnym trybem awarii. Wdrożenia, które mylą oba, kończą z klientem, którego klucz statyczny jest w porządku, certyfikat przestarzały, a komunikat błędu nie wspomina żadnego z nich.

Pułapka ponownego użycia nazwy podmiotu

Kuszące jest ponowne użycie nazwy wyróżniającej poprzednika, aby nic poniżej nie musiało się zmieniać. To utrzymuje stabilną linię wystawcy w interfejsie i niszczy jedyny sygnał, którego potrzebujesz. Dwa certyfikaty o identycznych podmiotach i różnych kluczach nie da się odróżnić po nazwie, więc pakiet z obiema kotwicami daje walidatorowi dwóch kandydatów i żadnej reguły wyboru.

Budowa ścieżki może wtedy wybrać niewłaściwy, zgłosić „nie można pobrać certyfikatu lokalnego wystawcy”, gdy właściwa kotwica jest obecna, albo odnieść sukces na jednym hoście i zawieść na innym z tym samym pakietem, bo kolejność kandydatów była inna. Jeśli nazwę trzeba ponownie użyć, trzymaj obie kotwice w osobnych plikach podczas przejścia i ładuj je jawnie, a scal je dopiero gdy każdy partner przedstawi nowego wystawcę. W przeciwnym razie nadaj zamiennikowi odrębną nazwę wspólną — wystarczy sufiks generacji lub daty — aby logi i teksty błędów mówiły, pod jakim organem wydano zawodzącego partnera.

Rotacja, która nie kładzie sieci

Przy planowanej wymianie akceptuj obie kotwice przez ograniczone okno zamiast przełączać w jednym kroku. Wystaw nową CA i jej poświadczenia pośrednie, umieść nową kotwicę w pakiecie każdego walidatora obok starej, i dopiero potem zacznij wystawiać z niej certyfikaty partnerów. Partnerzy ze starymi tożsamościami walidują się względem starej kotwicy; nowi działają względem nowej.

Wykonane w tej kolejności, każdy krok jest odwracalny. Awaria, której unikasz, to jednoczesne przełączenie: klient, który przegapił aktualizację pakietu, spotyka bramę, która już wycofała starą kotwicę, uścisk dłoni umiera i żaden log nie mówi, która strona jest przestarzała.

Wycofuj w przeciwnym kierunku. Wystaw ponownie każdą tożsamość, która musi przetrwać, potwierdź, że każda przedstawia nowy łańcuch, a potem usuń starą kotwicę z pakietów. Wycofaj klucz prywatny starej CA z użycia, bo wystawca, który wciąż może podpisywać, oznacza, że rotacja nie jest skończona. Zachowaj certyfikaty i rejestry wydań do audytu. Utracony wystawca jest przywracany do tego samego zaufania; ujawnienie wymaga nowych tożsamości i żadnego powrotu do starej kotwicy.

Zweryfikuj wynik, nie listę plików

Plik zaufania w oczekiwanym katalogu dowodzi niewiele. Aplikacja może czytać inną ścieżkę, inny format albo kopię w pakiecie, który zastępuje aktualizacja. Sprawdź zachowanie na obu końcach, a nie istnienie pliku.

Potwierdź, że nowe połączenie z nową tożsamością się udaje, a następnie potwierdź, że tożsamość wydana przez wycofaną CA jest odrzucana. Ten drugi test jest tym, który ludzie pomijają, i jedynym, który pokazuje, że stary organ nie daje już dostępu. Tam, gdzie wdrożenie opiera się na CRL lub OCSP, sprawdź, czy punkty dystrybucji w nowych certyfikatach się rozwiązują i czy partnerzy pytający docierają do respondera.

Zakończ klientem, który nigdy się nie połączył: wyczyść stan jego profilu, połącz i odczytaj wynegocjowany łańcuch. Partner wznawiający sesję z pamięci podręcznej ochoczo zaraportuje, że migracja się udała, choć niczego nie zweryfikował.