In Teil 1 wurde die Root-CA installiert, die später offline (also runtergefahren) werden soll. Jetzt kümmern wir uns aber zunächst um die Sub-CA die Active Directory integriert werden soll. Dies ist der zweite Teil der PKI Installation.
Als Erstes wird das Zertifikat und die Sperrliste der Root-CA im Active Directory veröffentlicht. Am einfachsten ist das per CMD:
certutil –dspublish –f FWCA01_FrankysWeb-Root-CA.crt Rootca
certutil –dspublish –f FrankysWeb-Root-CA.crl
Nach einem Neustart des Servers oder „gpupdate /force“ sollte das Zertifikat der Root-CA in dem Speicher für Vertrauenswürdige Stammzertifizierungsstellen sichtbar sein
Wie schon bei der Root-CA, wird auch bei der Sub-CA, zuerst die CAPolicy.inf im Windows Verzeichnis abgelegt. Die CAPolicy hat den folgenden Inhalt
[Version] Signature = "$Windows NT$" [certsrv_server] LoadDefaultTemplates = 0 RenewalKeyLength = 2048 RenewalValidityPeriodUnits = 5 RenewalValidityPeriod = years
Nachdem die CAPolicy.inf im Windows Verzeichnis liegt, kann die Sub-CA installiert werden:
Der Typ der CA ist diesmal „Unternehmen“ und nicht wie bei der Root-CA „Eigenständig“
Da es sich in diesem Fall um eine Sub-CA handelt muss „Untergeordnete Zertifizierungsstelle“ ausgewählt werden
Der Assistent soll einen neuen privaten Schlüssel erstellen
Hier ist es wichtig welche Einstellungen gewählt werden, ich nehme SHA256 und 4096Bit Keylänge. Das sollte eine Weile halten.
Namen der SubCA festlegen:
Und die Zertifikatsanforderung speichern
Der Rest ist wieder „Weiter..Weiter..Fertigstellen“… Diese Warnung am Ende der Installation ist normal, da noch kein gültiges Zertifikat vorhanden ist:
Nachdem die Installation abgeschlossen ist, muss die Zertifikatsanforderung auf die Root-CA kopiert werden. Die Anforderung findet sich unter C:\, bei mir hat die Anforderung den Namen „DC1.frankysweb.local_FrankysWeb-Sub-CA.req“
Mit einem Rechtsklick in der Zerstifizierungsstellen Konsole der Root-CA kann die Anforderung eingereicht werden, dazu wird die Anforderungsdatei ausgewählt.
Jetzt findet sich jetzt ein neuer Eintrag unter „Ausstehende Anforderungen“
Diese Anforderung kann genehmigt werden, indem unter „Alle Aufgaben“ auf „Ausstellen“ geklickt wird.
Unter „Ausgestellte Zertifikate“ findet sich jetzt das Zertifikat der Sub-CA. Mit einem Doppelklick kann es angezeigt werden.
Unter dem Reiter „Details“ lässt es sich in eine Datei kopieren (SubCA.cer). Die Datei kann nun auf die Sub-CA kopiert werden, sie wird später benötigt.
Jetzt wird die SubCA konfiguriert. Dies geschient wieder mit einer Batch-Datei (Achtung: Anpassungen nötig, siehe unten)
:: CA konfigurieren :: www.frankysweb.de :: siehe https://www.frankysweb.de/ :: Configuration Naming Context (Forestroot) certutil -setreg CA\DSConfigDN "CN=Configuration,DC=frankysweb,DC=local" ::Maximale Zertifikatsgltigkeit auf 5 Jahre festlegen (Standard: 2 Jahre) certutil -setreg CA\ValidityPeriodUnits 5 certutil -setreg CA\ValidityPeriod "years" ::Sperrlisten und Deltasperrlisten Veröffentlichungsintervalle konfigurieren ::Sperrliste: Alle 4 Tage ::Delta Sperrliste: Alle 12 Stunden certutil -setreg CA\CRLPeriodUnits 3 certutil -setreg CA\CRLPeriod "days" certutil -setreg CA\CRLDeltaPeriodUnits 12 certutil -setreg CA\CRLDeltaPeriod "hours" ::Pfade für die Sperrlisten konfigurieren 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://ca.frankysweb.de/cert/%%3%%8%%9.crl\n65:file://\\dc1.frankysweb.local\cadata$\%%3%%8%%9.crl" :: Pfade für die 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://ca.frankysweb.de/cert/%%1_%%3%%4.crt" ::Auditing aktivieren certutil -setreg CA\AuditFilter 127
Folgende Anpassungen sind je nach Umgebung nötig:
Zeile 7: Hier muss die Active Directory Konfigurationspartition angegeben werden. Meine AD-Domain heißt frankysweb.local. Daher ist es bei mir „CN=Configuration,DC=frankysweb,DC=local“. Der entsprechende Eintrag lässt sich per ADSI-Edit von einem Domain Controller ermitteln:
Zeile 27 und Zeile 30: Wenn sichergestellt werden soll, dass die Sperrliste auch von externen Clients erreichbar sein soll (Wichtig bei Clients ohne Verbindung zum AD), muss am Ende der Zeile einen Webserver angeben, der aus dem Internet erreichbar ist. Wer nur AD-Mitglieder bedienen muss, kann das Ende der Zeile entfernen (Nicht die ganze Zeile, nur das ab „n2“). Ich empfehle allerdings eine gültige URL einzutragen, später dazu mehr.
Sobald die nötigen Anpassungen durchgeführt wurden kann die Batch Datei ausgeführt werden.
Danach kann das Zertifikat der Sub-CA installiert werden. Dazu wird in der Zertifizierungsstellen MMC der Sub-CA mit einem Rechtsklick auf die CA und dann auf „Alle Aufgaben“ –> „Zertifizierungsstellenzertifikat installieren“ geklickt. Dann wird das Zertifikat der SubCA (SubCA.cer) ausgewählt und installiert:
Nachdem das Zertifikat installiert wurde, kann die CA gestartet werden.
So. Jetzt haben wir eine Sub-CA. Durch die CAPolicy.inf wurde festgelegt, dass keine Standard Vorlagen veröffentlicht werden sollen. Daher ist die Liste der Zertifikatsvorlagen leer:
Somit werden keine Rechner automatisch Zertifikate beantragen und ausgestellt bekommen, es sei denn es wird eine entsprechende Vorlage erstellt. Benutzer können also nicht einfach die EFS-Verschlüsslung oder Bitlocker verwenden, außer wir erstellen eine entsprechende Zertifikatsvorlage und erlauben es den Benutzern. Mit dieser Art der Konfiguration einer PKI, erschlägt man viele Szenarien und behält die Kontrolle für was und welchen Zweck Zertifikate im Unternehmen verwendet werden. Denn nur wenn der Admin eine entsprechende Vorlage mit einem bestimmten Zweck, für eine bestimmte Benutzergruppe erstellt, kann das Zertifikat registriert und genutzt werden. In der „Weiter…Weiter…Fertigstellen“-Installation einer PKI kann jeder Benutzer Verschlüsselung benutzen, ohne entsprechende Key-Recovery Agents lassen sich verschlüsselte Daten aber nicht entschlüsseln, wenn zum Beispiel der Benutzer das Unternehmen verlässt oder der private Schlüssel verloren geht.
Aber wir sind noch nicht ganz fertig, denn es fehlt noch der Download der Sperrlisten via http… (Teil 3)