Alarm o wygaśnięciu się uruchamia, tunel nadal przepuszcza ruch, a nikt nie jest zgodny, czy data ma znaczenie. Ma, ale nie zawsze w momencie wydrukowanym na certyfikacie. Wygasły certyfikat zatrzymuje nowe uwierzytelnienia i zatrzymuje rewalidacje, które niektóre implementacje wykonują w ramach długiej sesji. Czy istniejący tunel umrze o północy, zależy od protokołu, klienta i ustawień ponownego negocjowania serwera. Zaplanuj odnowienie przed datą i zweryfikuj je nowym logowaniem, a nie sesją, która była już otwarta.

Ustal, który certyfikat naprawdę wygasa

Wdrożenie zawiera certyfikat liściowy serwera, dane uwierzytelniające klienta, jeden lub więcej certyfikatów pośrednich i kotwicę zaufania, i nie wygasają razem. Czytaj certyfikat nazwany w błędzie i łańcuch, z którym został przedstawiony, a nie pierwszy plik w katalogu profilu. Certyfikat liściowy serwera, który odnawia się czysto, nadal może zawieść, jeśli certyfikat pośredni nad nim wygasł. Zapisz podmiot, wystawcę, not-after i miejsce wdrożenia każdego pliku, zanim cokolwiek zmienisz.

Kotwica zaufania jest zwykle najdłużej żyjącym obiektem i najmniej prawdopodobną przyczyną.

Dlaczego aktywna sesja może przetrwać datę

Uwierzytelnienie następuje przy nawiązaniu połączenia, a niektóre protokoły później ponownie sprawdzają tożsamość. OpenVPN ponownie negocjuje kanał danych według timera, więc ponowne negocjowanie przedstawiające wygasły certyfikat kończy się niepowodzeniem, nawet jeśli tunel działa od godzin. Implementacje, które nigdy nie rewalidują, mogą nieść ustanowioną sesję poza datę wygaśnięcia, i dlatego «wciąż działa» nie jest dowodem. Żadne z tych zachowań nie jest czymś, na co można planować.

Traktuj datę jako termin nowych logowań, a żywotność sesji jako czas pożyczony.

Sprawdź zegar, zanim obwinisz certyfikat

Ważność jest oceniana względem zegara lokalnego, więc urządzenie z błędnym czasem zgłasza błąd ważności dla certyfikatu całkowicie aktualnego. Sprawdź klienta, serwer i każde urządzenie na ścieżce.

Zegar, który resetuje się przy rozruchu, wyjaśnia awarie pojawiające się dopiero po zaniku zasilania.

Odnów przez urząd, który go wydał

Zachowaj tożsamość, zamierzone przeznaczenie i zgodną konfigurację klucza. Jeśli odnowienie wprowadza nowego wystawcę lub przypięty certyfikat, klienci potrzebują skoordynowanej aktualizacji zaufania, a nie wymiany pliku na serwerze. Chroń klucze prywatne podczas wydawania i dystrybucji, ponieważ odnowiony certyfikat nie unieważnia skompromitowanego starego klucza. Reset hasła nie jest odnowieniem, cokolwiek mówi zgłoszenie.

Opublikuj nowy łańcuch w całości, ponieważ liść bez swojego pośredniego to połowa odnowienia, która działa tylko na maszynach, które już mają go w pamięci podręcznej.

Udowodnij to nowym logowaniem, zachowaj możliwość wycofania

Po wdrożeniu nawiąż nowe dozwolone połączenie z reprezentatywnego klienta i wypróbuj rzeczywistą aplikację. Sprawdź, czy łańcuch jest dostarczany tak, jak oczekują klienci, i czy wszelkie informacje o unieważnieniu są osiągalne. Zachowaj wycofanie, które nie zależy od zaufania do wygasłego materiału, aby móc wrócić do poprzedniego stanu bez osłabiania weryfikacji. Usuń przestarzałe pliki dopiero po zweryfikowaniu zamiennika.

Istniejące sesje mogą nadal odzwierciedlać wcześniejszy stan, więc niczego nie dowodzą w żadną stronę.

Kolejność, której używam tego dnia

Potwierdź wygasający obiekt i jego łańcuch, a następnie potwierdź zegary:

  • Który certyfikat wygasa i do którego łańcucha należy.
  • Czy każdy certyfikat pośredni jest wdrożony i opublikowany.
  • Zegary klienta i serwera zgadzają się w rozsądnym zakresie.
  • Nowe logowanie kończy się sukcesem z reprezentatywnego klienta.
  • Informacja o unieważnieniu jest osiągalna.
  • Istnieje wycofanie, które nie osłabia weryfikacji.

Potem odnów, wdróż pełny łańcuch, przetestuj nowym logowaniem i dopiero potem posprzątaj. Okresy ważności i zasady ich oceny są zdefiniowane w RFC 5280, a data nie jest niespodzianką, jeśli monitoring obserwował obiekt, który naprawdę wygasa.

Powiązane artykuły