Certyfikaty – czas na zmiany, cz. II

Opublikowano: 30 sierpnia 2007
Autor: Barbara Wróbel

Zawartość strony

	OCSP (ang. Online Certificate Status Protocol)
	Zarządzanie i diagnostyka
	Podsumowanie
	Przeczytaj pozostałe części tego artykułu

OCSP (ang. Online Certificate Status Protocol)

Certyfikat, by mógł być w pełni wiarygodny, musi spełniać kilka warunków. Jednym z nich jest ten, by był nadal certyfikatem ważnym. Dotychczas, w celu sprawdzenia tego, głównie posługiwano się w Windows Server 2003 tzw. CRL, czyli Certificate Revocation List. Była to publikowana przez urząd certyfikacji lista zawierająca spis wszystkich tych certyfikatów, które z różnych przyczyn zostały odwołane, a co za tym idzie nie są już ważne. Lista ta w przypadku dużych urzędów certyfikacji mogła osiągać znaczne rozmiary. Pewnym pomysłem, by dało się w miarę rozsądnie transmitować takie listy nawet przy wolniejszych łączach, było wprowadzenie tzw. delta CRL, czyli list różnicowych zawierających tylko dodane ostatnio odwołane certyfikaty. W Windows Server 2008, by usprawnić cały proces jeszcze bardziej, wprowadzono wbudowane wsparcie dla mechanizmu o nazwie Online Certificate Status Protocol, czyli w skrócie OCSP. Umożliwia on indywidualne sprawdzanie ważności pojedynczego certyfikatu, bez konieczności ściągania zbędnych danych o innych odwołanych certyfikatach. Redukuje tym samym ruch w sieci.

OCSP jest funkcjonalnością opcjonalną i jej włączenie wymaga wykonania paru kroków konfiguracyjnych (oczywiście po uprzednim zainstalowaniu OCSP jako jednego ze składników roli serwera certyfikatów). Prześledźmy je może na przykładzie wersji Enterprise urzędu certyfikacji.

Po pierwsze, po wejściu we właściwości urzędu na zakładce „Extensions” zaznaczmy opcje „Include in the AIA extension of issue certificates” oraz „Include in the online certificate status protocol (OCSP) extension”. Opcje te występują w odniesieniu do wybranego powyżej rozszerzenia AIA i lokalizacji określonej z użyciem protokołu http.

Rys. 1. Karta właściwości urzędu.

Następnie na podstawie szablonu „OCSP Response Signing” w wersji 3 wygenerujemy certyfikat dla serwera certyfikatów.

Ostatnim etapem jest dodanie nowej konfiguracji w przystawce zarządzającej „Online Responder” w gałęzi „Revocation Configuration”. Po kliknięciu w tę gałąź prawym przyciskiem i wybraniu „Add Revocation Configuration” pojawi się kreator. Przeprowadzi nas przez cały proces, w czasie którego będziemy musieli wskazać certyfikat CA, certyfikat OCSP Response Signing oraz tzw. dostawcę (ang. provider). Ostatni element, czyli dostawca, określi położenie listy CRL jak i list delta CRL, z których Online Responder będzie czerpał dane.

Jak widać, proces OCSP Response Signing pomimo, że wprowadza nowy mechanizm sprawdzania odwołanych certyfikatów, to jednak ciągle w pewien sposób bazuje na dotychczasowych listach CRL. Listy te jednak nie są już bezpośrednio w całości przesyłane klientowi, lecz OCSP odpowiada za udostępnianie konkretnych odpowiedzi z nich uzyskanych. Dodatkowo, aby przyspieszyć działanie OCSP, odpowiedzi uzyskane z list są buforowane (za co odpowiedzialny jest moduł Online Responder Web Proxy Cache).

Dokładny opis całej konfiguracji wspomnianej powyżej można znaleźć na stronie:

http://technet2.microsoft.com/windowsserver2008/en/library/045d2a97-1bff-43bd-8dea-f2df7e270e1f1033.mspx?mfr=true

Poza tym, dla zapewnienia większej niezawodności całego mechanizmu można jeszcze skorzystać z funkcjonalności o nazwie Online Responder Array. W ramach tego możemy stworzyć pewnego rodzaju grupy OCSP składające się na przykład z kilku serwerów. Dokładnie grupa taka może występować w następujących odmianach:

• jeden serwer OCSP obsługujący kilka urzędów certyfikacji;
• kilka serwerów OCSP obsługujących jeden urząd certyfikacji – serwery te będą posiadać wspólną konfigurację, dlatego w przypadku awarii jednego z nich pozostałe nadal mogą odpowiadać na żądania sprawdzenia poprawności certyfikatu;
• kilka serwerów OCSP obsługujących kilka urzędów certyfikacji.

Wybór modelu oczywiście uzależniony jest od naszych potrzeb.

 Do początku strony

Zarządzanie i diagnostyka

Certyfikaty są na tyle specyficznym i newralgicznym - jeśli chodzi o bezpieczeństwo - zagadnieniem, iż wymagają szczególnej kontroli również w kwestii zarządzania nimi.

W Windows Server 2008 dokonano tego dzięki uściśleniu zakresu kompetencji przypisanych zarówno agentom rejestrowania jak i agentom zarządzania. Jeśli wejdziemy we właściwości serwera certyfikatów i przejdziemy do zakładki „Certificate Managers”, będziemy mogli określić certyfikatami na podstawie jakich szablonów może zarządzać dana osoba, jak i w odniesieniu do kogo. Oczywiście w tej zakładce będą dostępni do wyboru jako zarządzający tylko ci użytkownicy lub grupy, którym wcześniej nadano odpowiednie uprawnienia na zakładce „Security”.

Rys. 2. Zakładka „Certificate Managers”.

Analogicznie sytuacja przedstawia się na zakładce „Enrollment agents”, tyle że tu w odniesieniu oczywiście do czynności przypisanych tego typu agentom. W obu przypadkach uprawnienia mogą być nadawane w odniesieniu do konkretnych osób lub grup.

W zarządzaniu certyfikatami, a raczej w pewnym sensie monitoringu kluczowych dla całego urzędu certyfikacji elementów, może w Windows Server 2008 również pomóc przystawka o nazwie PKI Enterprise. Dzięki niej szybko można określić nie tylko strukturę naszych urzędów certyfikacji, ale również lokalizację i stan tak podstawowych rzeczy, jak certyfikat głównego urzędu certyfikacji czy też listy odwołanych certyfikatów (czyli CRL).

Rys. 3. Przystawka PKI Enterprise.

Czasami jednak nawet w najlepiej zarządzanym świecie mogą pojawić się problemy. By pomóc w ich rozwiązywaniu już w Viście wprowadzono mechanizm diagnostyczny CAPI2. Mechanizm ten śledzi działania dotyczące certyfikatów, a wyniki swej inspekcji zapisuje w dzienniku zdarzeń wykorzystując format XML. Aby móc z niego skorzystać należy go wcześniej uruchomić w dzienniku zdarzeń klikając prawym przyciskiem w gałęzi „Applications and Services Logs ->Microsoft->Windows->CAPI2”, a następnie wybierając „Enable log” lub włączając logowanie z linii komend poleceniem:

wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true

Logowanie domyślnie odbywa się na poziomie 2 i 4. W przypadku potrzeby jeszcze dokładniejszej diagnostyki można włączyć tzw. poziom verbose o numerze 5. W tym celu w gałęzi:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\crypt32

należy dodać odpowiednio klucze:

• klucz DiagLevel typu DWORD (32-bit) o wartości 0x00000005
• klucz DiagMatchAnyMask typu QWORD (64-bit) o wartości 0x00ffffff

Logowanie jest dość dokładne, więc raczej należy je włączać tylko na pewien okres czasu, ze względu na dość szybkie zapełnianie się logu.

 Do początku strony

Podsumowanie

Przedstawione powyżej elementy mechanizmu certyfikacji w Vista oraz Windows Server 2008 stanowią jedynie wycinek tego, co zostało zaimplementowane w obu produktach. Z punktu widzenia administratora również inne nowości związane z certyfikatami zasługiwałyby na pewno na uwagę, szczególnie te powiązane z zastosowaniem kart inteligentnych. Jest to jednak temat na tyle rozległy, iż na pewno warto poświęcić mu w przyszłości osobny artykuł.

 Do początku strony

Przeczytaj pozostałe części tego artykułu

• Certyfikaty – czas na zmiany, cz. I

Do początku strony