Archiwum kategorii: PKI

Generowanie Żądania certyfikatu z openssl dla Microsoft Enterprise CA

Opublikowany przez
2

Dawno temu pisałem o tym, jak wygenerować żądanie certyfikatu dla systemów nie będących Windowsami tak, aby dało się certyfikat wystawić na Microsoft Enterprise CA. Jako przykład podałem generowanie certyfikatów serwera vCenter
Niedawno temat powrócił, ale w nowej odsłonie, gdyż serwer vSphere wymaga zdefiniowania w certyfikacie odpowiednich Nazw Alternatywnych. Powstało pytanie, jak pogodzić te dwie funkcjonalności.
Okazuje się to być całkiem proste, trzeba tylko pamiętać, że choć plik konfiguracji openssl pozwala na wiele sekcji opisujących rozszerzenia żądania certyfikatu, to tylko jedna z nich może być wykorzystywana w trakcie generowania certyfikatu. Dlatego przygotowując plik konfiguracyjny dla określonego serwera warto uporządkować jego strukturę, względem propozycji przedstawionej w poprzednim wpisie.
Przykładowy plik konfiguracyjny może wyglądać następująco:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
openssl_conf = openssl_init

[ openssl_init ]
oid_section = new_oids

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ new_oids ]
MsCaCertificateTemplate = 1.3.6.1.4.1.311.20.2

[ v3_req ]
basicContraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:server01, DNS:server01.domena.test
MsCaCertificateTemplate = ASN1:PRINTABLESTRING:VMwareCertificate

[ req_distinguished_name ]
countrName = PL
stateOrProvinceName = Malopolskie
localityName = Krakow
0.organizationName = Firma
organizationalUnitName = Oddzial
commonName = server01.domena.test

Analizując najważniejsze części:

  • Linia 1. Wskazuje na sekcję będącą konfiguracją globalną.
  • Linia 4. Wskazuje na sekcję defniującą OIDy. Linia ta jest jedyną w sekcji konfiguracji globalnej
  • Linia 13. Wskazuje na sekcję definiującą rozszerzenia, które zostaną dodane do żądania certyfikatu
  • Linia 15. Definiuje sekcję z OIDami.
  • Linia 16. Definiuje OID zarejestrowany i użytkowany przez Microsoft do oznaczania rozszerzenia definiującego szablon certyfikatu
  • Linia 22. Definiuje alternatywne nazwy serwera. Należy zwrócić uwagę na fakt, że w przykładzie używany jest prefiks DNS: Możliwe są także inne prefiksy.
  • Linia 23. Definiuje nazwę używanego szablonu certyfikatów. Należy zwrócić uwagę, że wykorzystywany jest wariant nazwy bez żadnych spacji. Nazywa się on „Certificate Template Name”, w przeciwieństwie do nazwy przyjaznej, nazywającej się „Certificate Template Display Name”

Pozostała cześć jest standardowa dla każdego żądania obsługiwanego przez openssl.

Eksport/Import szablonów certyfikatów z AD w Windows 2012

Opublikowany przez
4

Dzisiaj będzie parę słów o imporcie i eksporcie szablonów certyfikatów w Microsoft Active Directory.
Te dane są zapisane w partycji konfiguracji AD i przez to są współdzielone przez wszystkie domeny w obrębie lasu AD.
Czasem jednak zdarzają się sytuacje, kiedy zachodzi potrzeba przeniesienia tych danych między lasami, na przykład przy wdrażaniu testowanego uwcześnie rozwiązania w środowisku przed produkcyjnym do produkcyjnej domeny.
Zadanie takie może być wykonane na dwa różne sposoby. Pierwszy jest oczywisty dla tych, którzy mają z systemem windows duże doświadczenie, ale sposób ten jest brzydki i może powodować duże komplikacje w dzisiejszych systemach. Dlatego omówię go później.
Wraz z nadejściem systemu Windows 2008 R2 została wprowadzona nowa rola AD CS, która nazywa się AD CS Web Enrollment Service.
Służyć ona ma publikacji oraz użytkowaniu CA pomiędzy lasami AD, przy założeniu istnienia jedynie Zewnętrznej relacji zaufania pomiędzy tymi lasami. Więcej na ten temat można znaleźć tutaj.
Na tej samej stronie zostały też zamieszczone dwa świetne skrypty napisane w powershellu, które stanowią istotę dzisiejszego wpisu. Dzięki nim można wyeksportować oraz zaimportować szablony do oraz z plików XML w formacie MS-XCEP.
Niestety, te skrypty posiadają dwa błędy, które ujawniają się w trakcie pracy z systemem Windows 2012:

  1. skrypty zostały napisane jako zwykłe CMD-Let’y, które niestety nie są ładowane w W2k12. Szybkim obejściem tego problemu jest zakomentowanie deklaracji funkcji wraz z zamykającym nawiasem klamrowym na początku i końcu skryptu. Ponadto należy zakomentować deklarację parametrów jako cmd-let binding. Po tych zmianach skrypty uruchamiać się będą w normalny sposób z możliwością podania odpowiednich danych wejściowych, jak jest to wymagane.
  2. Funkcja eksportująca ma w niewłaściwy sposób zrealizowaną obsługę weryfikacji istnienia jednego z tablicowych atrybutów szablonu. Linię:
    1
    $superseded = if ($temp.Settings.SupersededTemplates -eq 0) {

    Należy zastąpić następującą:

    1
    $superseded = if ($temp.Settings.SupersededTemplates.Length -eq 0) {

    Dzięki temu zabiegowi zarówno eksport jak i import przebiegną pomyślnie..

  3. Ostatnią niedogodnością tych skryptów jest zależność od zewnętrznego modułu Power Shell. Ponieważ moduł jest napisany w .NET, na pewno istnieje możliwość wyeliminowania tej zależności, jednak ten temat będzie przedmiotem innego posta.

Wspominana wcześniej „brzydka metoda” to jest stara komenda ldifde wraz z wymaganymi flagami służącymi do eksportu:

1
ldifde -m -v -d cn=%Template1%,%LDAP% -f %Template1%.ldf

Najważniejszą częścią tej komendy jest przełącznik -m, który skutkuje wynikowym plikiem ldf pozbawionym odwołań do obiektów AD Forest.
Żeby zaimportować wygenerowany plik należy użyć bardzo podobnej komendy.:

1
 ldifde -i -k -f %Template1%.ldf

Metoda ta powinna działać dla wszystkich systemów, począwszy od Windows 2000.

Błąd „The AD RMS installation could not determine the certificate hierarchy.” podczas reinstalacji AD RMS

Opublikowany przez
Odpowiedz

Istnieją rzadkie przypadki, kiedy zachodzi konieczność ponownej instalacji klastra RMS. Najczęstszą przyczyną takiej potrzeby jest nieudany proces provisioningu z jakichś prostych powodów, jak na przykład przypisany wcześniej certyfikat SSL do Web Site’a w IIS. Po nieudanym provisioningu należy odinstalować rolę AD RMS i po restarcie maszyny zainstalować ją na nowo. Niestety jednak nie zawsze dochodzi do pełnej deinstalacji usługi. Błąd cytowany w tytule ma opisanych kilka potencjalnych przyczyn i odpowiadających im rozwiązań. Jednak podstawowym problemem jest zawsze konfiguracja serwera w rejestrze. Należy jednak przed dokonaniem zmian w rejestrze upewnić się, że jest to dokładnie ta rzecz, którą chcemy osiągnąć.
Mianowicie omawiany błąd może wystąpić z następujących powodów:

  1. Nieprawidłowy Service Connectin Point – pojawia się w sytuacji, gdy z jakichś powodów w kontenerze CN=SCP, CN=RightManagementService, CN=Services, CN=Configuration, DC=domain, DC=lab pojawia się nieprawidłowy URL do usługi istniejącego już klastra RMSowego. Więcej informacji jedst dostępnych pod tym adresem. Jest to powód bezpośrednio podany w komunikacie błędu na zakończenie kreatora.
  2. Druga przyczyna jest wspominana we wpisie w logu aplikacji skojarzonym z niepowodzeniem provisioningu o numerze 204. Ta przyczyna pochodzi z błędu w rejestrze, ale zachodzi ona z powodu braku jednej wartości. Zgodnie z przytoczonym artykułem wystarczy ten klucz ponownie utworzyć.
  3. W przypadku odrzucenia poprzednich przyczyn należy zweryfikować zawartość gałęzi rejestru HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS. W przypadku gdy występuje tam jakakolwiek wartość, a szczególnie taka, która zawiera odwołanie do nieistniejącego URL, może wystąpić omawiany błąd. Rozwiązaniem jest usunięcie wszystkich kluczy z tej gałęzi rejestru pozostawiając jedynie wartość (default).

W przypadku napotkania innej, nie opisanej tutaj przyczyny dla tego błędu bardzo proszę o pozostawienie komentarza.

Microsoft Enterprise CA nie zezwala na publikację szablonów V2 i V3

Opublikowany przez
1

W pewnych sytuacjach pomimo instalacji Systemu Operacyjnego Windows w wersji Enterprise i konfiguracji roli Active Directory Certificate Services jako Enterprise CA usługa CA nie umożliwia publikacji szablonów certyfikatów w wersjach wyższych niż V1. Dzieje się tak z powodu błędnych wpisów w rejestrze charakteryzujących instalację CA jako Standard.
Okno Publikacji szablonu
Rozwiązaniem problemu braku widoczności szablonów V2 i V3 w okienku dodawania certyfikatów (porównaj z rysunkiem) jest ustawienie flagi w konfiguracji instalacji CA:

1
certutil -setreg ca\setupstatus +512

Po aktualizacji rejestru konieczny jest restart usługi CA.
Ponadto wartym wspomnienia jest fakt, że istnieje możliwość ręcznej edycji listy szablonów za pomocą których CA wydaje certyfikaty. Jest to możliwe przez edycję atrybutu

1
certificateTemplates

w obiekcie

1
pKIEntrollmentService

Obiekty te znajdują się w ścieżce

1
CN=Internal Issuing CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contonso,DC=lab

Instalacja Usług Certyfikacji (CA) na Windows 2008 R2 Core

Opublikowany przez
Odpowiedz

Dzisiaj o czymś zupełnie nowym, ponieważ CA zostało dodane do Windows Core dopiero w wersji R2. Sama opcja instalacji tylko części komponentów nazwana „Core Installation” została udostępniona w wersji 2008.
Na temat Core Installation jest już dość dużo materiałów, na przykład ten artykuł Nataniela Zielińskiego, więc nie będę opisywał go szerzej. Dość powiedzieć że w wersji tej nie ma większości interface’ów graficznych, system zaś obsługuje się z lini poleceń. Istnieje też dobre opracowanie pozwalające ogarnąć Core Installation, jednakże część usług wprowadzonych dopiero w R2 jest nieomal pozbawiona dokumentacji.
Instalacja serwera CA na zwykłym Windows 2008 wymaga użycia kreatora dodawania roli, którego brak w wersji Core. Tak więc pierwszym krokiem jest zainstalowanie binariów usługi. Wykonuje się to poleceniem

1
start /w ocsetup.exe CertificateServices /norestart /quiet

Następnie warto dokonać sprawdzenia poprawności instalacji

1
oclist find /i "CertificateServices"

Po upewnieniu się o tym, że mamy w systemie pakiet usługi, musimy ją skonfigurować. Można to wykonać za pomocą skryptu automatycznej instalacji dostępnego tutaj. Jest to skrypt VBScript który pozwala bez problemowo zainstalować CA. Na stronie podany jest pełen zestaw parametrów koniecznych do ukończenia procesu instalacji pomyślnie. Należy tutaj zwrócić uwagę na fakt, że parametry

1
/interactive

oraz

1
/iw

są nie obsługiwane w Core installation.
Ponaddto przed przystąpieniem do instalacji CA, zarówno w wersji Core jak i zwykłej warto przygotować plik CApolicy.inf który należy umieścić w katalogu %SYSTEMROOT%. Przykład takiego pliku poniżej:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[Version]
Signature="$Windows NT$

[PolicyStatementExtension]
Policies=LegalPolicy

[LegalPolicy]
OID=1.1.1.1.1.1.1.121

NOTICE=Certyfikat wystawiony zgodnie z dokumentem Kodeks_Postepowania_Certyfikacyjnego_Testowe_Domeny
URL="http://pki.testowa.domena.lab/repozytorium/cps.html"

[certsrv_server]
renewalkeylength=2048
RenewalValidityPeriodUnits=5
RenewalValidityPeriod=years
CRLPeriod=days
CRLPeriodUnits=14
CRLOverlapPeriod=days
CRlOverlapUnits=7
CRLDeltaPeriod=hours
CRLDeltaPeriodUnits=0

Po instalacji warto ustawić parametry CDP (CRL Distribution Point) na przykład tak:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
certutil -setreg CA\DSConfigDN CN=Configuration,DC=CCKNF,DC=AD
certutil -setreg CA\CRLPeriodUnits 14
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 7
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Hours"
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:http://pki.testowa.domena.lab/repozytorium/%%3%%8%%9.crl\n65:file://\\%%1\CertEnroll/%%3%%8%%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:http://pki.testowa.domena.lab/repozytorium/%%1_%%3%%4.crt\n1:file://\\%%1\CertEnroll/%%1_%%3%%4.crt"
certutil -setreg CA\AuditFilter 127
certutil -setreg CA\ValidityPeriodUnits 2
certutil -setreg CA\ValidityPeriod "Years"
net stop certsvc & net start certsvc
certutil -crl

Utworzenie takiego, lub podobnego skryptu pozwoli ominięcie „wyklikiwania” za pomocą zdalnie podpiętej konsoli mmc parametrów umieszczanych w certyfikatach.
Na koniec dodam, że pierwszym artykułem który pozwolił rozpocząć pracę z CA na systemie W2K8R2 Core Installation był artykuł Eyalestrin’a.