Odnawianie certyfikatu VPN bez zmiany jego tożsamości

Odnowienie certyfikatu, które zmienia tożsamość, nie jest odnowieniem, to migracja w przebraniu zgłoszenia serwisowego. Klient weryfikuje nazwę, łańcuch i czasem konkretny klucz, a wszystkie trzy mogą się zmienić bez zmiany daty ważności. Przed zamówieniem zamiennika zapisz, co klient naprawdę sprawdza: nazwę hosta lub tożsamość peera, przeznaczenie certyfikatu, politykę kluczy i łańcuch wystawcy. Odnowienie jest rutynowe lub skoordynowane w zależności od tego, co z tych rzeczy zmienia zamiennik.

Trzy warunki decydują o kształcie odnowienia

Trzy warunki to: czy coś przypina liść, czy zmienia się łańcuch i kto jeszcze weryfikuje nazwę. Odpowiedz na nie po stronie klienta, a nie dla wygody CA, bo to klient zawodzi o trzeciej nad ranem.

Zacznij od sprawdzenia posiadanego certyfikatu. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName wypisuje podmiot, wystawcę, okno ważności i nazwy, dla których certyfikat jest naprawdę ważny. To ostatnie pole jest najważniejsze i najczęściej zakładane: wniosek o odnowienie, który pomija SAN, na którym polega klient, daje certyfikat technicznie ważny, ale funkcjonalnie błędny. Skopiuj listę SAN ze starego certyfikatu do wniosku, zamiast wpisywać ją ponownie z pamięci.

Warunek pierwszy: czy coś przypina liść

Jeśli klienci ufają utrzymywanemu CA i weryfikują nazwę, odnowienie liścia z nowym kluczem jest dla nich niewidoczne. Jeśli jakikolwiek klient przypina certyfikat liścia, jego odcisk palca lub klucz publiczny, zamiennik jest skoordynowaną zmianą z twardym przejściem, bo stare przypięcie nie może zweryfikować nowego certyfikatu.

Ustal, w którym przypadku jesteś, zanim cokolwiek zamówisz. Przypięcie, którego nikt nie udokumentował, nadal jest przypięciem, gdy się zepsuje.

Warunek drugi: porównaj przypięcia i łańcuch

Odcisk palca czyni przypięcie sprawdzalnym: openssl x509 -noout -fingerprint -sha256 -in server.crt na starym i nowym certyfikacie oraz openssl x509 -noout -pubkey do porównania kluczy publicznych. Jeśli konfiguracja klienta, profil mobilny lub magazyn zaufania urządzenia zawiera którąś z tych wartości, masz przypięcie. Mobilne profile VPN są częstą kryjówką, bo profil jest rozpowszechniany raz i nigdy więcej nie jest sprawdzany.

Jeśli zamiennik pochodzi z tego samego pośredniego i klient już go ma lub może pobrać, po stronie zaufania nic się nie zmienia. Nowy pośredni, inny wystawca lub łańcuch dostarczony w złej kolejności zamieniają odnowienie w zmianę zaufania, a awaria wygląda jak nieznany wystawca, a nie jak wygasły certyfikat.

Sprawdź łańcuch, który serwer naprawdę wysyła, za pomocą openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, i zweryfikuj go lokalnie za pomocą openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Zrobienie tego przed zmianą daje punkt odniesienia do późniejszego porównania.

Warunek trzeci: kto jeszcze weryfikuje nazwę

Koncentrator VPN, równoważnik obciążenia, sonda monitorująca, integracja RADIUS lub SAML oraz profil mobilny mogą każde trzymać własną kopię oczekiwanej nazwy lub kotwicy zaufania. Odnowienie to moment, w którym te kopie się rozchodzą, bo certyfikat się zmienia, a kopie nie.

Wymień każdego konsumenta przed zmianą i zdecyduj dla każdego, czy potrzebuje aktualizacji. Ten, o którym zapomnisz, jest tym, który cię powiadomi.

Jest też pułapka czasowa. Sprawdź początek ważności oraz wygaśnięcie, bo certyfikat przygotowany do późniejszej aktywacji jest odrzucany, jeśli zostanie zainstalowany zbyt wcześnie, a błąd wygląda jak problem z zegarem, a nie problem z przygotowaniem. openssl x509 -noout -dates na nowym pliku przed wdrożeniem to dwusekundowa kontrola. Utrzymuj też wspieraną ścieżkę odzyskiwania i znaną dobrą konfigurację, aby nieudane odnowienie można było cofnąć, przywracając poprzedni certyfikat i klucz.

Wdróż, zweryfikuj świeżym uwierzytelnieniem, a następnie wycofaj

Ustanowiony tunel odzwierciedla walidację, która miała miejsce przy jego budowie, więc może wyglądać zdrowo, podczas gdy każde nowe połączenie zawodzi. Przetestuj świeżym uwierzytelnieniem, używając rzeczywistej nazwy usługi, której używają klienci.

Dokończ kontrolę na poziomie aplikacji, na której zależy użytkownikowi, i potwierdź dostarczenie łańcucha z perspektywy klienta, a nie serwera. Nie tłum kontroli nazwy lub certyfikatu, aby przejście było ciche; to zamienia tymczasowy problem zgodności w trwały.

Wycofaj przestarzały materiał dopiero po zweryfikowaniu wdrożenia, a skompromitowany klucz traktuj jako zupełnie inny przypadek: samo odnowienie niczego nie unieważnia, więc dotknięta tożsamość potrzebuje procesu unieważniania i obsługi sesji wdrożenia. RFC 5280 definiuje zasady certyfikatów i walidacji ścieżki, na których to wszystko się opiera. Trzymaj rutynowe odnowienie liścia oddzielnie od wymiany CA, aby klienci nie byli proszeni o zaufanie nowemu wystawcy bez powodu.