Wdrożenie respondera OCSP w AD CS

OCSP (Online Certificate Status Protocol) jest protokołem, który pozwala nam na sprawdzanie online, czy certyfikat jest dalej ważny i działa on lepiej od domyślnej metody, która jest używana, czyli listy CRL. W małych organizacjach nie ma to wielkiego znaczenia, czy używamy jednego czy drugiego, lecz w większych te pliki CRL mogą być duże i w celu zmniejszenia ruchu można zastosować tzw. OCSP Responder. W dużym uproszczeniu CRL jest listą zawierającą wszystkie odwołania certyfikatu. Im więcej odwołań, tym większa lista. W przypadku komunikacji OCSP pytamy zawsze o jeden certyfikat. Dla zielonych w temacie polecam przeczytać sobie ten artykuł na Medium – naprawdę świetnie przedstawia temat.

Dobry koncept działania

Dobre wdrożenie zakłada, że będziemy mieć wdrożoną domenę Active Directory (najlepiej z rezerwowym kontrolerem domeny, hosty DC1 i DC2), wdrożony główny urząd certyfikacji na osobnej maszynie (host Root CA), która jest tylko i wyłącznie po do tego, by wystawić certyfikat podrzędnemu urzędowi certyfikacji (host Sub CA1), który pracowałby w klastrze failover w celu uzyskania wysokiej dostępności (z hostem Sub CA2). Ponadto responder OCSP powinien być na osobnym hoście (OCSP1) od podrzędnego urzędu certyfikacji i najlepiej, by także pracował w trybie wysokiej dostępności, więc w tym przypadku zostaje postawić drugiego hosta, który także będzie responderem OCSP (host OCSP2) i ruch do responderów byłby rozbijany jakimś load balancerem (to się nazywa Online Responder Array).

Takie praktyki znalazłem w tych miejscach:

Rzeczywistość

W rzeczywistości by takie środowisko mieć jak wyżej, należy mieć co najmniej 7 instancji Windows Server, nie wspominając o tym, że jeśli chcemy jeszcze mieć jakieś bazy danych to powinniśmy je trzymać na osobnych maszynach. Rzeczywistość jest taka, że większość firm po prostu nie ma na to kasy i kończy z jednym urzędem certyfikacji. Tym głównym, a na nim stoi też OCSP Responder.

Dlatego też postaram się pokazać jak to powinno się skonfigurować w takim biednym wydaniu, czyli bez redundancji, wysokiej dostępności i na jednym hoście.

Instalacja i konfiguracja

Ogólnie wdrażanie OCSP z mojej perspektywy zakłada, że mamy już wdrożony urząd certyfikacji, a przedtem AD – możemy przystąpić do instalacji. Należy zainstalować rolę, którą widać poniżej. Po wybraniu roli i kliknięciu Dodaj funkcje wystarczy, że będziemy klikać dalej i wszystko będzie OK.

Następnie zostaniemy poproszeni o skonfigurowanie roli AD CS:

Administrator jest dobrym użytkownikiem do tego zadania. Po wybraniu odpowiedniego użytkownika przechodzimy dalej. Następnie wybieramy rolę Obiekt odpowiadający w trybie online. Idziemy dalej.

Tym razem Konfiguruj.

Jak widać, wszystko jest ok, więc można zamknąć.

Po wdrożeniu da się zauważyć, że IIS wystawił nową podstronę – ocsp.

To nie koniec konfiguracji. Teraz musimy wskazać w naszym CA, że istnieje responder OCSP, który może pozwalać na sprawdzenie certyfikatu. Należy otworzyć przystawkę certification authority, kliknąć na nasz urząd PPM i wybrać Właściwości.

Następnie należy przejść do zakładki Rozszerzenia, wybrać rozszerzenie Dostęp do informacji o urzędach (AIA) i kliknąć pod listą na Dodaj… aby dodać nowy wpis – w moim przypadku nazwa hosta to dc1.stormshield.local, więc adres to respondera to http://dc1.stormshield.local/ocsp. Wpisujemy i dajemy OK.

Ponadto, po wybraniu wpisu należy zaznaczyć opcję Dołącz do rozszerzenia protokołu stanu certyfikatów online (OCSP).

Po tym zapisujemy. Urząd certyfikacji się zrestartuje i zastosuje zmiany. Poza tym musimy stworzyć szablon, który będzie używał responder do wykonywania odpowiedzi, więc w naszym CA należy przejść do elementu Szablony certyfikatów, kliknąć PPM i Zarządzaj:

Następnie należy wybrać z listy wybrać certyfikat Podpisywanie odpowiedzi protokołu OCSP, kliknąć PPM i wybrać Duplikuj szablon.

Następnie należy w opcjach certyfikatu dodać hosta, na którym jest postawiony responder (należy zaznaczyć w typach obiektów komputery i dopiero wtedy można wybrać nasz host) poprzez nazwę hosta (nie FQDN) i zapisać.

Potem takiemu hostowi dajemy pełne uprawnienia.

Jak zrobimy to – zapisujemy szablon, wracamy do listy szablonów i klikamy PPM, a następnie Nowy > Szablon certyfikatu do wystawienia.

Wybieramy z listy Podpisywanie odpowiedzi protokołu OCSP i dajemy OK.

Następnie w Menedżerze serwera wybieramy Narzędzia u góry i otwieramy narzędzie Zarządzanie obiektem odpowiadającym w trybie online.

Klikamy na Konfiguracja odwołania PPM i wybieramy Dodaj konfigurację odwołania.

Dajemy dalej.

Nazywamy jakoś profil konfiguracji i idziemy dalej.

Wybieramy opcję Wybierz certyfikat dla istniejącego urzędu certyfikacji przedsiębiorstwa.

Następnie wybieramy Przeglądaj certyfikaty urzędu certyfikacji opublikowane w usłudze Active Directory i klikamy Przeglądaj….

Nie mamy innych urzędów, bo mamy tylko Root CA, więc wybieramy to, co jest i dajemy OK.

W tym menu nie trzeba niczego zmieniać – zostawiamy tak jak jest. Należy się upewnić, że nasz szablon certyfikatu, który dodaliśmy jest wskazany na liście. W moim przypadku tak jest. Po tym idziemy dalej.

I na tym etapie dajemy Zakończ.

To, co widzimy niżej sygnalizuje, że responder działa.

Jeśli przedtem wystawialiśmy certyfikaty z tego CA, musimy je wszystkie zaaktualizować. Dopiero po aktualizacji klienci będą w stanie sprawdzać za pomocą swoich przeglądarek ważność certyfikatu.

Test działania respondera

Wedle tego, co znalazłem w internecie są takie tylko dwie metody do darmowego sprawdzania lokalnych OCSP.

Działająca metoda w AD to pobranie pliku certyfikatu ze strony i wykonanie polecenia:

certutil -url nazwapliku.cer

To nam otworzy okienko, w którym możemy przetestować nasz certyfikat pod kątem ważności sprawdzając zarówno CRL jak i odpowiedź z OCSP.

Drugą metodą jest OpenSSL, ale z jakiegoś powodu nie mogę zrobić testu:

openssl ocsp -issuer chain.cer -cert nowystorm.cer -text -url http://dc1.stormshield.local/ocsp
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: F24A314B6FE15A9F957F564E67A7F742AEAAE6D1
          Issuer Key Hash: B4F871C0904A4E23DB23ED735A8B600377A3FE4F
          Serial Number: 5F000000194FC858E43846DF9F000000000019
    Request Extensions:
        OCSP Nonce:
            0410B6C5BD9BF012E5E4C9434574D9F27C92
Responder Error: unauthorized (6)

Plik chain.cer to plik certyfikatu CA, a nowystorm.cer to plik certyfikatu do sprawdzenia.

Dla porównania pokażę jak wygląda odpowiedź OCSP z publicznego serwera dla certyfikatu strony, którą przeglądasz:

openssl ocsp -issuer chain.pem -cert cert.pem -text -url http://ocsp.int-x3.letsencrypt.org
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
          Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
          Serial Number: 0300066ED207EE1AA2BD24030405755E491F
    Request Extensions:
        OCSP Nonce:
            041000836B3DA5BF27BDA09E99899D1C931F
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
    Produced At: Aug 22 17:32:00 2020 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
      Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
      Serial Number: 0300066ED207EE1AA2BD24030405755E491F
    Cert Status: good
    This Update: Aug 22 17:00:00 2020 GMT
    Next Update: Aug 29 17:00:00 2020 GMT

    Signature Algorithm: sha256WithRSAEncryption
         85:17:4b:b1:09:14:ce:62:1d:94:4b:f6:8d:82:ce:47:97:ff:
         05:be:3a:7f:45:59:d1:d6:fc:b8:c5:e4:e4:86:dc:80:4d:fc:
         56:72:0f:21:24:5d:c9:3c:9f:c1:d7:51:26:6f:94:66:51:04:
         b6:5c:a9:6d:34:06:67:90:40:39:b2:07:12:76:0f:5a:47:ce:
         02:46:8b:12:b5:6d:40:b7:b6:05:6a:ed:fd:ed:27:8b:95:31:
         88:7b:44:e7:4d:89:ed:66:51:68:3d:0d:6c:d1:f4:df:16:f4:
         0d:54:f0:6f:54:42:2d:e9:e8:16:76:9f:8c:2e:64:9d:f5:ec:
         87:2e:f7:e1:0e:de:da:2a:e0:4d:67:de:04:9b:e7:e5:ae:83:
         1b:1b:06:df:37:f9:dd:6d:2d:45:3c:50:82:f8:d4:0c:bc:8b:
         4d:20:db:8a:5a:1a:e5:60:12:68:9f:dd:37:76:7e:7d:1e:3c:
         f9:50:c4:6c:ad:6d:59:98:fc:f4:f9:0f:a6:fe:f0:50:08:6b:
         2a:66:46:35:64:4a:51:fa:57:47:44:85:6c:56:22:03:3e:1f:
         9b:96:c1:e2:03:15:40:2a:5b:3c:18:19:00:a3:cc:d8:3a:b8:
         f0:29:21:e6:81:11:d2:11:4a:f3:0f:73:b3:ba:ba:3e:90:0a:
         0b:77:82:9c
WARNING: no nonce in response
Response verify OK
cert.pem: good
        This Update: Aug 22 17:00:00 2020 GMT
        Next Update: Aug 29 17:00:00 2020 GMT

Zajawka pod kątem wdrażania OCSP

  • https://www.sysadmins.lv/dl/48.aspx

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *