Ktoś unieważnił certyfikat w konsoli CA i teraz użytkownik nie może się połączyć. Pierwszy odruch to szukanie cofnięcia, a w większości PKI go nie ma: unieważnienie to stwierdzony fakt o numerze seryjnym, a wspierana droga powrotna to nowy certyfikat, nie odwrócony rekord. Przejdź przez poniższe kontrole po kolei, ponieważ dozwolona naprawa zależy od kodu przyczyny i od tego, czy klucz kiedykolwiek został ujawniony.

Zidentyfikuj certyfikat, nie osobę

Nazwy pospolite się powtarzają. Użytkownik, który ponownie zapisał się w poprzednim kwartale, może mieć dwa certyfikaty o tym samym CN i różnych numerach seryjnych, a unieważnienie jednego pozostawia drugi działający. Najpierw ustal dokładny obiekt:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

Zapisz numer seryjny, wystawcę, datę unieważnienia i przyczynę zapisaną w CRL. Następnie potwierdź, które urządzenia przedstawiają ten numer seryjny, ponieważ unieważniony certyfikat może nadal być zainstalowany na laptopie, telefonie i zapasowym routerze, a zamiana docierająca tylko do jednego z nich powoduje drugi incydent.

Szybka kontrola zachowania potwierdza stan bez zmieniania czegokolwiek:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

Jeśli zgłasza certyfikat jako unieważniony, CRL i klient są zgodne; jeśli weryfikuje się czysto, klient, którego trzymasz, nie jest unieważnionym, a poszukiwanie trwa dalej.

Sprawdź, czy CA użyła zawieszenia, czy trwałego unieważnienia

RFC 5280 definiuje certificateHold jako stan tymczasowy, a removeFromCRL jako sygnał, który go zwalnia. Ten cykl życia jest realny, ale nie jest to ogólny przycisk cofania. Odczytanie kodu przyczyny mówi, czy wystawca kiedykolwiek zamierzał wspierać zwolnienie.

Pułapką jest założenie, że tymczasowy zamiar oznacza tymczasowy zapis. Jeśli wpis w CA nosi keyCompromise lub cessationOfOperation, certyfikat jest trwale unieważniony, niezależnie od tego, co zamierzała osoba, która kliknęła przycisk. Odwrotnie, wpis oznaczony certificateHold w CA, która nie implementuje zwolnienia zawieszenia, jest trwały w praktyce, ponieważ nic nigdy nie opublikuje zwolnienia.

CA oparte na OpenSSL ilustrują granicę. Polecenie ca akceptuje wartości -crl_reason, w tym certificateHold i removeFromCRL, ale nie generuje deltowych CRL — dokumentacja OpenSSL CA wskazuje to ograniczenie dla swojego wyjścia CRL. Pełny CRL, który po prostu pomija numer seryjny, to inny model publikacji niż delta mówiąca "ten wpis jest zwolniony", więc wklejenie removeFromCRL do CA VPN opartej na OpenSSL nie daje zdefiniowanego w standardach zwolnienia.

Jeśli klucz mógł zostać ujawniony, wymień go

Unieważniony certyfikat to stwierdzenie, że temu kluczowi nie można już ufać. Jeśli unieważnienie było merytorycznie słuszne — laptop zgubiony, klucz skopiowany na dysk współdzielony, klucz prywatny wklejony do zgłoszenia — przywrócenie tego samego certyfikatu odwraca decyzję bezpieczeństwa, która działała zgodnie z przeznaczeniem.

Wystaw nową parę kluczy w procesie rejestracji, rozprowadź nowy profil i pozostaw stary numer seryjny unieważniony przez cały jego okres ważności. Zaktualizuj wszystko, co przypina tożsamość do numeru seryjnego lub odcisku palca, w tym listy dopuszczeń, inwentarze urządzeń i monitoring oczekujący konkretnego certyfikatu.

Argument wygody za przywróceniem starego jest realny, ale należy na niego odpowiedzieć wprost, a nie po cichu. "Użytkownik potrzebuje dostępu dziś" to powód, by przyspieszyć wystawienie, a nie powód, by cofnąć unieważnienie klucza, z którego nie możesz się rozliczyć.

Jeśli to był błąd administracyjny, wymień pod kontrolą

Gdy unieważnienie było po prostu błędne, a klucz nigdy nie został ujawniony, naprawa nadal jest kontrolowaną wymianą, a nie edycją. Użyj wspieranego procesu wystawcy, zachowaj numer seryjny i historię wystawiania nietknięte i unikaj dwóch kuszących skrótów: odwrócenia znaku stanu w index.txt z R z powrotem na V oraz usunięcia wiersza wystawienia, aby nowy certyfikat mógł ponownie użyć numeru seryjnego.

W CA OpenSSL baza danych jest rozdzielona tabulatorami i łatwo ją błędnie odczytać, co czyni ręczną edycję kuszącą:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

Czytaj ją, nie zapisuj. Edycja pliku zmienia następny CRL bez żadnego śladu audytowego, a każda druga instancja CA lub kopia zapasowa, która nadal ma oryginalny wiersz, później się z nim nie zgodzi.

Po wystawieniu zamiany opublikuj świeży CRL zwykłym mechanizmem i pozwól klientom go pobrać. Usunięcie CRL, skrócenie jego ważności do zera lub wyłączenie sprawdzania unieważnień w profilu klienta naprawia jednego użytkownika, osłabiając każde inne unieważnienie, jakie CA kiedykolwiek opublikowała.

Potwierdź nowe dopuszczenie i zachowaj zapis

Testuj nowym połączeniem, a nie sesją, która była już otwarta. Żywy tunel może nie powtórzyć kontroli dopuszczenia, które wykonuje nowy uścisk dłoni, a pamięci podręczne CRL sprawiają, że klient może łączyć się dalej, aż się odświeży. Rozłącz się, połącz ponownie i potwierdź w logu serwera, który numer seryjny został dopuszczony.

Zapisz, co się stało, dopóki jest to świeże: który numer seryjny unieważniono, przez kogo, z jakiej przyczyny, jaka zamiana została wystawiona i kiedy CRL opublikowano ponownie. Ten zapis umożliwia następny przegląd unieważnień i jest dowodem, że błąd został obsłużony, a nie ukryty.

W przyszłości przy krótkich zawieszeniach używaj mechanizmu pauzy dopuszczenia, jeśli wdrożenie go ma — konto wyłączone w warstwie tożsamości, usunięte członkostwo w grupie, wstrzymany profil klienta. To oddziela tymczasową decyzję polityki od pytania, czy wystawiony certyfikat jest nadal godny zaufania, i właśnie ta różnica przepadła za pierwszym razem.

Powiązane artykuły