Usługi certyfikatów Active Directory pozwalają firmie wystawiać własne certyfikaty wykorzystywane wewnętrznie, bez korzystania z zewnętrznego urzędu certyfikacji.

Na czym polega ta usługa

Usługa obejmuje skonfigurowanie roli usług certyfikatów Active Directory na Windows Server oraz wystawienie pierwszych certyfikatów.

Dla kogo ma sens

Usługa jest przydatna dla firm chcących wystawiać własne certyfikaty do wykorzystania wewnątrz infrastruktury.

Ile to trwa

Konfiguracja usług certyfikatów mieści się z reguły w standardowym czasie do 3 dni.

Warunki

Diagnoza wstępna i wycena są bezpłatne, a usługa objęta jest gwarancją do 12 miesięcy.

Warianty wdrożenia urzędu certyfikacji

AD CS (Active Directory Certificate Services) można skonfigurować na kilka sposobów, w zależności od tego, jak certyfikaty mają być wykorzystywane w firmie. Podstawowy podział to urząd certyfikacji przedsiębiorstwa (enterprise CA), zintegrowany z Active Directory, oraz urząd autonomiczny (standalone CA), działający niezależnie od domeny. Enterprise CA umożliwia automatyczne wystawianie certyfikatów na podstawie szablonów i zasad grupy, co sprawdza się przy większej liczbie stacji roboczych. Standalone CA wymaga ręcznego zatwierdzania wniosków o certyfikat, ale bywa wybierany tam, gdzie certyfikaty mają obsługiwać systemy spoza domeny, na przykład urządzenia sieciowe lub serwery w strefie zdemilitaryzowanej.

Drugi podział dotyczy roli w hierarchii: urząd główny (root CA), będący punktem zaufania dla całej struktury, oraz urząd podrzędny (subordinate CA lub issuing CA), który wystawia certyfikaty końcowym użytkownikom i urządzeniom, a sam podlega urzędowi głównemu. W większych środowiskach root CA bywa świadomie odłączany od sieci po wystawieniu certyfikatu dla urzędu podrzędnego, co ogranicza ryzyko kompromitacji klucza głównego. Wybór właściwego wariantu zależy od skali środowiska, liczby lokalizacji oraz tego, czy certyfikaty mają obsługiwać wyłącznie usługi wewnętrzne, czy również urządzenia i aplikacje komunikujące się na zewnątrz.

Błędy przy samodzielnej konfiguracji

Instalacja roli AD CS wygląda na prostą, dlatego część administratorów próbuje skonfigurować ją samodzielnie, kierując się wyłącznie kreatorem ról w Menedżerze serwera. Najczęstszy błąd to instalacja urzędu certyfikacji na kontrolerze domeny zamiast na osobnym serwerze — po awarii lub błędnej konfiguracji trudno wtedy odseparować problem z certyfikatami od problemów z samą domeną. Kolejny częsty problem to brak zaplanowania hierarchii przed instalacją: zmiana z jednopoziomowego urzędu na strukturę root/subordinate po fakcie wymaga w praktyce budowy urzędu od nowa, ponieważ nazwy i klucze CA nie są przenoszone bez utraty ważności wcześniej wystawionych certyfikatów.

Zdarza się też pomijanie konfiguracji punktów dystrybucji list CRL (Certificate Revocation List, czyli listy unieważnionych certyfikatów) oraz punktów AIA (Authority Information Access, wskazujących, gdzie pobrać certyfikat urzędu). Bez poprawnie ustawionych adresów tych punktów certyfikaty bywają odrzucane przez aplikacje sprawdzające ich ważność, mimo że sam certyfikat został poprawnie wystawiony. Innym powtarzającym się błędem jest nieprzemyślany dobór okresu ważności certyfikatu głównego — zbyt krótki wymusza wymianę całej hierarchii zaufania wcześniej, niż to konieczne, a to oznacza ponowne wdrożenie certyfikatu na wszystkich stacjach i serwerach w domenie.

Kiedy to nie jest konfiguracja AD CS

Nie każdy problem z certyfikatami w firmowej sieci wymaga wdrażania własnego urzędu certyfikacji. Jeśli chodzi wyłącznie o certyfikat SSL dla jednej publicznie dostępnej strony internetowej, wystarczy zwykle certyfikat od zewnętrznego dostawcy, bez budowania całej infrastruktury AD CS. Podobnie, gdy problem dotyczy wygasłego lub nieprawidłowo skonfigurowanego certyfikatu na pojedynczym serwerze — to zadanie z zakresu bieżącej administracji, a nie wdrożenia nowej usługi. Usługi certyfikatów AD CS mają sens tam, gdzie certyfikaty są potrzebne masowo i cyklicznie: do uwierzytelniania stacji roboczych, szyfrowania poczty wewnętrznej, VPN, Wi-Fi z uwierzytelnianiem 802.1X czy podpisywania kodu wewnątrz organizacji.

Dodatkowe pytania klientów

Czy trzeba wyłączać dostęp do internetu na serwerze z rolą CA?

Nie jest to wymóg formalny, ale w przypadku urzędu głównego (root CA) częstą praktyką jest odłączenie go od sieci po wystawieniu certyfikatu dla urzędu podrzędnego. Ogranicza to ryzyko związane z bezpieczeństwem klucza głównego, na którym opiera się zaufanie całej hierarchii certyfikatów.

Czy certyfikaty wystawione przez własny urząd będą działać poza siecią firmową?

Certyfikat wystawiony przez wewnętrzny urząd certyfikacji jest automatycznie zaufany przez urządzenia należące do domeny, natomiast urządzenia spoza niej — na przykład prywatny sprzęt czy zewnętrzni partnerzy — będą zgłaszać ostrzeżenie o niezaufanym certyfikacie, chyba że certyfikat urzędu głównego zostanie na nich ręcznie zainstalowany.

Co się dzieje, gdy certyfikat urzędu głównego wygaśnie?

Wygaśnięcie certyfikatu root CA unieważnia całą hierarchię opartą na tym urzędzie, co oznacza konieczność wymiany certyfikatu głównego oraz ponownego wystawienia certyfikatów podrzędnych. Dlatego okres ważności urzędu głównego planuje się zwykle na wiele lat naprzód, z odpowiednim zapasem względem certyfikatów wystawianych niżej w hierarchii.

Czy migracja z jednego serwera na drugi jest możliwa bez utraty wystawionych certyfikatów?

Tak, pod warunkiem zachowania tej samej nazwy urzędu certyfikacji oraz przeniesienia bazy danych CA i kluczy prywatnych zgodnie z procedurą migracji. Pominięcie któregokolwiek z tych elementów prowadzi do sytuacji, w której wcześniej wystawione certyfikaty przestają być rozpoznawane jako ważne.

Czy usługa obejmuje też integrację z Wi-Fi lub VPN opartym na certyfikatach?

Konfiguracja bazowa obejmuje samą rolę AD CS wraz z wystawieniem pierwszych certyfikatów. Integrację z konkretnymi usługami, takimi jak uwierzytelnianie 802.1X czy VPN oparty na certyfikatach, ustala się indywidualnie w zależności od tego, jaka infrastruktura sieciowa już działa w firmie.

Utrzymanie usługi po wdrożeniu

Po skonfigurowaniu urzędu certyfikacji sama usługa wymaga bieżącej uwagi administracyjnej: aktualizacji list CRL zgodnie z ustalonym harmonogramem, monitorowania zbliżających się terminów wygaśnięcia certyfikatów oraz reagowania na wnioski o odnowienie. Zaniedbanie tych elementów prowadzi zwykle do przerw w działaniu usług zależnych od certyfikatów — na przykład błędów logowania przez VPN czy odrzucania połączeń Wi-Fi — mimo że sam urząd certyfikacji nadal działa poprawnie. Dlatego przy większych wdrożeniach warto od razu ustalić, kto w firmie odpowiada za bieżący nadzór nad hierarchią certyfikatów, zanim liczba wystawionych certyfikatów urośnie na tyle, że ręczne śledzenie terminów przestanie być praktyczne.

Szablony certyfikatów i automatyzacja wystawiania

W wariancie enterprise CA kluczowym elementem codziennej pracy urzędu certyfikacji są szablony certyfikatów. Szablon określa, do czego dany certyfikat może być użyty (na przykład uwierzytelnianie stacji roboczej, podpis cyfrowy, szyfrowanie poczty), jakie dane mają się w nim znaleźć oraz kto może o taki certyfikat wnioskować. Dzięki integracji z Active Directory i zasadami grupy (Group Policy) certyfikaty ze skonfigurowanych szablonów mogą być wystawiane automatycznie, bez ręcznego udziału użytkownika czy administratora — komputer lub konto otrzymuje certyfikat przy starcie systemu lub logowaniu, zgodnie z przypisaną zasadą grupy. Upraszcza to obsługę dużej liczby stacji, ale wymaga wcześniejszego przemyślenia, które szablony mają być dostępne do automatycznego wystawiania, a które — ze względu na wrażliwość zastosowania — powinny wymagać ręcznego zatwierdzenia przez administratora urzędu certyfikacji.

Błędne uprawnienia do szablonu to jeden z częstszych problemów zgłaszanych już po wdrożeniu: zbyt szerokie uprawnienia do wnioskowania o certyfikat mogą pozwolić użytkownikom na uzyskanie certyfikatu przeznaczonego dla innej roli, na przykład dla kont administracyjnych. Z tego względu przegląd uprawnień do poszczególnych szablonów certyfikatów jest elementem, który warto ująć jako osobny krok konfiguracji, a nie zakładać, że domyślne ustawienia są wystarczające dla każdego środowiska.

Typowe zastosowania w firmowej infrastrukturze

W praktyce usługi certyfikatów Active Directory najczęściej wspierają kilka powtarzających się scenariuszy. Pierwszy to uwierzytelnianie stacji roboczych i serwerów w sieci wewnętrznej — certyfikat potwierdza tożsamość urządzenia niezależnie od hasła użytkownika, co bywa wymagane przy dostępie do niektórych zasobów firmowych. Drugi to szyfrowanie i podpisywanie poczty elektronicznej wewnątrz organizacji (S/MIME), gdzie certyfikat pozwala odbiorcy zweryfikować, że wiadomość rzeczywiście pochodzi od wskazanego nadawcy i nie została zmieniona po drodze. Trzeci częsty przypadek to uwierzytelnianie w sieci bezprzewodowej metodą 802.1X, gdzie zamiast wspólnego hasła do Wi-Fi każde urządzenie loguje się własnym certyfikatem, co ułatwia też odebranie dostępu pojedynczemu urządzeniu bez zmiany hasła dla wszystkich.

Czwarty scenariusz to certyfikaty dla wewnętrznych stron i aplikacji webowych działających tylko w sieci firmowej — bez publicznego adresu internetowego zewnętrzny urząd certyfikacji nie wystawi dla nich certyfikatu, więc naturalnym rozwiązaniem jest własny urząd zintegrowany z domeną. Piąty, rzadziej spotykany, ale spotykany w większych firmach, to podpisywanie kodu i skryptów wykorzystywanych wewnętrznie, co pozwala systemowi odróżnić skrypty pochodzące z zaufanego źródła od tych spoza organizacji.

Bezpieczeństwo klucza prywatnego urzędu certyfikacji

Bezpieczeństwo całej hierarchii certyfikatów opiera się na ochronie klucza prywatnego urzędu certyfikacji — jeśli ten klucz zostanie skompromitowany, nieuprawniona osoba mogłaby wystawiać certyfikaty podszywające się pod dowolne urządzenie czy usługę w firmie. Z tego względu dostęp administracyjny do serwera pełniącego rolę CA powinien być ograniczony do wąskiego grona osób, a kopia zapasowa klucza i bazy urzędu certyfikacji przechowywana w sposób odseparowany od codziennej pracy serwera. W środowiskach, gdzie wymagany jest wyższy poziom zabezpieczeń, klucz prywatny urzędu głównego bywa dodatkowo przechowywany na sprzętowym module zabezpieczającym (HSM), choć w większości małych i średnich firm wystarczające bywa samo odseparowanie root CA od sieci po wystawieniu certyfikatu dla urzędu podrzędnego.

Kolejne pytania klientów

Czy jeden serwer może pełnić rolę CA i jednocześnie inne funkcje w firmie?

Technicznie jest to możliwe, ale nie jest to zalecane rozwiązanie, szczególnie w przypadku urzędu głównego. Łączenie roli CA z innymi zadaniami serwera zwiększa liczbę osób i procesów mających dostęp do maszyny, a tym samym zwiększa ryzyko związane z bezpieczeństwem klucza prywatnego urzędu certyfikacji.

Co się stanie, jeśli pracownik odejdzie z firmy, a jego certyfikat pozostanie aktywny?

Certyfikat przypisany do konta lub urządzenia można unieważnić ręcznie z poziomu urzędu certyfikacji — trafia wtedy na listę CRL i przestaje być akceptowany przez systemy sprawdzające jego ważność. To element bieżącej obsługi urzędu certyfikacji, wykonywany razem z dezaktywacją konta w Active Directory.

Czy urząd certyfikacji trzeba odnawiać co jakiś czas?

Sam urząd certyfikacji jako usługa działa w sposób ciągły, natomiast wygasa certyfikat, na którym się opiera — zarówno w przypadku urzędu głównego, jak i podrzędnego. Odnowienie takiego certyfikatu jest zaplanowanym działaniem administracyjnym, a nie ponowną instalacją całej roli.

Podsumowanie

Wdrożenie usług certyfikatów Active Directory to decyzja, którą warto poprzedzić ustaleniem docelowej hierarchii urzędów i zakresu zastosowań certyfikatów, ponieważ zmiana tych założeń po wdrożeniu zwykle oznacza budowę urzędu od nowa. Prawidłowo skonfigurowany AD CS działa w tle przez lata, obsługując uwierzytelnianie i szyfrowanie wewnątrz firmowej sieci bez udziału zewnętrznego dostawcy certyfikatów.

22 378 48 09

Windows Server — konfiguracja usług certyfikatów (Active Directory Certificate Services)