Odwołany certyfikat VPN nadal się łączy? Sprawdź egzekwowanie CRL

Odwołałeś certyfikat, wygenerowałeś nową listę, a stary profil nadal zestawia tunel. Samo odwołanie nie jest zepsute: CRL to podpisane oświadczenie, że numer seryjny nie jest już ważny, i zmienia dostęp dopiero wtedy, gdy komponent kończący TLS ją wczyta, dla właściwego wystawcy, zanim podejmie decyzję o akceptacji. Właśnie tam leży większość takich przypadków, i dlatego odwołanie i odmowa to dwa różne fakty.

Przejdź przez pięć poniższych kontroli po kolei i zatrzymaj się na pierwszej, która nie zachodzi, ponieważ każda późniejsza zakłada prawdziwość wcześniejszych.

Sprawdź, który komponent podejmuje decyzję o akceptacji

Wskaż proces, który waliduje certyfikat klienta, bo tylko ten proces może egzekwować listę. Na serwerze OpenVPN to sam demon, skonfigurowany z crl-verify. W ocserv to wiersz crl w ocserv.conf. W strongSwan danymi wejściowymi są wczytane CRL-e wraz z strictcrlpolicy. Proxy lub urządzenie kończące TLS przed VPN może być prawdziwym weryfikatorem, a jeśli nim jest, demon za nim nigdy nie widzi certyfikatu klienta.

WireGuard należy do innej kategorii. Nie ma certyfikatów ani listy odwołań; peer jest dopuszczany przez swój klucz publiczny w konfiguracji, więc zakończenie dostępu oznacza usunięcie tego klucza. Jeśli szukasz CRL we wdrożeniu tylko z WireGuardem, tego mechanizmu tam nie ma.

Uważaj też na pułapkę po stronie klienta. Klient, który odmawia połączenia, bo nie lubi certyfikatu serwera, egzekwuje łańcuch serwera, a nie odwołuje własnych poświadczeń. Certyfikat użytkownika jest odwoływany tylko tam, gdzie ten certyfikat jest walidowany, a to prawie zawsze strona serwera.

Sprawdź, dla jakiego wystawcy podpisano listę

CRL jest ograniczona do jednego CA wystawiającego. Przy korzeniu i pośrednim certyfikaty liścia pochodzą od pośredniego, więc listą, która ma znaczenie, jest CRL pośredniego; lista korzenia nic nie mówi o tych liściach. Weryfikator wskazany na zły plik parsuje go ochoczo, nie znajduje pasującego wpisu i akceptuje wszystko.

Potwierdź dopasowanie, zanim dotkniesz demona. Wystawca na certyfikacie musi odpowiadać subjectowi listy:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Gdy oba pochodzą z tego samego CA, numer seryjny wydrukowany dla certyfikatu jest wartością, która musi pojawić się na liście. Jeśli się nie zgadzają, trzymasz niewłaściwą CRL lub jej niewłaściwą kopię.

Ważność należy do tej samej kontroli. nextUpdate w przeszłości czyni listę nieaktualną, a weryfikator, który zawodzi zamknięcie, odrzuci wtedy każdego klienta zamiast tylko odwołanego.

Sprawdź, czy numer seryjny jest w kopii wczytanej przez demona

Odwołanie zapisuje wpis w bazie CA, a ponowne wygenerowanie zapisuje nowy plik. Żadna z tych czynności nie dociera do działającego demona, który wczytał starą kopię przy starcie. Zrzuć listę i poszukaj numeru seryjnego:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Następnie sprawdź, jak twoja implementacja pobiera plik. OpenVPN czyta ścieżkę podaną do crl-verify raz przy starcie, więc nowa lista wymaga restartu lub sygnału restartu; ta sama opcja wskazana na katalog jest odczytywana ponownie przy każdym połączeniu, i dlatego istnieje tryb katalogu. strongSwan musi przeładować swoje poświadczenia, na przykład za pomocą swanctl --load-creds. To, że plik na dysku jest poprawny, i to, że weryfikator go używa, to dwa różne fakty.

Sprawdź politykę dla brakującej lub wygasłej listy

To decyzja, której wiele wdrożeń nigdy nie podejmuje wprost, i rozstrzyga, czy odwołanie cię chroni, czy zamyka wszystkich na zewnątrz. Fail-closed oznacza, że brak użytecznej informacji o odwołaniu skutkuje odrzuceniem; fail-open oznacza, że weryfikator działa dalej bez niej. strongSwan udostępnia wybór jako strictcrlpolicy. OpenVPN z crl-verify odmawia startu na pliku, którego nie potrafi odczytać ani sparsować, a wygasła lista objawia się jako błąd weryfikacji TLS dotyczący wygasłej CRL, a nie jako cicha akceptacja.

Niezależnie od wybranego kierunku automatyzacja liczy się bardziej niż wybór: zadanie, które regeneruje CRL przed nextUpdate, i alert, gdy wdrożona kopia się starzeje, powstrzymują obie polityki przed staniem się incydentem. Sprawdzanie online przez OCSP przenosi świeżość do respondera, ale obowiązuje ta sama zasada, bo weryfikator nieskonfigurowany do sprawdzania odpowiedzi niczego nie zmienia.

Sprawdź aktywną sesję, a potem kopie klucza

Odwołanie jest oceniane podczas walidacji certyfikatu, która odbywa się przy połączeniu i przy renegocjacji. Ustanowiona sesja działa dalej, aż wynegocjuje ponownie, a domyślnym ustawieniem OpenVPN jest raz na godzinę z reneg-sec 3600. Jeśli osoba musi teraz zniknąć z sieci, zakończ sesję obok publikacji listy, a potem potwierdź, że ponowne połączenie jest odrzucane.

Oddziel poświadczenie od jego kopii. Usunięcie profilu na jednym laptopie nie powstrzymuje innej kopii tego samego klucza prywatnego przed uwierzytelnieniem; to odwołanie czyni każdą kopię bezużyteczną, i tylko gdy wcześniejsze kontrole zachodzą. Daj urządzeniu zastępczemu własny certyfikat, aby jedno można było odwołać bez ruszania drugiego.

Zanim uznasz to za zakończone: komponent walidujący jest zidentyfikowany, wystawca listy zgadza się z wystawcą liścia, odwołany numer seryjny znajduje się w kopii, którą demon faktycznie wczytał, polityka dla brakujących lub wygasłych list jest świadoma i monitorowana, a aktywna sesja została zakończona, a nie przeczekana. Formaty stojące za tym wszystkim określa RFC 5280.