Archiwa tagu: AD CS

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.

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.