Zweistufige PKI

von Ronny Böttcher · Veröffentlicht 3. Mai 2023 · Aktualisiert 3. Mai 2023

Seiteninhalt

In diesem Beitrag wird eine zweistufige PKI (Zertifizierungsstelle) eingerichtet. Ich orientiere mich hierbei an der dreiteiligen Anleitung von „Frankys Web“:

Was ist eine PKI und was bedeutet „zweistufig“?

Eine zweistufige PKI besteht aus einer Root-CA und einer Sub-CA. Dabei sollte die Root-CA nicht Mitglied der Domäne sein und nach Abschluss der Einrichtung heruntergefahren und vom Netzwerk getrennt sein. Die Root-CA kann dabei sowohl eine physikalische als auch eine virtuelle Maschine sein, da auf ihr die privaten Schlüssel für das Zertifikat der Root-CA liegen. Die Root-CA wird lediglich verwendet, um im weiteren Verlauf die Echtheit der Sub-CA zu bestätigen (also zum Signieren des Sub-CA-Zertifikates), die eigentlichen Zertifikate werden dann später von der Sub-CA ausgestellt.
Optional kann man für die Root-CA noch ein HSM verwenden (bspw. bietet „YubiKey“ sowas an), mit dem man das Root-CA-Zertifikat erstellt. Hier ist es dann wichtig, dass man neben der Root-CA auch sicherstellt, dass das HSM nicht entwendet werden kann.
Die Sub-CA sollte Mitglied der Domäne sein, das vereinfacht das Ausstellen von Zertifikaten für andere Mitgliedsserver der Domäne wesentlich.

Im Zusammenhang mit der PKI / CA werden diese beiden Abkürzungen geführt:

CRL = Certificate Revoke List
AIA = AuthorityInformationAccess

Vorbereitungen

Es werden zwei VMs angelegt:

PKI01
1. Rolle: „Root-CA“
2. Ressourcen:
  - CPU: 1vCPU
  - RAM: 4GB dynamisch (max. 4GB)
  - DISK: 30GB
  - OS: Windows Server 2022 Standard
3. Nicht in AD gejoined; Stand-Alone
PKI02
1. Rolle: „Sub-CA“
2. Ressourcen:
  - CPU: 1vCPU
  - RAM: 4GB dynamisch (max. 4GB)
  - DISK: 30GB
  - OS: Windows Server 2022 Standard
3. AD joined

Zudem muss sollte man sich vorher Gedanken zu diesen Punkten machen:

Über welche Webadresse sollen CRL & AIA abrufbar sein; nur intern oder auch extern? Dementsprechend notwendige Subdomains anlegen, wie bspw. pki.meine.domain
Welcher Account soll für den „Key Recovery Agent“ verwendet werden – ggfs. anlegen, wenn noch nicht vorhanden. Optimaler Weise ist dies kein persönlicher Account, denn wenn der Mitarbeiter aus dem Unternehmen ausscheidet, wird meistens auch der Account deaktiviert/gelöscht.

PKI01: Root-CA

Zuerst kann unter „C:\Windows“ die Datei „CAPolicy.inf“ angelegt und mit folgendem Inhalt befüllt werden:

[Version]
Signature = "$Windows NT$"
[CRLDistributionPoint]
Empty = true
[AuthorityInformationAccess]
Empty = true
[certsrv_server]
RenewalKeyLength = 4096
RenewalValidityPeriodUnits = 10
RenewalValidityPeriod = years

Hierbei wird festgelegt, dass die CA keine CDP (Sperrlisten) und AIA (AuthoriyInformationAccess) enthält – das ist wichtig, da es sich um eine Offline-Root-CA handelt. Zudem muss der Schlüssel 4096Bit lang sein und maximale Gültigkeit liegt bei 10 Jahren. Best-Practice ist ein Wert zwischen 5 & 20 Jahren. Diese Datei wird bei der gleich folgenden Installation der CA via Server Manager mit eingelesen.
Verwendet man diese Datei nicht, sollte man diese Einstellungen definitiv im Nachgang dann durchführen.

Im nächsten Schritt wird die Server-Rolle inkl. der Features installiert. Hier wird noch gar nicht wirklich etwas konfiguriert, erst danach geht’s so richtig los 😉

Nach Abschluss der Rolleninstallation folgt die Konfiguration der Root-CA.

Die ersten Schritte sind recht einfach, da kaum eine echte Auswahl besteht.

Credentials: HOST\Administrator (des Servers, der Root-CA wird)
Role Services: Certification Authority
Setup Type: Standalone CA
CA Type: Root CA
Private Key: Create a new private key

Jetzt wird es zum ersten Mal spannend. Da „SHA1“ als geknackt gilt, sollte man irgendeines der höheren verwenden, bspw. „SHA256“ oder „SHA384“ oder „SHA512“. Ebenso sollte bei der Schüssellänge mindestens „2048“ verwendet werden. Es gibt allerdings bereits Security-Tools, die dies als unsicher sehen und man besser jetzt schon „4096“ auswählen sollte.

Also:

Cryptography:
- Provider: RSA#Microsoft Software Key Storage Provider
- Key length: 4096
- Hash algorithm: SHA512
CA Name: „DEMOLABOR-Root-CA“ (Der Name ist frei wählbar, allerdings sollte der Hostname nicht Bestandteil sein)
Validation period: „20 years“ – das ist vollkommen okay, denn die Root-CA wird später (weil bei ihr der private Schlüssel liegt) heruntergefahren und ist nicht erreichbar.

Die weiteren Dinge bleiben beim Standard, laufen schnell durch und schon hat man eine Root-CA.

Danach im „ADSI-Editor“ (findet man bspw. auf dem Domain-Controller im Server-Manager im Menü „Tools“) die Konfiguration anzeigen lassen und den „CN“ rauskopieren. Hier in meiner Demo-Labor-Umgebung ist das:

CN=Configuration,DC=DEMOLABOR,DC=intern

Diese Information wird für das nachfolgende Kommandozeilen-Skript (nicht PowerShell!) benötigt:

net stop certsvc
certutil -setreg CA\DSConfigDN "CN=Configuration,DC=DEMOLABOR,DC=intern"
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "years"
certutil -setreg CA\AuditFilter 127
certutil -setreg CA\CRLPeriodUnits 1
certutil -setreg CA\CRLPeriod "years"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "days"
::CRL-Publizierung, %%10 bedeutet, dass es sich bei dem Objekt um ein CRL-Publication-Point handelt
certutil -setreg CA\CRLPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10:LDAP:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n2:http://pki.demolabor.network/cert/%%3%%8%%9.crl"
::AIA-Extension-URLs, %%11 bedeutet, dass es sich bei dem Objekt um einen AIA-Objekt handelt.
certutil -setreg CA\CACertPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:LDAP:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://pki.demolabor.network/cert/%%1_%%3%%4.crt"
net start certsvc

Übersicht der Anpassungen:

Zeile 2: certutil -setreg CA\DSConfigDN „CN=Configuration,DC=DEMOLABOR,DC=intern„
Zeile 11: certutil -setreg CA\CRLPublicationURLs „1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10:LDAP:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n2:http://pki.demolabor.network/cert/%%3%%8%%9.crl“
Zeile 13: certutil -setreg CA\CACertPublicationURLs „1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:LDAP:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://pki.demolabor.network/cert/%%1_%%3%%4.crt“

Erklärung dazu:

Da die Root-CA keine AD-Anbindung hat, muss der Hinweis auf die AD-Configuration manuell erfolgen
Möchte man die CRL für Clients verfügbar machen, die nicht in der AD sind, kann man hier einen (externe) Webadresse angeben
Möchte man die AIA für Clients verfügbar machen, die nicht in der AD sind, kann man hier einen (externe) Webadresse angeben

Ich habe die Befehle in ein Skript („CA-CMD.bat“) gepackt und dann in der administrativen CMD ausgeführt; Ergebnis:

Microsoft Windows [Version 10.0.20348.169]
(c) Microsoft Corporation. All rights reserved.

C:\Users\Administrator>C:\Users\Administrator\Desktop\CA-CMD.bat

C:\Users\Administrator>net stop certsvc
The Active Directory Certificate Services service is stopping.
The Active Directory Certificate Services service was stopped successfully.


C:\Users\Administrator>certutil -setreg CA\DSConfigDN "CN=Configuration,DC=DEMOLABOR,DC=intern"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Root-CA\DSConfigDN:

New Value:
  DSConfigDN REG_SZ = CN=Configuration,DC=DEMOLABOR,DC=intern
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Users\Administrator>certutil -setreg CA\ValidityPeriodUnits 10
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Root-CA\ValidityPeriodUnits:

Old Value:
  ValidityPeriodUnits REG_DWORD = 1

New Value:
  ValidityPeriodUnits REG_DWORD = a (10)
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Users\Administrator>certutil -setreg CA\ValidityPeriod "years"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Root-CA\ValidityPeriod:

Old Value:
  ValidityPeriod REG_SZ = Years

New Value:
  ValidityPeriod REG_SZ = years
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Users\Administrator>certutil -setreg CA\AuditFilter 127
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Root-CA\AuditFilter:

New Value:
  AuditFilter REG_DWORD = 7f (127)
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Users\Administrator>certutil -setreg CA\CRLPeriodUnits 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Root-CA\CRLPeriodUnits:

Old Value:
  CRLPeriodUnits REG_DWORD = 1

New Value:
  CRLPeriodUnits REG_DWORD = 1
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Users\Administrator>certutil -setreg CA\CRLPeriod "years"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Root-CA\CRLPeriod:

Old Value:
  CRLPeriod REG_SZ = Weeks

New Value:
  CRLPeriod REG_SZ = years
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Users\Administrator>certutil -setreg CA\CRLDeltaPeriodUnits 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Root-CA\CRLDeltaPeriodUnits:

Old Value:
  CRLDeltaPeriodUnits REG_DWORD = 0

New Value:
  CRLDeltaPeriodUnits REG_DWORD = 0
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Users\Administrator>certutil -setreg CA\CRLDeltaPeriod "days"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Root-CA\CRLDeltaPeriod:

Old Value:
  CRLDeltaPeriod REG_SZ = Days

New Value:
  CRLDeltaPeriod REG_SZ = days
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Users\Administrator>certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n10:LDAP:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n2:http://pki.demolabor.network/cert/%3%8%9.crl"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Root-CA\CRLPublicationURLs:

Old Value:
  CRLPublicationURLs REG_MULTI_SZ =
    0: 65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl
    CSURL_SERVERPUBLISH -- 1
    CSURL_SERVERPUBLISHDELTA -- 40 (64)

    1: 8:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10
    CSURL_ADDTOCRLCDP -- 8

    2: 0:http://%1/CertEnroll/%3%8%9.crl

    3: 6:file://%1/CertEnroll/%3%8%9.crl
    CSURL_ADDTOCERTCDP -- 2
    CSURL_ADDTOFRESHESTCRL -- 4


New Value:
  CRLPublicationURLs REG_MULTI_SZ =
    0: 1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl
    CSURL_SERVERPUBLISH -- 1

    1: 10:LDAP:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10
    CSURL_ADDTOCERTCDP -- 2
    CSURL_ADDTOCRLCDP -- 8

    2: 2:http://pki.demolabor.network/cert/%3%8%9.crl
    CSURL_ADDTOCERTCDP -- 2

CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Users\Administrator>certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:LDAP:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.demolabor.network/cert/%1_%3%4.crt"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Root-CA\CACertPublicationURLs:

Old Value:
  CACertPublicationURLs REG_MULTI_SZ =
    0: 1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt
    CSURL_SERVERPUBLISH -- 1

    1: 0:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11

    2: 0:http://%1/CertEnroll/%1_%3%4.crt

    3: 2:file://%1/CertEnroll/%1_%3%4.crt
    CSURL_ADDTOCERTCDP -- 2


New Value:
  CACertPublicationURLs REG_MULTI_SZ =
    0: 1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt
    CSURL_SERVERPUBLISH -- 1

    1: 2:LDAP:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11
    CSURL_ADDTOCERTCDP -- 2

    2: 2:http://pki.demolabor.network/cert/%1_%3%4.crt
    CSURL_ADDTOCERTCDP -- 2

CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Users\Administrator>net start certsvc
The Active Directory Certificate Services service is starting.
The Active Directory Certificate Services service was started successfully.


C:\Users\Administrator>

Nach dem Ausführen o.g. Befehle bzw. des Skriptes muss die Sperrliste erneut veröffentlicht werden, ansonsten gibt es beim Import der bereits vorhandenen Sperrliste („DEMOLABOR-Root-CA.crl“) eine Fehlermeldung!

Um diese Fehlermeldung auf der Sub-CA zu vermeiden…

Danach müssen die Sperrliste und das Root-CA-Zertifikat von „C:\Windows\System32\CertSrv\CertEnroll“ auf den Server kopiert werden, der Sub-CA werden soll. Das kann entweder der TEMP-Ordner unter C:\ sein, oder direkt der Ordner „C:\Shares\cadata“ (welcher im Server Manager als Share „cadata“ angelegt wird.

Jetzt geht’s weiter mit der Installation der Sub-CA …

PKI02: Sub-CA

Beide gerade auf den Server für die Sub-CA kopierte Dateien (1x .crl & 1x .crt) müssen im AD veröffentlicht werden. Hier wird erneut die CMD („Kommandozeile“) gestartet und folgende Befehle im Pfad, in dem diese beiden Dateien liegen, ausgeführt:

certutil –dspublish –f PKI01_DEMOLABOR-Root-CA.crt Rootca

certutil –dspublish –f DEMOLABOR-Root-CA.crl
gpupdate /force

Anschließend erfolgt auch hier die Installation der Rollendienste.

Darauf folgt die Konfiguration der Zertifikatsdienste.

Wichtig ist, dass man dies mit einem Account macht, welcher „Enterprise Admin“ ist. Der wesentliche Unterschied zur Root-CA ist, dass die Sub-CA als „Enterprise CA“ installiert wird, sodass die AD-Services für ein einfacheres Zertifikatsmanagement verwendet wird. Ebenso wichtig ist, dass beim Generieren des privaten Schlüssels die höchstmögliche Sicherheit verwendet wird – also 4096bit Länge und SHA512.

Beim „Common name“ wird der Hostname entfernt & durch „Sub“ ersetzt und ich persönlich stelle noch eine „-01“ ans Ende. Also:

aus „DEMOLABOR-PKI02-CA“
wird „DEMOLABOR-Sub-CA-01„

Direkt danach muss man ein Zertifikats-Request erstellen. Ich persönlich passe den Namen der Request-Datei direkt nach obigem Schema an, also

aus „C:\PKI02.DEMOLABOR.intern_DEMOLABOR-PKI02-CA.req“
wird „C:\PKI02.DEMOLABOR.intern_DEMOLABOR-Sub-CA-01.req“

Die nächsten Dialoge können mit <Next> bestätigt werden. Nach Abschluss der Konfiguration erscheint eine Warnung, aber die ist normal, denn sie weißt lediglich darauf hin, dass man mit dem Zertifikats-Request nun bei der Root-CA eben ein Zertifikat ausstellen lassen und dieses dann in der Sub-CA importieren soll.

Jetzt also den Zertifikats-Request vom Server der Sub-CA auf den Server der Root-CA kopieren. dann im „Server Manager“ der Root-CA in Tools die „Certification Authority“ aufrufen, dort einen Rechtsklick auf die Root-CA machen und mit „Submit new request“ die Datei wählen. Jetzt findet sich unter „Pending Requests“ ein neuer Eintrag, welcher mit Rechtsklick und „All Tasks > Issue“ genehmigt werden kann. Anschließend findet sich unter „Issued Certificates“ das Zertifikat für die Sub-CA. Mit einem Doppelklick kann man sich die Eigenschaften anschauen und im Reiter „Details“ dann über den Button „Copy to File“ auch exportieren, denn wir müssen dies ja nun in die Sub-CA eintragen.

Im nächsten Schritt muss die Sub-CA konfiguriert werden; das lässt sich am einfachsten per Skript lösen, so wie es bereits bei der Root-CA gemacht wurde. Die Info für „DSConfigDN“ ist aus dem Teil oben noch bekannt, ansonsten einfach nochmal im ADSI-Editor nachschauen.

Diese Information wird für das nachfolgende Kommandozeilen-Skript (nicht PowerShell!) benötigt:

net stop certsvc
certutil -setreg CA\DSConfigDN "CN=Configuration,DC=DEMOLABOR,DC=intern"
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "years"
certutil -setreg CA\AuditFilter 127
certutil -setreg CA\CRLPeriodUnits 3
certutil -setreg CA\CRLPeriod "days"
certutil -setreg CA\CRLDeltaPeriodUnits 12
certutil -setreg CA\CRLDeltaPeriod "hours"
::CRL-Publizierung
certutil -setreg CA\CRLPublicationURLs "65:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:LDAP:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n6:http://pki.demolabor.network/cert/%%3%%8%%9.crl"
::AIA-Extension-URLs
certutil -setreg CA\CACertPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:LDAP:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://pki.demolabor.network/cert/%%1_%%3%%4.crt"
net start certsvc

Die Befehle sehen sehr ähnlich aus, lediglich bei der Zeile für die „CRLPublicationsURLs“ ist ganz am Ende noch „\n65:file://\\pki.demolabor.intern\cadata\%%3%%8%%9.crl““ hinzugekommen, damit werden die Sperrlisten auch auf dem Netzlaufwerk veröffentlicht.

Übersicht der Anpassungen:

Zeile 2: certutil -setreg CA\DSConfigDN „CN=Configuration,DC=DEMOLABOR,DC=intern„
Zeile 11: certutil -setreg CA\CRLPublicationURLs „1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10:LDAP:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n2:http://pki.demolabor.network/cert/%%3%%8%%9.crl“
Zeile 13: certutil -setreg CA\CACertPublicationURLs „1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:LDAP:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://pki.demolabor.network/cert/%%1_%%3%%4.crt“

Ich habe die Befehle in ein Skript („CA-CMD.bat“) gepackt und dann in der administrativen CMD ausgeführt; Ergebnis:

Microsoft Windows [Version 10.0.20348.169]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\system32>C:\Users\temp.admin\Desktop\Sub-CA-CMD.bat

C:\Windows\system32>certutil -setreg CA\DSConfigDN "CN=Configuration,DC=DEMOLABOR,DC=intern"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Sub-CA-01\DSConfigDN:

Old Value:
  DSConfigDN REG_SZ = CN=Configuration,DC=DEMOLABOR,DC=intern

New Value:
  DSConfigDN REG_SZ = CN=Configuration,DC=DEMOLABOR,DC=intern
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Windows\system32>certutil -setreg CA\ValidityPeriodUnits 5
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Sub-CA-01\ValidityPeriodUnits:

Old Value:
  ValidityPeriodUnits REG_DWORD = 2

New Value:
  ValidityPeriodUnits REG_DWORD = 5
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Windows\system32>certutil -setreg CA\ValidityPeriod "years"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Sub-CA-01\ValidityPeriod:

Old Value:
  ValidityPeriod REG_SZ = Years

New Value:
  ValidityPeriod REG_SZ = years
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Windows\system32>certutil -setreg CA\AuditFilter 127
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Sub-CA-01\AuditFilter:

New Value:
  AuditFilter REG_DWORD = 7f (127)
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Windows\system32>certutil -setreg CA\CRLPeriodUnits 3
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Sub-CA-01\CRLPeriodUnits:

Old Value:
  CRLPeriodUnits REG_DWORD = 1

New Value:
  CRLPeriodUnits REG_DWORD = 3
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Windows\system32>certutil -setreg CA\CRLPeriod "days"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Sub-CA-01\CRLPeriod:

Old Value:
  CRLPeriod REG_SZ = Weeks

New Value:
  CRLPeriod REG_SZ = days
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Windows\system32>certutil -setreg CA\CRLDeltaPeriodUnits 12
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Sub-CA-01\CRLDeltaPeriodUnits:

Old Value:
  CRLDeltaPeriodUnits REG_DWORD = 1

New Value:
  CRLDeltaPeriodUnits REG_DWORD = c (12)
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Windows\system32>certutil -setreg CA\CRLDeltaPeriod "hours"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Sub-CA-01\CRLDeltaPeriod:

Old Value:
  CRLDeltaPeriod REG_SZ = Days

New Value:
  CRLDeltaPeriod REG_SZ = hours
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Windows\system32>certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n79:LDAP:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n6:http://pki.demolabor.network/cert/%3%8%9.crl\n65:file://pki.demolabor.intern\cadata\%3%8%9.crl"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Sub-CA-01\CRLPublicationURLs:

Old Value:
  CRLPublicationURLs REG_MULTI_SZ =
    0: 65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl
    CSURL_SERVERPUBLISH -- 1
    CSURL_SERVERPUBLISHDELTA -- 40 (64)

    1: 79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10
    CSURL_SERVERPUBLISH -- 1
    CSURL_ADDTOCERTCDP -- 2
    CSURL_ADDTOFRESHESTCRL -- 4
    CSURL_ADDTOCRLCDP -- 8
    CSURL_SERVERPUBLISHDELTA -- 40 (64)

    2: 0:http://%1/CertEnroll/%3%8%9.crl

    3: 0:file://%1/CertEnroll/%3%8%9.crl


New Value:
  CRLPublicationURLs REG_MULTI_SZ =
    0: 65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl
    CSURL_SERVERPUBLISH -- 1
    CSURL_SERVERPUBLISHDELTA -- 40 (64)

    1: 79:LDAP:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10
    CSURL_SERVERPUBLISH -- 1
    CSURL_ADDTOCERTCDP -- 2
    CSURL_ADDTOFRESHESTCRL -- 4
    CSURL_ADDTOCRLCDP -- 8
    CSURL_SERVERPUBLISHDELTA -- 40 (64)

    2: 6:http://pki.demolabor.network/cert/%3%8%9.crl
    CSURL_ADDTOCERTCDP -- 2
    CSURL_ADDTOFRESHESTCRL -- 4

    3: 65:file://pki.demolabor.intern\cadata\%3%8%9.crl
    CSURL_SERVERPUBLISH -- 1
    CSURL_SERVERPUBLISHDELTA -- 40 (64)

CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Windows\system32>certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n3:LDAP:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.demolabor.network/cert/%1_%3%4.crt"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DEMOLABOR-Sub-CA-01\CACertPublicationURLs:

Old Value:
  CACertPublicationURLs REG_MULTI_SZ =
    0: 1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt
    CSURL_SERVERPUBLISH -- 1

    1: 3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11
    CSURL_SERVERPUBLISH -- 1
    CSURL_ADDTOCERTCDP -- 2

    2: 0:http://%1/CertEnroll/%1_%3%4.crt

    3: 0:file://%1/CertEnroll/%1_%3%4.crt


New Value:
  CACertPublicationURLs REG_MULTI_SZ =
    0: 1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt
    CSURL_SERVERPUBLISH -- 1

    1: 3:LDAP:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11
    CSURL_SERVERPUBLISH -- 1
    CSURL_ADDTOCERTCDP -- 2

    2: 2:http://pki.demolabor.network/cert/%1_%3%4.crt
    CSURL_ADDTOCERTCDP -- 2

CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

C:\Windows\system32>

Danach die „Certification Authority“ im Server Manager der Sub-CA starten und das CA-Zertifikat installieren. Die Sub-CA läuft jetzt und man sollte direkt danach in die „Certificate Templates“ wechseln und alle Vorlagen löschen, ansonsten kann es passieren, dass sich Anwender selbst Zertifikate ausstellen (bspw. für Dateiverschlüssung (EFS) oder Bitlocker und dann kein Administrator mehr an diese Daten kommt); optional kann „Domain Controller Authentication“ drin bleiben.

Installation des Webdienstes für CRL & AIA, sowie Zertifikatsanforderung & -ausstellung

Sofern noch nicht geschehen, sollte jetzt im DNS und/oder externen Provider die notwendige Subdomain „pki.“ angelegt werden. Im Beispiel der DEMO-Umgebung werden folgende verwendet:

pki.demolabor.network -> Webabruf via extern und intern
pki.demolabor.intern -> UNC-Abruf intern

Beide Pfade wurden mit den o.g. Scripten eingetragen, das kann nochmal in der Management Console nachgeschaut werden.

In der Demoumgebung wurde mittels Server Manager das Verzeichnis als Share angelegt. Anschließend kann die Sperrliste veröffentlicht werden.

Wenn die Fehlermeldung „Directory Invalid“ erscheint, dann kann die SubCA nicht auf das Share zugreifen. In meinem Fall habe ich bei CLR & AIA die Pfade zu „\\pki.demolabor.intern\cadata\…“ rausgenommen und dann erneut veröffentlicht. Die Dateien liegen dann unter „C:\Windows\System32\CertSrv\CertEnroll“ und müssen einmal manuell nach „\\pki.demolabor.intern\cadata\“ (bzw. in meinem Fall lokal unter „C:\Shares\cadata“) abgelegt werden.
Sofern vorher noch nicht geschehen, sollte spätestens jetzt auf der Root-CA ebenfalls die CRL & AIA veröffentlicht werden und auf den selben Speicherort abgelegt werden, wie die CRL & AIA der Sub-CA.

Danach wird per Assistent im Server Manager der Webserver installiert. Die Management-Tools werden gleich mit installiert, alle weiteren Dialoge können mit „Next“ in den Standardeinstellungen übernommen werden.

Anschließend im Menü „Tools“ im Server Manager den „IIS Manager“ starten; hier ein neues virtuelles Verzeichnis über das Kontextmenü auf „Default Web Site“ erstellen. Dann den Alias „cert“ (bzw. was weiter oben als Web-URL-Pfad eben gewählt wurde) und den Ordnerpfad (in der DEMO-Umgebung „C:Shares\cadata“) eintragen.
Danach im virtuellen Verzeichnis auf der rechten Seite die Kachel „Request Filtering“ (im deutschen System „Anforderungsfilterung“) auswählen, danach auf der rechten Seite auf „Edit Feature Settings…“ klicken. Im Dialog dann die Option „Allow double escaping“ wählen und auf <OK> klicken.

In der „pkiview.msc“ sollten nun alle Einträge den Status „OK“ haben.

Die Erreichbarkeit kann man dann ganz einfach im Browser probieren, bspw. mit diesen Links (der DEMO-Umgebung):

http://pki.demolabor.intern/cert/DEMOLABOR-Root-CA.crl
http://pki.demolabor.intern/cert/PKI02.DEMOLABOR.intern_DEMOLABOR-Sub-CA-01.crt

In beiden Fälle sollte der Browser die jeweilige Datei herunterladen. Ist der Webserver auch von außen erreichbar, sollte der Abruf über diese URLs (der DEMO-Umgebung) funktionieren:

http://pki.demolabor.network/cert/DEMOLABOR-Root-CA.crl
http://pki.demolabor.network/cert/PKI02.DEMOLABOR.intern_DEMOLABOR-Sub-CA-01.crt

Anschließend folgt die Installation der Rolle „Certification Authority Web Enrollment“ (CAWeb) über den Server Manager. Es werden die Management-Tools mitinstalliert, alle anderen Dinge können in der Standardeinstellung übernommen werden. Nach Abschluss der Installation erfolgt die Grundkonfiguration, die über den blauen Link „Configure Active Directory Certificate Services…“ gestartet wird. Hier gibt es im Prinzip keine besonderen Dinge zu beachten, alles wichtige steht in den Dialogen selbst drin. D.h. für die Einrichtung muss mindestens ein Account mit Mitgliedschaft der lokalen Administratoren sein und da nur eine Komponente installiert wurde, wird diese ausgewählt, danach geht es mit <Next> & <Configure> weiter.

Tags: HowTo PKI Security

Ronny Böttcher

Microsoft-Systemadministrator seit 2007 und seit 2021 als IT-Consultant bei Bechtle in Deutschland am Standort Mannheim; alle bisherigen Stationen siehe bei "Über mich". In seiner Freizeit bei der Feuerwehr und Modellbahner, zudem gerne am Kochen/Grillen - oder am Essen 😁

Torsten Palitza sagt:

18. April 2024 um 15:37 Uhr

6

Like it now
Hallo Ronny,

vielen Dank für deine Anleitung. Ich habe dennoch eine Frage bzw. Verständnisproblem. Nachdem auf dem PKI01 die CA-CMD.bat ausgeführt wurde, sprichst du davon, dass die Sperrliste erneut veröffentlicht werden muss. Soll das vermutlich auch auf dem PKI01 geschehen? Und im Anschluss soll dann die Sperrliste und das Root-CA von PKI01, die sich in „C:\Windows\System32\CertSrv\CertEnroll“ befinden, auf PKI02 kopiert und anschließend veröffentlicht werden?

Falls ich das richtig verstanden habe, habe ich folgendes Problem auf PKI01 und dem Veröffentlichen der neuen Sperrliste:
certutil -dspublish -f Demo-Root-CA.crl ldap:///CN=Demo-Root-CA,CN=PKI01,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=Demo,DC=de?certificateRevocationList?base?objectClass=cRLDistributionPoint?certificateRevocationList CertUtil: -dsPublish command FAILED: 0x80070547 (WIN32: 1351 ERROR_CANT_ACCESS_DOMAIN_INFO) CertUtil: Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied.

Antworten
- Ronny Böttcher sagt:
  
  1. Juni 2024 um 19:40 Uhr
  
  8
  
  Like it now
  Hallo Torsten,
  
  vielen Dank für deine Frage.
  
  Es muss einmal auf der RootCA (in meinem Beispiel „PKI01“) gemacht werden, sodass ggfs. gesperrte SubCA-Zertifikate bekannt gemacht werden. Klar, beim Neuaufbau gibt es keine gesperrten SubCA-Zertifikate, daher ist die Liste dann quasi leer. Die Dateien werden dann von PKI01 aus dem Pfad „C:\Windows\System32\CertSrv\CertEnroll“ nach PKI02 kopiert und dort wird dann certutil -dspublish -f Demo-Root-CA.crl ausgeführt, um die Sperrliste der RootCA in die AD zu Importieren
  
  Ich hoffe, ich habe damit deine Frage beantworten können.
  
  Viele Grüße
  Ronny 😉
  
  Antworten
Thorsten Kallenborn sagt:

25. August 2023 um 9:00 Uhr

21

Like it now
Hallo,
super Artikel 😊, ich stelle mir die Frage ob ich meinen DC als Sub-CA einrichten soll.
Ist das zu empfehlen oder eher nicht?
Für eine Antwort wäre ich dankbar.

VG

Antworten
- Ronny Böttcher sagt:
  
  29. August 2023 um 17:10 Uhr
  
  21
  
  Like it now
  Hallo,
  vielen Dank für die Rückmeldung.
  
  Also Microsofts Best-Practice ist, dass auf einem DC keine weiteren Rollen laufen sollten. Ich würde die Sub-CA als Member-Server einrichten und nicht direkt auf dem DC. Ein Grund ist bspw. Upgrade des DCs, dann muss man auch direkt die Sub-CA anpacken und man hat dann unnötige Abhängigkeiten geschaffen. In vielen Unternehmen werden eh Windows Server Datacenter-Lizenzen verwendet und dann ist die Menge der VMs eh egal – d.h. ein Windows-Server mehr, macht’s dann auch nicht umständlicher.
  
  Ich hoffe, ich konnte bei der Entscheidung weiterhelfen 😉
  
  Viele Grüße
  Ronny
  
  Antworten

Schreibe einen Kommentar Antworten abbrechen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Zweistufige PKI

4 Antworten

Schreibe einen Kommentar Antworten abbrechen

Häufig aufgerufene Artikel

Über mich

Schlagwort-Auswahl

👨🏼‍⚖️ Rechtlicher Hinweis 👩🏼‍⚖️

Zufälliger Spruch

Der Renten-Counter 😉