Przesiadka na plastik
Przed dwoma miesiącami (patrz: “$(LC153617:Stempel dla każdego)$”) pokazywałem, jak wydać “dokument tożsamości” dla użytkownika indywidualnego lub serwera i zapisać go na dysku twardym. Tym razem zajmiemy się certyfikatami przechowywanymi na karcie chipowej.
Nie wdając się w szczegóły, można powiedzieć, że jest to plastikowa karta wyposażona w pamięć, procesor i własne oprogramowanie. W pamięci zapisywane są: klucz prywatny i certyfikat, rolą procesora jest natomiast wykonywanie operacji kryptograficznych.
Co istotne, klucz prywatny nigdy nie opuszcza karty, a wszystkie operacje z jego wykorzystaniem są wykonywane właśnie wewnątrz karty. W efekcie poziom zabezpieczania operacji autoryzowanych z wykorzystaniem karty jest znacznie większy niż wtedy, gdy klucze prywatne składowane są na przykład na dyskach. Inną zaletą przechowywania certyfikatów i kluczy prywatnych na kartach inteligentnych jest ich przenośność.
Przenośne “paszporty” przydadzą się podczas rejestrowania się na komputerach w sieci lokalnej albo do uwierzytelniania listów wysyłanych z dowolnej maszyny.
Zanim jednak przystąpimy do zapisywania certyfikatu na “plastiku”, musimy poświęcić nieco czasu na zapoznanie się z bardziej rozbudowaną strukturą urzędów certyfikacji. Konieczne będzie bowiem uruchomienie tzw. korporacyjnego urzędu certyfikacji – tylko on oferuje funkcje pozwalające na wydawanie przenośnych “paszportów”.
Z góry na dół
W poprzednim artykule o wydawaniu certyfikatów wspominałem o tym, że możliwe jest tworzenie hierarchii jednostek certyfikujących. Najprostsza hierarchia składa się z jednego poziomu, w którym istnieje tylko urząd główny, poświadczający własną tożsamość i jednocześnie wydający “paszporty” użytkownikom końcowym. Sytuacja taka jest jednak stosunkowo rzadko spotykana. Dotyczy albo środowisk testowych, albo deweloperskich lub małych sieci, w których nie ma uzasadnienia (finansowego czy też technicznego) ustanawianie hierarchii urzędów. Gdy jednak mamy do czynienia z dużą liczbą użytkowników, którym zechcemy wydać certyfikaty, można pokusić się o zbudowanie kilku urzędów funkcjonujących w ramach jednej hierarchicznej struktury.
Zastanówmy się nad korzyściami płynącymi z istnienia hierarchii urzędów. Należy wymienić dwie zasadnicze: zapewnienie skalowalności oraz łatwość zarządzania. W pierwszym przypadku oznacza to, że w dowolnym momencie możemy rozbudować naszą infrastrukturę, dodając kolejną jednostkę certyfikującą. Kiedy zaś chodzi o łatwość zarządzania, wyobraźmy sobie sytuację, w której certyfikaty wydawane są do różnorakich celów, np. uwierzytelniania w sieci i do zabezpieczenia poczty elektronicznej. Jeżeli wspomniana sieć działa na dużym obszarze, to utrzymywanie tylko jednego punktu, który wydaje certyfikaty wszystkim użytkownikom, powoduje sporo kłopów. Wygodniejsze będzie uruchomienie wielu urzędów – zwłaszcza gdy zaistnieje konieczność wydawania innych certyfikatów dla osób pracujących w różnych miejscach.
Moja piramida
Zbudowanie kilkustopniowej hierarchii nie jest dużo bardziej skomplikowane niż instalacja i konfiguracja pojedynczego urzędu. Pierwszym krokiem jest zainstalowanie głównego urzędu certyfikacji. W trakcie takiej instalacji generowana jest para kluczy i tworzony certyfikat głównego urzędu. Zawiera on klucz publiczny podpisany własnym kluczem prywatnym.
Sama operacja instalacji urzędu jest dość prosta – sprowadza się do przejścia serii etapów opisywanych dokładnie przez kreatora i wybieraniu właściwych parametrów. Trzeba jednak ominąć kilka pułapek czyhających po drodze na administratorów. Pierwszą jest konieczność wcześniejszego przygotowania tekstowego pliku konfiguracyjnego o nazwie CAPolicy.inf. Zbiór ten musi przed instalacją znaleźć się w folderze
%WindowsRoot%
(czyli np.
C:\Windows
). Zapisane mogą być w nim różne parametry konfiguracyjne wykorzystywane przez wspomniany kreator (np. oświadczenie wydawcy, informacje o stosowanej polityce certyfikacji, miejscach, gdzie będą publikowane listy unieważnionych certyfikatów i informacji o urzędach, czy też długość życia certyfikatów odnawianych).
Plik CAPolicy.inf jest ważny choćby dlatego, że niektóre parametry usług certyfikacji mogą być skonfigurowane tylko za jego pomocą. Właściwie nie ma żadnych metod pozwalających zmienić ustawienia w późniejszym terminie. Zaznaczam więc, że w trakcie instalacji nie otrzymujemy żadnej informacji o tym, że plik jest niedostępny i zastosowane będą parametry domyślne. Poświęćmy zatem trochę czasu na zapoznanie się z dokumentacją i rzetelnie zaplanowanie całego procesu instalacji i konfiguracji.
Po uruchomieniu urzędu głównego można już budować urzędy podrzędne (albo i podrzędne w stosunku do tych podrzędnych). Operacja instalacji i konfiguracji usług certyfikacji jest bardzo podobna. Pierwsza różnica polega na tym, że w kreatorze instalacji wybieramy jedną z dwóch możliwych opcji:
Podrzędny urząd certyfikacji przedsiębiorstwa
lub Autonomiczny podrzędny urząd certyfikacji. Drugą różnicą jest to, że w trakcie instalacji generowane jest żądanie certyfikatu, które należy przekazać do nadrzędnego UC i zainstalować otrzymany tam certyfikat na komputerze, na jakim tworzymy właśnie podrzędny UC. Żądanie to może być przekazane automatycznie (jeżeli oba komputery działają w sieci) lub przeniesione na dowolnym nośniku (np. pendrive’ie).
Mimo że teoretycznie nie ma ograniczeń co do liczby poziomów w hierarchii certyfikacji, zaleca się, aby raczej nie było ich więcej niż trzy.
