Installation einer Zertifizierungsstelle unter Windows Server 2012R2 Teil 1 – Die Offline Root-CA

Ich empfehle Ihnen vorher den Artikel „Grundlegendes einer Zertifizierungsstellen (CA)“ zu lesen. In diesem Artikel beschreibe ich Ihnen wie Sie eine interne Zertifizierungsstelle unter Windows Server 2012R2 einrichten. Wie in dem Artikel über die Grundlagen von Zertifizierungsstellen beschrieben, richte auch ich zuerst eine Offline Root-CA ein. Dafür wird eine Virtuelle Windows Server 2012R2 Maschine benötigt. Diese sollte unter keinen Umständen Mitglied der Domäne sein.

Die Einrichtung der Offline-CA

Es schadet nichts die VM auf einen Aktuellen Updatestand zu bringen. Sobald das geschehen ist, kann die Installation beginnen. Als erstes wird die Rolle „Active Directory-Zertifikatdienste“ installiert.

Wichtig ist das nach der Installation der Zertifizierungsstelle weder der Computername noch die Domänenzugehörigkeit geändert werden kann.

Die benötigten Rollendienste sind bei der Root-CA lediglich die Rolle „Zertifizierungsstelle“

Nach der Installation der Zertifikatsdienste kann die Zertifizierungsstelle ohne Neustart des Computers installiert werden.

Als Anmeldeinformation für die Rollendienste der Offline CA muss das lokale Administrator Konto verwendet werden. Der zu konfigurierende Rollentyp ist hierbei die Zertifizierungsstelle selber.

Da wir gewollter weise über keine Active Directory Mitgliedschaft verfügen, bleibt nur eine „Eigenständige Zertifizierungsstelle“ übrig. Eine „Unternehmenszertifizierungsstelle“ wird später als die untergeordnete Zertifizierungsstelle erstellt.

Die Offline-CA wird als „Stammzertifizierungsstelle“ eingerichtet. Für den privaten Schlüssel sollte ein neuer erstellt werden, und nicht ein vorhandener Verwendet werden.

Die Schlüssellänge sollte möglichst hoch sein. Als Standard wird 2048 Bit vorgegeben, aber es kann auch 4096 Bit ausgewählt werden. Da der Hashalgorithmus „SHA1“ nicht mehr als sicher gilt, verwende ich in meiner Umgebung „SHA512“ aus der Algorithmus Familie „SHA2“. Auch der MD5 Algorithmus der vielen aus der Linux Welt für Prüfsummen bekannt ist, ist nicht mehr sicher. Mehr dazu im Golem Artikel „Hash-Verfahren“.

Als nächstes sollte für die Offline CA ein vernünftiger Name gefunden werden, diesen sehen hinterher alle Clients in ihrem Zertifikatsspeicher. Sinnvoll wäre hier zum Beispiel „Unternehmensname Root-CA“ oder vergleichbares.

Bei der Gültigkeitsdauer ist zu beachten, spätestens nach diesem Zeitraum benötigen sie die Offline-CA zu erneuern der Zertifizierungsstelle. Wichtig ist auch, je länger der Zeitraum, desto grösser ist die Gefahr wenn die Sub-CA kompromittiert wird und die Anwendung das Zertifikat nicht auf Gültigkeit überprüft. Hier sollten Sie genau überlegen wie das Risiko ist, und was Sie mit Ihrer CA vorhaben. Bei mir zuhause, kann ich bei den 5 Jahren die Standard sind bleiben.

Die Datenbankorte können ohne Probleme an dem vorgeschlagenen Ort belassen werden.

Zum Schluss kann alles nochmal geprüft werden, bevor die Zertifizierungsstelle eingerichtet wird. Prüfen Sie es sorgfältig, danach gibt es keinen Weg zurück, außer von vorne anzufangen.

Nach einem kurzen Moment ist die Zertifizierungsstelle eingerichtet.

Nach der Einrichtung der CA müssen noch ein paar Einstellungen in der Zertifizierungsstelle vorgenommen werden. Dazu starten Sie die „Zertifizierungsstelle“-Konsole aus dem Server-Manager.

In den Eigenschaften der Root-CA sollten jetzt die „Certificate Revocation Lists (CRL)“ bzw. im Deutschen die „Zertifikatsperrlisten“ und die „Authority Information Access (AIA)“ bzw. im Deutschen der „Zugriff auf Stelleninformationen“ (Ich lasse die Übersetzung mal unkommentiert) gepflegt werden. Hier sollten Sie gut überlegen in welche Sperrlisten eingetragen werden, so mal ja der Server der Offline CA Offline sein wird. Sinnvoll ist es für die Root-CA dieselben Veröffentlichungspunkte zu Nutzen wie für die Untergeordnete CA. Dafür sollte man sich jetzt schon für einen Computernamen / DNS-Namen für die Sub-CA entscheiden. In kleinen Umgebungen wäre es möglich die Untergeordnete CA auf einen Domänen Controller zu installieren. Dieser würde aber bis zu einer Migration der CA auf seinem Betriebssystem Stand verbleiben und könnte auch nicht heruntergestuft werden. Dies könnte in Zukunft dazu führen das der Domänen Funktion Ebene nicht weiter angehoben werden kann. Ich werde in meiner Umgebung den DNS-Alias „CA“ für die untergeordnete Zertifizierungsstelle verwenden, und trage ihn auch direkt in den DNS ein.

Entsprechend trage ich als Veröffentlichungspunkt „http://ca.adg.local/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crt“ und Aktiviere für den hinzugefügten Punkt die Checkboxen „in Sperrlisten einbeziehen. Wird z. Suche von Deltasperrlisten verwendet“ und „In CDP-Erweiterung des ausgestellten Zertifikats einbeziehen“.

Für den „Zugriff auf Stelleninformationen“ trage ich entsprechend „http://ca.adg.local/certEnroll/<ServerDNSName>_<CaName><CertificateName>.crt“ und aktiviere die Option „In AIA-Erweiterung des ausgestellten Zertifikats einbeziehen“.

Damit die Offline-CA nicht jede Wochen zur Erzeugung einer neuen Sperrliste gestartet werden muss, müssen die folgenden Befehle in eine Eingabeaufforderung die im Administrativen Modus gestartet wurde:

Certutil -setreg CA\CRLPeriod Months
Certutil -setreg CA\CRLPeriodUnits 6
Certutil -setreg CA\CRLOverlapPeriod Weeks
Certutil -setreg CA\CRLOverlapUnit 4
Certutil -setreg CA\CRLDeltaPeriodUnit 0

Als nächstes sollte die Liste der Gespeicherten Zertifikate veröffentlicht werden. Tragen Sie sich die Erneuerung der Sperrliste am besten direkt in den Kalender ein. Ohne eine Gültig Sperrliste verweigert die SUB-CA ihren Dienst.

Als nächstes solle der Inhalt des Ordners „C:\Windows\System32\Certsrv\CertEnroll“ zusammen mit einem Export des Persönlichen Zertifikates (Ohne privaten Schlüssel) der Root-CA in einen Ordner, zur vereinfachten Einrichtung kann er auch über Netzwerk freigegeben werden.

Update:

Alle 3 Teile dieser Serie sind zusammen als PDF auf GitHub zum kostenlosen Download verfügbar.