OCSP kontra CRL: jak naprawdę działa każde sprawdzenie unieważnienia

Jedno z tych dwóch sprawdzeń unieważnienia zwraca podpisane świadectwo o jednym certyfikacie, a drugie zwraca podpisaną listę, którą pobierasz w całości. Oba mają powiedzieć weryfikatorowi, czy poświadczenie jest nadal zaufane, i oba zawodzą w sposób, który wcale nie przypomina siebie nawzajem. Poniższa kolejność odpowiada temu, z czym operator naprawdę styka się w produkcji: od bajtów w sieci po bramę, która odmawia połączenia. Pominięcie kroku to właśnie droga do wdrożenia z polityką unieważniania istniejącą tylko na papierze.

Krok 1: Co zwraca każde sprawdzenie i jak długo pozostaje użyteczne

CRL jest publikowana jako jeden podpisany obiekt obejmujący każdy certyfikat unieważniony przez wystawcę, więc weryfikator pobiera ją raz i używa ponownie, dopóki nie minie nextUpdate listy. Odpowiedź OCSP jest węższa: odpowiada dokładnie o jednym certyfikacie i niesie thisUpdate, producedAt oraz zwykle także nextUpdate. Ta różnica rządzi wszystkim innym. Zbuforowana CRL starzeje się po cichu, bo plik wciąż się parsuje, a jego podpis wciąż weryfikuje, podczas gdy wygasła odpowiedź OCSP jest oczywiście bezwartościowa w chwili, gdy odczytasz jej znaczniki czasu.

Dlatego buforowanie jest pierwszą rzeczą do ustalenia: który komponent trzyma kopię i jakiemu pułapowi ta kopia podlega. Na bramie pułapem powinien być nextUpdate minus margines bezpieczeństwa, nigdy to, co przypadkiem sugeruje nagłówek pamięci podręcznej HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate wypisuje obie daty, a listę, której nextUpdate już minął, trzeba traktować jako brakującą, a nie tylko jako starą.

Krok 2: Dokąd certyfikat kieruje klienta

Certyfikat liścia zwykle niesie dwie wskazówki: rozszerzenie punktu dystrybucji CRL oraz wpis dostępu do informacji urzędu dla OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints wypisuje pierwszą, a druga znajduje się w sekcji AIA wyniku openssl x509 -in client.pem -noout -text. Każde z tych rozszerzeń jest wskazówką, nie obowiązkiem. Klient, który nigdy nie implementuje sprawdzania unieważnienia, połączy się całkiem dobrze z certyfikatem, którego rozszerzenia wskazują respondera martwego od roku.

Punkty dystrybucji często wskazują wewnętrzny host, który rozwiązuje się tylko w jednym segmencie sieci, a niektórzy starsi klienci odrzucają adresy URL ldap wprost. Osiągalność testuj z hosta, który kończy tunel, nie z własnego laptopa, bo to jedyny punkt widzenia, którego awaria naprawdę ma znaczenie.

Krok 3: Wybierz fail-closed albo fail-open przed awarią

Nieosiągalny responder lub wygasła lista wymusza decyzję: odrzucić połączenie albo je przyjąć i odnotować lukę. Podkomenda verify w OpenSSL czyni ścisły wybór jawnym, bo dodanie -crl_check zamienia niedostępną CRL w unable to get certificate CRL i nieudaną weryfikację. Miękka awaria w większości stosów nie jest żadną flagą, to brak sprawdzenia, i właśnie dlatego trafia do produkcji przez przypadek.

Aby zobaczyć, jakie zachowanie klient naprawdę ma, usuń respondera i połącz się ponownie. Jeśli tunel nadal wstaje, znajdź wiersz logu, który zapisał pominięte sprawdzenie, i zapytaj, czy ktoś przeczytałby ten wiersz podczas incydentu. Ten sam dostawca może różnić się zależnie od protokołu: klient IKEv2 i klient OpenVPN na jednej maszynie czytają niepowiązane ustawienia konfiguracji.

Krok 4: Udowodnij, że sprawdzenie działa tam, gdzie dopuszczany jest ruch

Znajdź proces, który kończy lub autoryzuje połączenie, i zapytaj go o wiersz konfiguracji włączający sprawdzanie unieważnienia. Brama, która waliduje łańcuch, ale nigdy nie pyta o unieważnienie, stosuje inną politykę niż ta w twojej dokumentacji, i żaden zrzut ekranu łańcucha certyfikatów tego nie obala. OpenVPN zapisuje tę opcję jako crl-verify; strongSwan trzyma wyszukiwania CRL i OCSP w konfiguracji CA, gdzie ustawia się crl_uris lub ocsp_uris. Jeśli nie możesz wskazać żadnego z nich, przyjmij, że sprawdzenia nie ma.

Odpowiedź OCSP liczy się tylko wtedy, gdy podpisała ją CA wystawiająca, albo gdy podpisał ją responder mający delegowane przez tę CA rozszerzone użycie klucza OCSPSigning, więc odpowiedź niepowiązanej usługi niczego nie dowodzi. Jeśli sam prowadzisz respondera, monitoruj go jako twardą zależność, bo jedna martwa usługa naraz staje się awarią dla każdego klienta fail-closed.

Krok 5: Unieważnij jeden certyfikat celowo

Weź certyfikat testowy, unieważnij go tym samym kanałem, którego używa produkcja, i zapytaj respondera bezpośrednio. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text powinien zgłosić Cert Status: revoked wraz z czasem unieważnienia, a odpowiedź good oznacza, że twoje unieważnienie nie dotarło do respondera, o który pytają twoi klienci. Następnie uruchom openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem, aby zobaczyć tę samą decyzję ścieżką listy. Czytaj ciąg przyczyny, a nie kod wyjścia, bo odrzucenie z powodu unieważnienia i błąd łańcucha kończą się tak samo niepowodzeniem.

Krok, który naprawdę ma znaczenie, jest ostatni: połącz się ponownie ze starym profilem wobec rzeczywistego punktu egzekwowania i potwierdź, że odmowa pochodzi z unieważnienia. Potem połącz się ponownie ze świeżym, ważnym certyfikatem, aby dowieść, że nie zepsułeś tylko nasłuchującego. Usunięcie profilu na kliencie niczego nie dowodzi o decyzji serwera, podobnie jak udane uruchomienie openssl verify na maszynie, która nigdy nie kończy tunelu. RFC 6960 określa, co zawiera zgodna odpowiedź OCSP, w tym wartości statusu, które odczytuje ten test.