Eigentlich müssten PKIs heute in jedem Unternehmen Standard sein. Doch davon ist man noch weit entfernt. Das liegt einerseits daran, dass PKIs und die Konzepte digitaler Zertifikate wohl zu den am wenigsten verstandenen Technologien in der IT gehören, andererseits aber auch in dem hohen administrativen Aufwand, den PKIs verursachen können.
Microsoft hat ab dem Windows 2000 Server Zertifikatsdienste in das Betriebssystem integriert. Diese waren eine erste Basis aber erst mit dem Windows Server 2003 lassen sie sich wirklich effizient nutzen, von etlichen Verbesserungen in bezug auf die Sicherheit mal ganz abgesehen. Die wichtigste Neuerung ist dabei, dass nicht mehr nur Computer-, sondern auch Benutzerzertifikate automatisch verteilt werden können. Damit wird der administrative Aufwand geringer, auch wenn der Aufbau und Betrieb von PKIs noch keineswegs trivial ist zu komplex sind die Planung und die Sicherheitsüberlegungen.
Wenn man eine PKI für ein Unternehmen aufbauen will, wird man typischerweise mehrere Zertifizierungsstellen einrichten. Diese werden hierarchisch strukturiert, so dass die besonders sicherheitskritische Stammzertifizierungsstelle offline betrieben werden kann, während die Zertifikate dann schnell und möglichst automatisiert über untergeordnete Zertifizierungsstellen erstellt und verteilt werden. Nachfolgend wird nur auf die Einrichtung einer sogenannten Enterprise CA als Stammzertifizierungsstelle des Unternehmens eingegangen. Die Konfiguration aller anderen Varianten ist aber recht ähnlich.
Eine Enterprise CA benötigt den Zugriff auf das Active Directory, weil darin wichtige Informationen abgelegt werden. Die Installation erfolgt über den Bereich Software der Systemsteuerung bei Windows-Komponenten hinzufügen/entfernen. Wer dort Zertifikatsdienste auswählt, findet die Optionen Webregistrierungssupport für Zertifikatsdienste und Zertifizierungsstelle für Zertifikatsdienste.
Die erste Option muss nur auf Systemen eingerichtet werden, bei denen Zertifikate über den Browser angefordert werden dürfen. Dazu muss man allerdings vorher auch die IIS einrichten und ASP aktivieren. Bei Systemen mit IIS und den Zertifikatsdiensten spielt wiederum die Sicherheitskonfiguration eine besondere Rolle, weil dort zusätzliche Schnittstellen geöffnet werden, über die Angriffe erfolgen können.
Nach dem Start des Installationsprozesses muss man den Typ der Zertifizierungsstelle festlegen. Dabei gibt es einerseits die Unterscheidung zwischen Stammzertifizierungsstellen und untergeordneten Zertifizierungsstellen und andererseits zwischen Zertifizierungsstellen des Unternehmens (Enterprise CAs) und eigenständigen Zertifizierungsstellen (Standalone CAs). In grösseren Umgebungen wird man mit einer eigenständigen Stammzertifizierungsstelle arbeiten, die offline betrieben und nur genutzt wird, wenn das CA-Zertifikat erneuert oder eine CRL (Certificate Revocation List) ausgestellt werden muss. Mit letzterer werden Zertifikate für ungültig erklärt, wobei das nur wirksam ist, wenn Anwendungen die CRLs auch verarbeiten.
Die unterste Ebene sind sogenannte Issuing CAs, also die CAs, die Zertifikate ausgeben. Diese werden Online als Enterprise-CA erstellt. Dazwischen kann es noch weitere CAs geben, um mehrere
Issuing CAs zu gruppieren und beispielsweise unterschiedliche Konfigurationsparameter für diese vorzugeben. Auch diese Intermediate CAs werden offline betrieben. Während also in grösseren Unternehmen eine Stammzertifizierungsstelle des Unternehmens eher atypisch ist, wird in kleineren Umgebungen mit geringeren Sicherheitsanforderungen oft nur mit einer CA gearbeitet, die dann eben genau von diesem Typ ist.
Mit der Option Schlüsselpaar und
ein Zertifizierungsstellenzertifikat mit diesen Einstellungen erstellen lässt sich gleich darauf das Schlüsselpaar und das Zertifikat für diese Zertifizierungsstelle erzeugen. Diese Option ist immer dann nötig, wenn man kein vordefiniertes Zertifikat einer anderen CA nutzen kann. Andernfalls wird im nächsten Schritt ein solches Zertifikat importiert und der Kryptografiedienstanbieter (CSP, Cryptography Service Provider) ausgewählt. Hier finden sich einerseits vier CSPs von Microsoft sowie einige vordefinierte Schnittstellen zu Software von Drittanbietern.
Wenn man keine CSP eines Drittanbieters in Verbindung mit spezialisierter Hardware nutzen will, sollte man hier den Microsoft Strong Cryptographic Provider wählen, da dieser den vollen Umfang der Verschlüsselungsfunktionalität bereitstellt. Die anderen CSPs werden nur aus Gründen der Abwärtskompatibilität sowie für Einsatzbereiche geliefert, in denen starke Verschlüsselungsmechanismen nicht genutzt werden dürfen. Die Werte für Hash-Algorithmen und Schlüssellänge sollte man beibehalten.
Im folgenden Dialogfeld muss dann der eindeutige Name für die CA festgelegt werden. Dieser Name wird in das Zertifikat aufgenommen und lässt sich später nicht mehr verändern. Als Suffix dient in der Regel die Domäne, in der sich der Server mit der Zertifizierungsstelle befindet. Die Gültigkeitsdauer des Zertifikats ist beim Windows Server 2003 standardmässig fünf Jahre bei Windows 2000 waren es noch zwei; dieser Wert ist ein Kompromiss zwischen der Sicherheit und dem Administrationsaufwand: Je länger die Gültigkeitsdauer, desto stärker das Risiko, dass der Schlüssel geknackt wird. Bei kürzerer Dauer muss dagegen beispielsweise das Zertifikat der Zertifizierungsstelle öfter erneuert und auf die davon betroffenen Systeme verteilt werden. Wenn keine besonders hohen Sicherheitsanforderungen bestehen, sollte man hier den Standardwert beibehalten.
Schliesslich muss noch die Pfadangabe für die Zertifikatsdatenbank und das Protokoll eingegeben werden. Ausserdem lassen sich die Konfigurationsinformationen noch in einer Freigabe bereitstellen, was aber nur bei alleinstehenden CAs erforderlich ist. Bei Enterprise CAs werden die Informationen im Active Directory abgelegt.
Damit ist die CA eingerichtet und kann genutzt werden. Vorher müssen aber noch Zertifikatsvorlagen angepasst sowie die Webschnittstelle und die automatische Verteilung von Zertifikaten konfiguriert werden mehr darüber im nächsten Heft.
Die Frage, warum man sich eigentlich die Arbeit machen sollte, eine PKI einzurichten, ist eigentlich einfach zu beantworten. Immer mehr Sicherheitsfunktionen wie die Verschlüsselung von E-Mails über S/MIME, sichere Zugriffe auf Intranet-Server mit transparenter Authentifizierung von Benutzern oder der Aufbau sicherer VPN-Verbindungen über IPsec hängen von der Verfügbarkeit digitaler Zertifikate ab. Diese können natürlich von externen Anbietern bezogen werden. Wenn aber viele Clients und Benutzer Zertifikate benötigen, ist der Einsatz einer integrierten Lösung mit automatischer Verteilung wie beim Windows Server 2003 effizienter auch wenn man immer analysieren muss, ob sich damit die Sicherheitsanforderungen erfüllen lassen. Digitale Zertifikate sind letztlich nichts anderes als eine Art «digitaler Personalausweis», der Systeme oder Benutzer identifiziert. Richtig genutzt sind sie komfortabler und sicherer als Kennwörter. Die Zertifikate können auf Smartcards gespeichert und damit einfach transportiert werden und niemand muss sich mehr mit vielen Benutzernamen und Kennwörtern rumschlagen. Zudem gibt es etablierte Standards wie X.509, die von immer mehr Systemen unterstützt werden.
