Dopisanie adresu konsoli ShadowControl do instalatora agenta

Dzięki programowi Orca można osiągnąć taki efekt, że w trakcie kreatora instalacji nie trzeba podawać adresu serwera ShadowControl przy instalacji agenta, ponieważ może on być zapisany wewnątrz instalatora i wygląda to tak:

Dzięki temu można zainstalować agenta i po instalacji on sam się podepnie do konsoli. Program Orca możemy znaleźć w Windows 10 SDK – wystarczy przy instalacji zaznaczyć opcję MSI Tools i nic innego. Dzięki temu w folderze Windows 10 SDK będziemy mieć instalator do Orca:

Wystarczy przejść instalator i będziemy mieli program Orca na swoim komputerze. Po tym należy go otworzyć, przeciągnąć na niego instalator ShadowControl, a następnie wybrać po lewej pole Property, a następnie kliknąć na środku na wolne pole PPM i wybrać opcję Add row…

Następnie w polu Property należy zdefiniować APPL_ADDR i w polu Value wpisać adres IP lub FQDN naszej konsoli ShadowControl. Po tym zapisujemy i w File > Save nasz plik instalacyjny.

Po tym taki instalator możemy zainstalować przez GPO lub przez np. polecenie msiexec:

msiexec /qn /package ShadowControl_Installer.msi

Wdrażanie usługi rejestracji urządzeń sieciowych (NDES)

SCEP (Simple Certificate Enrollment Protocol) nie jest tak popularny w dzisiejszych czasach z tego względu, że większość rozwiązań, na których wdraża się certyfikaty SSL ma już wbudowany interfejs pozwalający na proste wymienienie certyfikatu. SCEP na pewno byłby dobrym rozwiązaniem jeśli w organizacji urządzeń z certyfikatami są setki i chcielibyśmy zaaktualizować na nich wszystkich certyfikaty, lecz nadal trzeba pamiętać, że takowe urządzenie musi to obsługiwać, z czego na ten moment spotkałem się z tym, że tylko FortiGate był w stanie obsłużyć SCEPa.

Funkcja, która pozwala na podpisywanie certyfikatów to NDES (Network Device Enrollment Service) lub po polsku Usługa rejestracji urządzeń sieciowych. Poniżej opiszę po krótce jak to wdrożyć szybko.

Przygotowanie

Na początku należy zacząć od założenia konta dla NDESa, w moim przypadku nazywa się scepuser.

Następnie musimy takie konto dodać do grupy IIS_IUSRS. Ogólnie te konto powinno być w takiej lokalnej grupie, lecz z faktu, że zainstalowałem tą rolę na kontrolerze domeny (czego się nie powinno robić) jest w grupie domenowej.

Z faktu, że to jest jednak kontroler domeny, musiałem w polityce kontrolerów domeny dodać możliwość logowania się w trybie usługi tego konta. Bez tego nie uda nam się skonfigurować roli. Na zrzucie ekranu jest widoczne gdzie można znaleźć te ustawienie.

Poniżej widok jak to wygląda po skonfigurowaniu w polityce kontrolerów domeny. W normalnym wypadku to się definiuje dla serwera, na którym jest instalowana rola NDES.

Podobnie należy zezwolić na logowanie lokalne do serwera.

Jeśli tego nie zrobimy, w trakcie konfigurowania usługi po wybraniu naszego konta serwisowego dostaniemy to:

Konfiguracja

Po przygotowaniu konta należy zainstalować rolę Usługa rejestracji urządzeń sieciowych.

Po zainstalowaniu należy kliknąć Konfiguruj usługi certyfikatów Active Directory na serwerze docelowym.

Tutaj trzeba wskazać konto administracyjne, które pozwala na skonfigurowanie roli. Najlepiej skorzystać z konta administratora.

Z listy zaznaczamy nowo zainstalowaną rolę.

Dopiero tutaj wskazujemy użytkownika scepuser.

Następnie musimy podać dane do nowego urzędu rejestrowania. Dosyć prosta sprawa.

Teraz wybieramy dostawcę klucza podpisu i długość klucza. Można zostawić domyślne.

I to byłoby na tyle, klikamy Konfiguruj i mamy gotowe…prawie.

Tutaj potwierdzenie, że to, co zrobiliśmy się udało.

Zanim NCEP będzie działał, musimy dodać szablon do podpisywania, z którego będziemy korzystać. W sumie to przy instalacji NCEPa on sam się wdraża, więc jedynie musimy się upewnić, że konfiguracja jest OK. Otwieramy urząd certyfikacji poprzez przystawkę certsrv, wybieramy Szablony certyfikatów, klikamy prawym na wolne miejsce i Zarządzaj.

W konfiguracji szablonów wybieramy szablon IPSec (żądanie offline), klikamy prawym i Właściwości.

W ustawieniach zabezpieczeń konto scepuser musi mieć uprawnienia do rejestracji.

Jeśli tak wygląda szablon – w sumie to nie musimy nic więcej robić, bo to oznacza, że wszystko jest już gotowe.

Testowanie SCEP

Ogólnie do przetestowania są płatne narzędzia, z takich darmowych to znalazłem post, który opisuje użycie tutaj. Z tego, co widziałem NCEPa używa się przy instalacji Microsoft Intune, więc myślę, że pod kątem tego narzędzia będzie najlepiej testować.

Stormshield jako podrzędny urząd certyfikacji dla AD CS w filtrze SSL i dodawanie certyfikatu SSL dla strony

Okej, ten sam temat przerabialiśmy wcześniej z FortiGate i teraz robimy to na Stormshieldzie. Nie chce mi się instalować przez GPO wbudowanego certyfikatu ze Stormshielda na każdym komputerze. Łatwiej jest podpisać certyfikat dla podrzędnego CA, którym byłby Stormshield i temat załatwiony, bo główne CA i tak mają wszyscy w komputerach po instalacji AD CS. Druga rzecz to jest to, by stronka wyświetlała stronkę Stormshielda jako bezpieczną. Zaczniemy najpierw od tego. Przykłady są bazowane na SNS 4.0.3, ale równie dobrze to będzie działało zarówno na starszych jak i nowszych wersjach.

Instalowanie certyfikatu SSL dla strony

To, jak uzyskać taki certyfikat z AD CSa opisałem tutaj, więc zapraszam do lekturki. Po tym, gdy certyfikat już mamy wyeksportowany należy przejść do strony Stormshielda, zalogować się i przejść do zakładki Konfiguracja, następnie z lewej strony wybrać Obiekty > Certyfikaty – PKI, a następnie kliknąć Dodaj > Importuj plik.

Następnie należy wskazać ścieżkę do plików certyfikatu (certyfikat musi mieć zintegrowany klucz prywatny, więc musimy skorzystać z P12 (PKCS #12). Jeśli to jest potrzebne – podajemy hasło i klikamy Importuj.

Poniżej coś, na co się naciąłem przy generowaniu certyfikatów z Windowsa: jeśli nie zaimportujemy podpisanego certyfikatu do naszego lokalnego magazynu certyfikatów z komputera, na którym generowaliśmy CSR to nie będzie widać drzewka z urzędu certyfikacji (przykład po lewej). Po prawej jest przykład tego, jak to powinno wyglądać.

Potem należy przejść do Użytkownicy > Portal uwierzytelnienia, wybrać zakładkę Portal uwierzytelnienia i w sekcji Serwer SSL wybrać nasz nowy certyfikat, a po tym zatwierdzić ustawienia.

Po otwarciu na nowo przeglądarki strona powinna być jako bezpieczna…

Nawet po adresie IP, jeśli wykorzystaliście mój przykład z generowaniem CSR z CLI z tego posta.

Na wypadek fuck-upu

Jeśli zrobicie tak jak ja i odwołacie certyfikat, który aktualnie jest używany na Stormshieldzie to jesteście w czarnej D. W takiej sytuacji jedyne, co pozostaje do podpięcie się przez PuTTY po SSH do Stormshielda i usunięcie certyfikatu z CLI. Należy otworzyć plik konfiguracyjny za pomocą polecenia:

joe ConfigFiles/auth

Następnie należy w pliku wyczyścić w sekcji [Config] wartość pola SslCertificate=:

Po tym wystarczy zapisać skrótem Ctrl+K+X i wykonać polecenie enauth. To zrestartuje portal i znowu będziemy mieć samopodpisany certyfikat SSL.

Certyfikat SSL dla podrzędnego CA w celu filtrowania SSL

Generowanie certyfikatu i import wygląda podobnie. Szablon w pliku tekstowym wygląda tak:

[Version]
Signature="$Windows NT$"
 
[NewRequest]
;w tym polu określamy dane certyfikatu
Subject = "C=PL, O=it.supra.tf, CN=stormshield.stormshield.local, L=Tychy, S=śląskie, [email protected], OU=IT"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
KeySpec = AT_KEYEXCHANGE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = CERT_CRL_SIGN_KEY_USAGE
HashAlgorithm = SHA256

[RequestAttributes]
CertificateTemplate=SubCA

Równie dobrze można to zrobić z GUI. W praktyce działa tak samo. Sposób wystawiania takiego certyfikatu i eksportowania go opisałem tutaj. Tutaj część o robieniu tego przez CLI. Certyfikat dla podrzędnego CA importuje się tak samo, jak ten do stronki:

Następnie w Kontrola aplikacji > Analiza protokołów > SSL należy wybrać Pokaż ustawienia wspólne dla wszystkich profili i wybrać w Główny urząd certyfikacyjny (CA) nasz urząd certyfikacji:

Na koniec wystarczy dodać hasło do certyfikatu i zapisać.

Tak wygląda efekt końcowy:

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

Automatyczne generowanie certyfikatów dla komputerów i użytkowników z AD CS

Ten myk jest dosyć przydatny pewnie w wielu kwestiach, ale na ten moment jestem chyba zbyt głupiutki, by znać największe zalety. Tak czy siak znam kilka – na pewno takie certyfikaty klienta/komputera można wykorzystać w autoryzacji VPN w klientach FortiClient dla FortiGate. Poza tym można to też wykorzystać przy logowaniu do interfejsu administracyjnego Stormshielda.

Istotna sprawa na początku – certyfikaty klienta w tym poradniku będą tak skonfigurowane, że będą wymagały tego, by każdy użytkownik miał wpisany adres e-mail w koncie użytkownika.

Jeśli tego nie zrobimy to skończymy z takimi błędami w urzędzie certyfikacji. Po prostu nasze certyfikaty nie zostaną wystawione.

Aby certyfikaty były wystawiane dla komputerów jak i dla użytkowników, musimy im pozwolić na żądanie takich certyfikatów. Zaczynamy w urzędzie certyfikacji, w sekcji Szablony certyfikatów klikamy PPM i wybieramy Zarządzaj.

Zaczniemy od szablonu dla komputerów. Z listy szablonów wybieramy Uwierzytelnienie stacji roboczej i klikamy na ten szablon PPM, wybieramy Duplikuj szablon.

Następnie w ustawieniach nowego szablonu musimy zmienić jego nazwę wyświetlaną i nazwę szablonu (nazwę pospolitą). Ta druga nie może mieć spacji, a ta pierwsza nie może być taka jak zawsze, bo nie będziemy w stanie rozróżnić naszego szablonu od tego wbudowanego. Ponadto ja zmieniłem okres ważności certyfikatu na 3 lata, ale to nie jest potrzebne. W produkcji nie stosowałbym tej zmiany. To wszystko robimy w zakladce Ogólne.

Następnie w zakładce Nazwa podmiotu upewniamy się, że Nazwa DNS i Główna nazwa użytkownika jest zaznaczona.

Następnie w zakładce Zabezpieczenia należy upewnić się, że grupa Komputery domeny ma uprawnienia do odczytu, rejestracji i autorejestrowania.

Po tym można zapisać. Następnie duplikujemy szablon Użytkownik:

Podobnie jak w przypadku pierwszego szablonu edytujemy obie nazwy. Tutaj domyślnie też okres ważności certyfikatu to rok i zmieniłem na 3. W normalnym środowisku bym tego nie zmieniał. Ponadto tutaj jest zaznaczona opcja Publikuj certyfikat w usłudze Active Directory i tak powinno być.

W zakładce Obsługiwanie żądań musimy się upewnić, że opcja Zezwalaj na eksportowanie klucza prywatnego jest odznaczona. Poza tym te opcje, które są tutaj widoczne są domyślnie wybrane i nie musimy niczego zmieniać.

Następnie musimy przejść do zakładki Rozszerzenia, wybrać z listy rozszerzeń Zasady aplikacji i kliknąć Edytuj….

Następnie klikamy Dodaj….

Z listy wybieramy Uwierzytelnienie serwera i dajemy OK.

Tak to powinno wyglądać na koniec.

Potem, w zakładce Zabezpieczenia grupa Użytkownicy domeny powinna mieć uprawnienia do odczytu, rejestracji i autorejestrowania.

Na koniec w karcie Nazwa podmiotu w alternatywnej nazwie podmiotu powinna być zaznaczona Nazwa e-mail i Główna nazwa użytkownika (UPN). Gdy to mamy gotowe, możemy zapisać.

Po tym musimy wystawić szablony tak, aby dało się z nich korzystać. Klikamy w urzędzie certyfikacji, w sekcji Szablony certyfikatów klikamy PPM i Nowy > Szablon certyfikatu do wystawienia.

Z listy wybieramy nasze nowe szablony certyfikatów i dajemy OK.

Okej, mamy szablony gotowe, więc teraz musimy umożliwić użytkownikom i komputerom na pobieranie certyfikatów. Co prawda tutaj stworzyłem obiekt w głównym drzewku AD, ale myślę, że niekoniecznie to jest najlepszy pomysł, bo po testach mój kontroler domeny wygenerował sobie certyfikaty i zaczął używać niewłaściwych certyfikatów w niewłaściwych miejscach (poniżej opisuję jak to rozwiązać). Zaczynamy w przystawce Zarządzanie zasadami grupy, w OU z komputerami i użytkownikami lub OU nadrzędnym tworzymy obiekt zasad grupy i jakoś go nazywamy.

Następnie wybieramy obiekt PPM i klikamy Edytuj. Po tym, aby włączyć automatyczne odnawianie certyfikatów dla komputerów należy przejść do Konfiguracja komputera > Zasady > Ustawienia systemu Windows > Ustawienia zabezpieczeń > Zasady kluczy publicznych > Klient usług certyfikatów – automatyczna rejestracja, kliknąć ostatni element PPM i wybrać Właściwości.

We właściwościach wybieramy Model konfiguracji – Włączone, a następnie zaznaczamy oba checkboxy i dajemy okej.

To samo robimy w przypadku użytkowników, lecz ustawienie znajduje się w Konfiguracja użytkownika > Zasady > Ustawienia systemu Windows > Ustawienia zabezpieczeń > Zasady kluczy publicznych > Klient usługi certyfikatów – automatyczna rejestracja.

Tak samo wybieramy Model konfiguracji – Włączone i zaznaczamy oba checkboxy.

Po tym zapisujemy ustawienie, zamykamy GPO i czekamy na aktualizację polityk grupy lub wymuszamy je choćby poleceniem gpupdate /force. Efekt jest taki, że w magazynie certyfikatów komputera pojawi nam się taki certyfikat:

Dodatkowo magazynie certyfikatów użytkownika także się pojawi certyfikat użytkownika:

Potem to można wykorzystać np. przy logowaniu ze Stormshieldem (można wykorzystać certyfikat zamiast podawania loginu i hasła do interfejsu administracyjnego).

By włączyć możliwość logowania po kontach z AD z certyfikatami musimy zintegrować Stormshielda z AD, a następnie dodać metodę autoryzacji Certyfikat (SSL) i wskazać urząd certyfikacji, z którego akceptujemy certyfikaty:

W przypadku FortiGate jeśli ustawieniach SSL-VPN włączymy opcję Require Client Certificate, będziemy musieli się przedstawić certyfikatem klienta przy połączeniu. Oczywiście FortiGate musi mieć certyfikat CA zaimportowany do swojego własnego magazynu certyfikatów, by to działało.

Potem, z poziomu klienta w opcjach profilu VPN wybór certyfikatu wygląda tak:

W trybie webowym tego VPNa wygląda to tak:

Troubleshooting po wprowadzeniu zmian

Jak wspominałem wcześniej, wrzucanie polityki GPO z auto-enrollment było dla mnie zgubne, bo kontroler domeny przestał się przedstawiać odpowiednim certyfikatem w przypadku ruchu szyfrowanego (LDAPS) i wykorzystywał zły certyfikat dla strony do wystawiania certyfikatów w IIS, więc zacząłem od tego, by w IIS zmienić certyfikat z powrotem na poprawny (to jest najprostsze).

Na początku należy przejść do przystawki Certyfikaty.

Następnie, należy wybrać konto usługi.

Teraz komputer lokalny.

Z listy wybieramy Usługi domenowe w usłudze Active Directory.

Po otwarciu katalogu NTDS/Osobisty okazało się, że jest on pusty. W takiej sytuacji AD dobiera sobie certyfikat z lokalnego magazynu certyfikatów i dobiera najnowszy z pasującymi atrybutami. Problem w tym, że te dobieranie atrybutów nie działa zbyt dobrze, więc jeśli chcemy, by LDAPS działał dobrze, musimy umieścić we wspomnianym magazynie certyfikat. Na początku należy zmienić szablon Uwierzytelnianie Kerberos tak, by pozwalał na eksportowanie certyfikatu z kluczem prywatnym, w taki sam sposób, jak tutaj poniżej. Potem należy taki szablon na nowo wystawić, odnowić certyfikat dla LDAPS, eksportować go do pliku i importować do magazynu NTDS/Osobisty.

Tutaj już odnawiam certyfikat.

Dalej.

Zarejestruj.

I gotowe.

Jak wspomniałem, eksportujemy.

Dalej.

Tak, eksportuj klucz prywatny. W następnej części musimy mieć zaznaczone opcje tak jak na zrzucie ekranu, czyli Jeśli jest to możliwe, dołącz wszystkie certyfikaty do ścieżki certyfikacji, Eksportuj wszystkie właściwości rozszerzone i Włącz funkcje prywatności certyfikatu.

Potem podajemy jakieś hasło i wybieramy szyfrowanie AES256-SHA256.

Na końcu wskazujemy ścieżkę do zapisu pliku i zapisujemy.

Tak to wygląda.

Potem we wspomnianym wcześniej magazynie importujemy wyeksportowany certyfikat.

Dalej.

Wskazujemy plik.

Potem podajemy hasło i istotne jest to, by opcja Dołącz wszystkie właściwości rozszerzone.

To się samo wpisze, idziemy dalej.

I koniec.

Po tym należy zrestartować system, a usługa kontrolera domeny zmieni certyfikat i będziemy w domu.

Rejestracja w sieci Web dla urzędu certyfikacji poprzez HTTPS

Niestety domyślnie ten serwis jest dostępny po HTTP i uważam, że to jest problem. Dlatego pokażę jak skonfigurować obsługę HTTPS tak, by jednocześnie serwis po HTTP i HTTPS był dostępny. W przykładzie postawiłem AD CSa na kontrolerze domeny i wiem, że to nie jest najlepsze rozwiązanie, ale szczerze powiedziawszy byłem trochę leniwy i nie chciało mi się w środowisku testowym stawiać nowej VMki dla AD CSa. Nie wiem, czy IIS po instalacji automatycznie wykonuje żądanie certyfikatu, by w przyszłości włączyć SSL dla stronki – w moim przypadku certyfikat już był przygotowany, ale na wszelki wypadek opiszę krótko jak krok po kroku wygenerować certyfikat z poziomu IISa.

Certyfikat SSL

Na początku należy otworzyć Menedżer internetowych usług informacyjnych (IIS) i wybrać w drzewku nasz serwer i wybrać Certyfikaty serwera.

W moim przypadku certyfikat tutaj już jest, ale wygenerujemy nowy dla przykładu klikając prawym i Utwórz żądanie certyfikatu….

Następnie należy wypełnić wszystkie dane. Najważniejsze jest to, żeby nazwa pospolita zgadzała się z tym, co wpisujemy, czyli jeśli wchodzimy na stronę https://dc1.stormshield.local/certsrv, to nazwa pospolita powinna być dc1.stormshield.local lub *.stormshield.local.

Następnie wybieramy jako dostawcę usług kryptograficznych i długość w bitach to, co mam poniżej. Opcjonalne jest zmienienie długości klucza na 4096 znaków.

Następnie należy po prostu zapisać żądanie podpisania certyfikatu (CSR).

Mając CSR należy wykonać żądanie podpisania certyfikatu. Można je zrealizować poprzez nasz serwis webowy po HTTP lub skorzystać z polecenia:

certreq -Submit -Attrib "CertificateTemplate:WebServer" -Config "dc1.stormshield.local\Stormshield Root CA" .\request.csr
//ta kropka i backslash (.\) wynikają z tego, że używałem konsoli Microsoft PowerShell

Następnie zapisujemy certyfikat i w IIS w tym samym miejscu, gdzie byliśmy wybieramy Ukończ żądanie certyfikatu….

Następnie wskazujemy plik certyfikatu, który zapisaliśmy, wpisujemy nazwę przyjazną, by łatwo rozpoznać który certyfikat podpisaliśmy (ja dopisałem 2 do nazwy, bo obawiałem się o to, że pierwszy certyfikat ma już jakąś nazwę pospolitą, lecz jednak nie miał) i na końcu wybieramy magazyn certyfikatów dla nowego certyfikatu jako Usługa hosta w sieci Web.

Po tym możemy przejść do ustawień serwisu CertSrv, a następnie do Ustawienia zaawansowane… po prawej stronie.

W sekcji Włączone protokoły powinniśmy pole powinno zawierać http, https. Jeśli tak ustawiliśmy, możemy zapisać.

Następnie należy przejść do Default Web Site i zmienić ustawienia powiązań, by umożliwić łączenie się na stronę po porcie 443. Klikamy po prawej na Powiązania…, dodajemy nowe powiązanie.

Następnie w Typ wskazujemy https, w nazwie hosta wskazujemy dc1.stormshield.local (tak jest w moim przypadku), port powinien być 443 i na dole musimy wybrać certyfikat SSL. Ja już wybrałem wcześniej i po lewej stronie jest podgląd certyfikatu po kliknięciu Wyświetl….

Poniżej też pokazuję, że nasz utworzony certyfikat też jest na liście dostępny.

Po tym wszystkim wystarczy zapisać i wszystko już powinno działać poprawnie:

Na najlepszej przeglądarce na świecie (XD) też działa:

Generowanie CSR oraz certyfikatów z poziomu Windowsa w oparciu o AD CS

To okazuje się być prostsze, niż mi się wydawało. Przykład, który będę przedstawiał jest najczęściej używanym – chodzi tutaj o wystawianie certyfikatów dla serwerów webowych. W poprzednich poradnikach pokazywałem jak to robić w oparciu o OpenSSL (wykorzystywałem tam Linux Subsystem for Windows), lecz tym razem pokażę jak to zrobić z poziomu MMC (Microsoft Management Console).

Generowanie CSR

CSR (Certificate Signing Request) jest po polsku dosłownie żądaniem podpisania certyfikatu. Aby wygenerować żądanie certyfikatu, musimy mieć klucz prywatny. MMC w ramach generowania MMC tworzy klucz prywatny dla danego CSR. Mając CSR możemy zlecić w urzędzie certyfikacji podpisanie certyfikatu. Następnie taki certyfikat należy zaimportować do miejsca, w którym generowaliśmy CSR. Kwestia klucza prywatnego, o której pisałem wcześniej jest kluczowa. Do prawidłowego działania serwera webowego potrzebujemy mieć:

  • certyfikat serwera,
  • certyfikat urzędu certyfikacji, który podpisał certyfikat (w przypadku, gdy urząd certyfikacji, który podpisał certyfikat nie jest głównym urzędem certyfikacji potrzebne są wszystkie nadrzędne certyfikaty podmiotu wystawiającego certyfikat) – taki certyfikat nazywa się łańcuchem (ang. chain),
  • klucz prywatny użyty do wygenerowania żądania podpisania certyfikatu.

Stąd jeśli maszyna z Windowsem nie jest hostem, na którym będzie wykorzystywany certyfikat, dla którego generujemy CSR lub serwer nie jest w stanie korzystać z magazynu certyfikatów Windowsa (wydaje mi się, że nginx na Windowsie działa tak samo jak na Linuksie, czyli wymaga wskazania ścieżki do pliku certyfikatu serwera, łańcucha i klucza prywatnego, to byłby dobry przykład).

Zabawę zaczynamy od otworzenia Zarządzaj certyfikatami komputerów. Tam, w Certyfikaty – komputer lokalny > Osobisty > Certyfikaty klikamy PPM i wybieramy Wszystkie zadania > Operacje zaawansowane > Utwórz żądanie niestandardowe….

Dajemy Dalej.

W tym menu opcje są dwie: jeśli mamy wdrożone AD CS (Active Directory Certificate Services) to możemy skorzystać z predefiniowanych szablonów z naszego urzędu certyfikacji. Jest to proste i przyjemne, ponieważ my musimy jedynie wypełnić szablon odpowiednimi danymi. Ten szablon ma po prostu uzupełnione parametry potrzebne dla certyfikatu, którego szablon wybierzemy. Ta opcja to Zasady rejestracji usługi Active Directory. W przypadku, gdy nie mamy AD CS lub po prostu chcemy ręcznie zdefiniować od zera parametry certyfikatu – możemy to zrobić poprzez opcję Kontynuuj bez zasad rejestracji. Po wyborze idziemy dalej.

Następnie możemy wybrać szablon certyfikatu, który chcemy wykorzystać do tworzenia CSR. W naszym wypadku będzie to Serwer sieci Web. Format żądania można zostawić w formacie PKCS #10. Idziemy dalej.

Następnie należy rozwinąć szczegóły zasad rejestracji i kliknąć Właściwości.

Następnie, w podmiocie musimy zdefiniować parametry, którymi ma się wyróżniać certyfikat. Najważniejsze parametry to nazwa pospolita (CN), Państwo (C), Miasto (L), Jednostka organizacyjna (OU), województwo/region (S), adres e-mail (E). Ponadto, należy zdefiniować nazwy alternatywne dla certyfikatu i najczęściej to będą nazwy DNS. W przypadku poniżej mam zdefiniowaną tylko 1 nazwę DNS: it.supra.tf wraz ze zdefiniowanymi parametrami podmiotu, którego reprezentuje ten certyfikat.

Następnie w karcie Ogólne powinniśmy zdefiniować przyjazną nazwę, powinna być taka sama jak nazwa pospolita.

Rozszerzeń nie musimy edytować – w przypadku opcji, którą wybrałem tutaj wszystko jest zdefiniowane, lecz pokażę jak powinien być zdefiniowany certyfikat dla serwera webowego. Gdybyśmy jednak zdecydowali się definiować wszystkie parametry rozszerzeń ręcznie, musimy mieć takie opcje zdefiniowane:

Na końcu, w ustawieniach klucza prywatnego musimy wybrać rozmiar klucza. W większości przypadków to będzie 2048 (z faktu, że wybrałem szablon z urzędu, długość klucza jest z góry narzucona). Tutaj też powinno się zaznaczyć opcję Klucz prywatny można eksportować po to, by móc po zaimportowaniu certyfikatu do MMC jakoś go wyeksportować z kluczem prywatnym do dalszego użycia.

Tutaj akurat pole jest wypełnione poprawnie, ale w przypadku typu klucza powinien być zdefiniowany typ Wymiana.

Mając to możemy zapisać plik i najlepiej to zrobić w formacie Base 64, bo możemy wykorzystać taki certyfikat zarówno w przystawce certification authority jak i w serwisie webowym do podpisywania certyfikatów.

Teraz możemy podpisać certyfikat.

Podpisywanie certyfikatu przez serwis webowy

Jeśli mamy zainstalowaną rolę Rejestracja w sieci Web dla urzędu certyfikacji, możemy połączyć się z usługą webową w celu podpisania certyfikatu przez adres http://<fqdn-ca>/certsrv, w moim przypadku http://dc1.serba.local/certsrv. Aby podpisać certyfikat, musimy zalogować się na konto uprawnione do wystawiania certyfikatów. Na pewno takim kontem będzie konto Administrator. Na początku należy wybrać Żądanie certyfikatu.

Następnie należy wybrać zaawansowane żądanie certyfikatu.

Zamiast tego menu może być czasami takie:

Wybieramy opcję Prześlij żądanie certyfikatu, używając pliku CMC lub PKCS #10 szyfrowanego algorytmem base-64 lub prześlij żądanie odnowienia, używając pliku PKCS #7 szyfrowanego algorytmem base-64.

Następnie należy wkleić zawartość CSR (to jest plik tekstowy, można go otworzyć dowolnym edytorem tekstu) do pola Zapisane żądanie i wybieramy Szablon certyfikatuSerwer sieci Web. Po tym przechodzimy dalej i zapisujemy certyfikat w formacie Base-64.

Ta opcja jest super, bo po prostu działa łatwo i szybko. Poza tym ta opcja jest dobra jeśli korzystamy z klucza prywatnego oraz CSR tworzonych w OpenSSL. Co jeśli nie możemy z takiej stronki skorzystać (np. nie możemy postawić serwera webowego na hoście, na którym jest urząd certyfikacji, bo na nim coś pracuje na porcie 80/443)? Wtedy możemy skorzystać z podstawki MMC.

Podpisywanie certyfikatu przez przystawkę w MMC

To jest dosyć proste – otwieramy przystawkę, klikamy na nasz urząd certyfikacji PPM i wybieramy Wszystkie zadania > Prześlij nowe żądanie…, a następnie wskazujemy plik CSR.

Jeśli wszystko jest w porządku (w moim przypadku tak jest, od razu pojawi się okienko do zapisania certyfikatu.

W ten sposób mamy podpisany certyfikat.

Stworzyłem CSR przez OpenSSL, lecz nie mogę podpisać certyfikatu przez MMC, dlaczego? Nie mam stronki do podpisywania certyfikatów.

To dlatego, bo CSR nie zawiera przeznaczenia certyfikatu, czyli do czego on jest. Przynajmniej tak jest najczęściej i tak było w moim przypadku. Rozwiązanie jest takie, by wykonać podpisanie certyfikatu przez Wiersz poleceń z uprawnieniami administratora. Polecenie jest następujące:

certreq -Submit -Attrib "CertificateTemplate:WebServer" -Config "<fqdn-ca>\<nazwa-ca>" nasz-plik.csr

W moim przypadku byłoby to:

certreq -Submit -Attrib "CertificateTemplate:WebServer" -Config "dc1.serba.local\serba-DC1-CA" nasz-plik.csr

W parametrze -Attrib określa się szablon certyfikatu poprzez distinguished name szablonu, nie przez nazwę przyjazną szablonu. Ten przykład jest dla serwera sieci Web. Ten przykład zakłada, że jesteśmy w katalogu, który zawiera nasz-plik.csr. Po wykonaniu polecenia jeśli wszystko jest okej, otworzy nam się okienko, w którym możemy zapisać podpisany certyfikat.

Importowanie podpisanego certyfikatu

W obu przypadkach certyfikat, który otrzymamy mniej więcej wygląda tak:

Aby go importować, należy na komputerze, na którym generowaliśmy CSR go zainstalować poprzez Zainstaluj certyfikat… lub importując certyfikat będąc w osobistym magazynie certyfikatów komputera (skorzystałem z tej opcji):

Następnie należy iść dalej.

Znowu dalej.

Znowu dalej. Właśnie tam ma certyfikat trafić.

I to tyle, na koniec trzeba zamknąć kreator klikając Zakończ.

Po wejściu w certyfikaty komputerów tym razem mamy już podpisany certyfikat w certyfikatach osobistych (widać, że ma klucz prywatny!):

Po tym możemy go wyeksportować, by go gdzieś indziej wykorzystać.

Eksport certyfikatu w celu dalszego użycia

Zaczynamy klikając prawym na certyfikat, następnie Wszystkie zadania > Eksportuj….

Klikamy dalej.

Następnie wybieramy opcję Tak, eksportuj klucz prywatny.

Tutaj pozostawiamy takie opcje, jakie są.

Następnie należy zaznaczyć opcję Hasło oraz wpisać hasło dwukrotnie w pola. Ponadto zalecam wybrać szyfrowanie AES256-SHA256. Po tym idziemy dalej.

Na końcu musimy zapisać plik certyfikatu.

Pod koniec mamy podsumowanie, klikamy Zakończ i cieszymy się wyeksportowanym certyfikatem.

Mamy certyfikat, ale co możemy z nim dalej zrobić?

Zaimportować. 😊 Tak na poważnie – to zależy od tego, do czego chcemy ten certyfikat zaimportować, bo nie każdy serwer WWW akceptuje certyfikaty w formacie PKCS #12 (PFX). W większości przypadków będziemy musieli z tego certyfikatu wyeksportować plik certyfikatu i klucza prywatnego i z tym pomoże nam OpenSSL. Możemy z niego w Windowsie korzystać instalując binarki OpenSSL lub korzystają na Windowsie 10 z Linux Subsystem for Windows. Przyzwyczaiłem się do tego drugiego rozwiązania, ale droga naprawdę w tym przypadku nie ma znaczenia. Mając plik certyfikat.pfx rozwiązanie jest następujące:

Eksport klucza prywatnego:

openssl pkcs12 -in certyfikat.pfx -nocerts -out key.pem -nodes
Enter Import Password:

Eksport certyfikatu:

openssl pkcs12 -in certyfikat.pfx -nokeys -out cert.pem -nodes
Enter Import Password:

Z faktu, że plik PFX był zabezpieczony hasłem, musiałem je podać. W innym wypadku nie ma takiego pytania i po prostu to, co nas interesuje jest eksportowane. Hasło z klucza prywatnego jest usunięte, lecz w pliku jest nagłówek:

Bag Attributes
    Microsoft Local Key set: <No Values>
    localKeyID: 01 00 00 00 
    Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider
    friendlyName: te-WebServer-fbedaf0e-62a3-4c9e-baa1-bfc85280d441
Key Attributes
    X509v3 Key Usage: 10 

Jest on niepotrzebny w przypadku linuksowych usług. Nie wiem jak wygląda to z tymi dotyczącymi Windowsa.

Jestem konsolowcem, nie lubię GUI i lubię robić wiele rzeczy szybko za jednym zamachem, jak zrobić wszystko z konsoli?

W takiej sytuacji można skorzystać z narzędzia certreq w Windowsie, które działa mniej więcej tak samo jak to, co robiliśmy wyżej przez GUI. Na początku, by ułatwić sobie pracę powinniśmy mieć szablon, który umożliwi nam łatwe określenie certyfikatu (tutaj przykład dla innego certyfikatu, nazwa to stormshield.stormshield.local i CA to Stormshield Root CA):

[Version]
Signature="$Windows NT$"

[NewRequest]
;w tym polu określamy dane certyfikatu
Subject = "C=PL, O=it.supra.tf, CN=stormshield.stormshield.local, L=Tychy, S=śląskie, [email protected], OU=IT"
KeySpec = 1
KeyLength = 2048
;klucz jest eksportowalny
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
KeySpec = AT_KEYEXCHANGE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
HashAlgorithm = SHA256

;to jest opcjonalne, ale możemy wcześniej zdefiniować nazwę szablonu, który mamy w urzędzie certyfikacji tak samo jak w kreatorze w GUI
[RequestAttributes]
CertificateTemplate=WebServer

;to jest obowiązkowe - musimy określić do czego będzie służył ten certyfikat
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

;to jest opcjonalne, ale jeśli nie chcemy mieć w Chrome błędów certyfikatu to uznałbym to jako obowiązkowe, dzięki temu możemy określić jakie adresy w przeglądarce są akceptowalne dla tego certyfikatu
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "DNS=stormshield.stormshield.local"
_continue_ = "IPAddress=192.168.40.1&"

Mając taki szablon zapisany w pliku (w moim przypadku w config-csr.txt) można utworzyć CSR za pomocą polecenia:

PS C:\Users\Administrator\Desktop> certreq.exe -new .\config-csr.txt .\request.csr
Zasady rejestracji usługi Active Directory
  {FA379C50-2A4F-409A-8F9E-B714B9E69E35}
  ldap:

CertReq: Request Created

Następnie na serwerze, gdzie jest urząd certyfikacji taki certyfikat podpisujemy:

PS C:\Users\Administrator\Desktop> certreq -Submit -Config "dc1.stormshield.local\Stormshield Root CA" .\request.csr
RequestId: 6
RequestId: "6"
Certificate retrieved(Issued) Issued

Potem na hoście, z którego generowaliśmy CSR importujemy certyfikat:

PS C:\Users\Administrator\Desktop> certreq -accept .\certyfikat.cer
Installed Certificate:
  Serial Number: 5f0000000671797c1d3d008ff8000000000006
  Subject: [email protected], CN=stormshield.stormshield.local, OU=IT, O=it.supra.tf, L=Tychy, S=śląskie, C=PL (Nazwa DNS=stormshield.stormshield.local, Adres IP=192.168.40.1)
  NotBefore: 22.08.2020 12:25
  NotAfter: 22.08.2022 12:25
  Thumbprint: 6bfaa5aee37a34593dad1f034f25514a3497ea58

Na końcu musimy sobie ten certyfikat znaleźć i możemy go wyeksportować w formacie PFX. Szukamy certyfikatu za pomocą polecenia:

Get-ChildItem -Path cert:\localMachine\my


   PSParentPath: Microsoft.PowerShell.Security\Certificate::localMachine\my

Thumbprint                                Subject
----------                                -------
D13B5A05111E4FCE19CB400E2C425E9B763D7337  CN=dc1.stormshield.local
6BFAA5AEE37A34593DAD1F034F25514A3497EA58  [email protected], CN=stormshield.stormshield.local, OU=IT, O=it.supra.tf, L=Tychy, S=śląskie, C=PL
1D6B16F9C60871F370574B2830EAC15276E9528E  CN=Stormshield Root CA, DC=stormshield, DC=local

Tutaj możemy zobaczyć, że certyfikat, który nas interesuje ma odcisk palca 6BFAA5AEE37A34593DAD1F034F25514A3497EA58. Dopisujemy go do ścieżki w Get-ChildItem, dzięki czemu wyszukanie obiektu wskazuje na 1 obiekt:

PS C:\Users\Administrator\Desktop> Get-ChildItem -Path cert:\localMachine\my\6BFAA5AEE37A34593DAD1F034F25514A3497EA58


   PSParentPath: Microsoft.PowerShell.Security\Certificate::localMachine\my

Thumbprint                                Subject
----------                                -------
6BFAA5AEE37A34593DAD1F034F25514A3497EA58  [email protected], CN=stormshield.stormshield.local, OU=IT, O=it.supra.tf, L=Tychy, S=śląskie, C=PL

Teraz taki obiekt należy przypisać do zmiennej. Od razu można przygotować sobie hasło do eksportu certyfikatu, które będzie potrzebne:

$certificate = Get-ChildItem -Path cert:\localMachine\my\6BFAA5AEE37A34593DAD1F034F25514A3497EA58
$mypwd = ConvertTo-SecureString -String "Zaq12wsx!" -Force -AsPlainText

I ostatecznie możemy wyeksportować certyfikat:

PS C:\Users\Administrator\Desktop> Export-PfxCertificate -CryptoAlgorithmOption AES256_SHA256 -ChainOption BuildChain -Password $mypwd -Cert $certificate -FilePath ./certyfikat.pfx


    Directory: C:\Users\Administrator\Desktop


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       22.08.2020     12:46           4636 certyfikat.pfx

Certyfikaty wystawiają mi się na krótko (1-2 lata), jak to zmienić?

Należy w rejestrze zmienić w gałęzi HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Stormshield Root CA zmienić klucz ValidityPeriodUnits na większą wartość, lecz ta nie może być większa od okresu, na które jest wystawiony certyfikat dla CA (domyślnie 5 lat), dlatego ja ustawiłem 4. Po zapisaniu zmian należy zrestartować serwer i po tym można wystawiać certyfikaty na 4 lata.

Dobre reflinki do robienia fajnych rzeczy z konsoli w tym temacie: