Nowe logowania VPN zawodzą, choć certyfikaty są ważne: sprawdź CRL

Certyfikaty, którym zostały miesiące, i logowania, które zawodzą natychmiast, wskazują na dwa różne obiekty z dwoma różnymi zegarami. Serwer odrzuca połączenia, ponieważ lista unieważnionych certyfikatów, którą konsultuje, przekroczyła własną datę wygaśnięcia, a nie dlatego, że certyfikaty użytkowników stały się nieaktualne. Odnowienie certyfikatu użytkownika nic nie daje tej liście.

Rozdzielenie obu harmonogramów to cała diagnoza i zmienia ona to, jaki musi być sposób naprawy.

Dwa zegary, a tylko jeden z nich to certyfikat

Certyfikat niesie okno ważności. Lista unieważnień certyfikatów niesie własne okno, a do tego wystawcę i podpis, a weryfikatorzy odmawiają zaufania liście, której czas następnej aktualizacji już minął. Gdy tak się dzieje, klient przedstawia całkowicie ważny certyfikat, a serwer mimo to zrywa połączenie z komunikatem o liście. Użytkownicy czytają ten komunikat jako „certyfikat wygasł”, co kieruje wniosek o odnowienie w niewłaściwe miejsce.

Oba obiekty mają też różnych właścicieli: certyfikat pochodzi od CA, która go wystawiła, natomiast lista jest generowana zgodnie z harmonogramem przez tego, kto obsługuje tę CA. Użytkownik nie może jej odświeżyć, a ponowne wystawienie certyfikatów nie może jej przedłużyć.

Przeczytaj listę, którą usługa faktycznie ładuje

Zacznij od działającej konfiguracji, a nie od pliku, którego oczekujesz. Ścieżka crl-verify może być bezwzględna, względna wobec profilu albo kopią wbudowaną w obraz, a weryfikator czyta właśnie tę kopię. Sprawdź ją na miejscu za pomocą openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate i porównaj daty z zegarem serwera.

Następnie potwierdź, że plik jest rzeczywiście tym używanym: sprawdź jego podpis za pomocą openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, który zgłasza wynik weryfikacji, zamiast po cichu wypisywać pola. Lista podpisana przez inną CA albo nieaktualna kopia pozostawiona w drugim katalogu zawodzi dokładnie tak jak wygasła.

Generuj ponownie z bazy unieważnień, a nie od zera

Nowa lista musi pochodzić z bieżącej bazy unieważnień CA, przez zatwierdzony proces podpisywania. Wygenerowanie pustej listy albo ponowne wygenerowanie ze starej kopii zapasowej indeksu po cichu cofa unieważnienie każdej tożsamości dodanej od czasu tej kopii. To zamienia awarię logowania w regresję bezpieczeństwa i nikt tego nie zauważa, bo objaw znika.

Trzymaj krok generowania pod kontrolą wersji razem z resztą narzędzi CA, aby interwał i klucz podpisujący były udokumentowane, a nie zapamiętane. Wystarczy wpis w runbooku, który nazywa polecenie, podpisującego i cel publikacji. Wtedy każdy dyżurujący może wygenerować listę ponownie, nie zgadując, który plik indeksu jest miarodajny. Przechowuj numer seryjny listy i czas następnej aktualizacji razem z zapisem wdrożenia.

Wdrażaj tam, gdzie patrzy weryfikator

Skopiuj nową listę na ścieżkę, którą czyta usługa, ustaw własność i tryb tak, aby konto usługi mogło ją czytać, a inni nie, i przeładuj lub uruchom ponownie zgodnie z udokumentowanym zachowaniem. Jeśli demon buforuje listę przy starcie, zastąpienie pliku bez przeładowania nie zmienia niczego, co zauważy działający proces. Potwierdź znacznik czasu, który proces zgłasza po przeładowaniu.

Jeśli kilka usług weryfikuje klientów, wdróż u każdej z nich. Zaktualizowanie jednego punktu końcowego i pozostawienie drugiego ze starą kopią daje awarię, która pojawia się tylko u użytkowników trafiających na drugi. Prowadź krótką listę tych punktów w tym samym runbooku. Po wdrożeniu sprawdź zgłoszoną datę listy dla każdego z nich, zamiast zakładać, że kopia dotarła.

Uczyń następny termin widocznym, zanim minie

Dłuższy interwał publikacji obniża częstotliwość tego incydentu bez tworzenia procesu. Wybierz interwał z polityki operatora, a następnie ustaw alarm na polu następnej aktualizacji wdrożonej listy z wystarczającym wyprzedzeniem na ponowne wygenerowanie i wdrożenie. Alarmuj na wdrożonej kopii, a nie na hoście CA, ponieważ zawodzi właśnie wdrożona kopia.

Po wdrożeniu sprawdź oba kierunki: dozwolony użytkownik się łączy, a znana unieważniona tożsamość nadal zawodzi. Druga kontrola wychwytuje niepełne ponowne wygenerowanie i wymaga jednego polecenia wobec profilu testowego, który trzymasz dokładnie w tym celu.