PKI von der Stange Secorvo White Paper Aufbau einer ...

© Secorvo Security Consulting GmbH
4.1.5 Export und Publikation von Root-CA-Zertifikat und -CRL
Das CA-Zertifikat der Root-CA muss als Vertrauensanker im AD publiziert werden.
Zusätzlich wird eine aktuelle, gültige CRL der Root-CA im AD benötigt. Dazu müssen diese
beiden Datenelemente als Dateien über einen Transfer-Datenträger (bspw. ein USB-Stick)
von der offline betriebenen Root-CA ins AD übertragen werden.
Hierzu muss zunächst der lokale Administrator der Root-CA den Transfer-Datenträger
anschließen und das Kommandozeilen-Skript export_ca_crl.cmd (siehe Anhang A.1.3)
aufrufen.
Danach ist der Transfer-Datenträger auf vertrauenswürdigem Wege 9 einem Enterprise-
Administrator des AD zu übergeben, der ihn anschließt und das Kommandozeilen-Skript
import_ca_crl.cmd (siehe Anhang A.2.3) aufruft.
Nach dem erfolgreichen erstmaligen Import wird das Root-CA-Zertifikat im AD publiziert; ggf.
ist dabei eine Karenzzeit für die Replikation auf alle Domain Controller einzuplanen. Danach
übernehmen alle an das AD angeschlossenen Computer beim nächsten (Online-)Neustart
oder Group Policy Refresh dieses Zertifikat als Vertrauensanker in ihren lokalen
Zertifikatsspeicher.
Dieser Ablauf ist regelmäßig rechtzeitig vor Ablauf der CRL der Root-CA zu wiederholen, um
die im AD und per HTTP publizierte Root-CA-CRL zu erneuern.
4.2 Issuing-CA
4.2.1 Systemvoraussetzungen und vorbereitende Schritte
Als Issuing-CA kommt ein ins AD integrierter, online betriebener Server zum Einsatz. Es
sollten die im jeweiligen Unternehmen üblichen Vorkehrungen zur Härtung und physischen
Sicherung von kritischen Windows-Servern zum Einsatz kommen; d. h. in der Regel ein
Betrieb im Rechenzentrum vergleichbar einem Domain Controller.
Der Server kann prinzipiell in einer beliebigen Domäne des AD betrieben werden. Um die
Anzahl der zugriffsberechtigten Domain-Administratoren einzugrenzen, hat es sich als Best
Practice etabliert, Certificate Services in der Root-Domäne des AD oder einer anderen
Domäne zu betreiben, in der kritische Serversysteme aber keine Workstations oder
Endbenutzer angesiedelt sind (sofern eine solche Domäne im betreffenden AD existiert).
Dabei muss kein dedizierter Server zum Einsatz kommen. Im hier beschriebenen
Anwendungsfall können die Certificate Services ohne nennenswerte Leistungseinbußen in
einer Virtualisierungsinstanz oder auf einem vorhandenen Server mit betrieben werden.
Auch der Betrieb auf einem Domain Controller ist grundsätzlich nicht ausgeschlossen, sollte
aber vermieden werden, wenn andere geeignete Server zur Verfügung stehen.
Als Serversoftware kann Windows Server 2003, 2008 oder 2008 R2 eingesetzt werden;
dabei wird jeweils mindestens die Enterprise Edition des Betriebssystems benötigt.
Nachfolgend wird, wie schon bei der Root-CA, von Windows Server 2008 (mit
Bezeichnungen in der englischen Benutzeroberfläche) ausgegangen. Die einzelnen Schritte
und Konfigurationsdateien sind jedoch auch auf die anderen Server-Betriebssysteme
übertragbar. Um eine CA auf einem Windows Server 2008 oder 2008 R2 in einem Windows-
9 Hier ist eine unternehmensspezifisch geeignete organisatorische Regelung zu etablieren, um
sicherzustellen, dass die Daten unverfälscht übertragen werden, bspw. durch persönliche
Übergabe zwischen einander bekannten Administratoren.
Secorvo White Paper PKI von der Stange Seite 17 von 43
WP17 PKI von der Stange 08 Stand 02. März 2011