4.12.2001

PKI - Teil 2

PKI setzt sich im Wesentlichen aus zwei Schlüsseln zusammen. Der Private darf niemals aus der Hand geraten; wenn doch, kann man über die CRL im CA mitteilen lassen, dass der dazugehörige öffentliche Schlüssel nicht mehr gültig ist. Falls der private Schlüssel der CA korrumpiert wurde, müssen alle von ihr ausgestellten Zertifikate gesperrt werden.

W2k-PKI-Komponenten:

W2k bietet die Möglichkeit, eine Zertifizierungsstelle (CA) einzurichten. Weiterhin ist Active Directory zur Veröffentlichung von PKI's in dem System integriert. Programme, die in W2k die PKI-Komponenten nutzen, sind der RAS-Server in Verbindung mit SmartCard-Lesegeräte, der IntenetExplorer mit SSL, OutlookExpress für Mails und NTFS in Verbindung mit EFS. Die Einsätze sind wie schon zum Teil erwähnt für die Verschlüsselung oder Signatur von Mails, für die sichere Kommunikation und Authentifizierung in Benutzung von IPSec oder SSL, EFS für die Dateiverschlüsselung, die Signatur von Skripten (Authenticode) signierte Treiber, uvm.

Zertifizierungsstellen (CA):

Root (oder Stamm) - CA: hat sich selbst ein CA-Zertifikat ausgestellt, höchste Sicherheit, meistens nur für CA-Zertifikate. Firma Kommerz. CA
untergeordnete CA: von übergeordneten CA ausgestelltes Zertifikat, stellt selbst Zertifikate für Endbenutzer aus: z.B. IPSec Firma Firma
  alleinstehende CA Unternehmens CA
Abhängigkeit - unabhängig von Active Directory - benötigt Active Directory (DC, Mitgliedsserver)
Zertifikat an - Zertifikate können auch an Benutzer und Rechner ausserhalb vergeben werden. - Zertifikate nur innerhalb eines W2k-Netzes möglich, wenn Benutzer- und Computerkonto vorhanden
Rechte lokaler Admin Organisations-Admin
  AD Veröffentlichung von Zertifikaten: Rechner in der Gruppe Zertifikatsherausgeber  

Die 'Installation erfolgt wie gewohnt über die Systemsteuerung \ Software... Danach ist aber weder ein Namenswechsel noch ein Rechneraus- oder -eintritt aus oder in eine Domäne möglich. Als nächstes kann man den Typ der Zertifizierungsstelle anwählen, die erweiterten Optionen wie die Integration vorhandener Schlüssel oder die Erstellung neuer Schlüssel mit Angabe der Länge, den Hashalgorithmus und den Dienstanbieter sind ebenfalls einstellbar. Informationen zur Zertifizierungsstelle wie Name, Ort und die Gültigkeit dieser sind genau wie der Ort der Zertifizierungsdatenbank einstellbar. Der Ordner, in dem Standardmässig die Zertifikatsdatenbank liegt (winnt \ system32 \ CertLog) sollte freigegeben sein. Die Auswirkungen der Installation sind ein Zertifikats-Snap-In, die Zertifizierungsstelle und der wählbare Webzugang zur CA zwecks der Verwaltung. Der eigene Rechner wurde jetzt zu den vertrauenswürdigen Stammzertifizierungsstellen hinzugefügt, welche sich in der Zertifikats-MMC befinden.

Fordert ein Client Zertifikate an, geht man in das Snap-In des CA-Servers (nur Org-CA.) klickt mit der rechten Maustaste und es öffnet sich ein Assistent. Die zweite Möglichkeit ist über den Webbrowser. http://IP-Adresse oder Name/Certsrv. Dort öffnet sich eine Website, die uns drei Möglichkeiten zur Auswahl gibt: Auf ein ausstehendes Zertifikat prüfen, ein Zertifikat anfordern oder das Zertifizierungsstellenzertifikat oder die Zertifikatsperrliste (CRL) abrufen. Der letzte Punkt bleibt allerdings nur untergeordneten Zertifikatsstellen vorbehalten. Wenn man ein Zertifikat anfordert, wird man gefragt, wozu das Zertifikat dienen soll (Webbrowser od. E-Mail). In den erweiterten Optionen gibt's dann noch Sachen wie die Schlüsselgrösse, die Importierung vorhandener Schlüssel, exportierbar oder als Dateiausgabe.

Wenn man nach einem Zertifikat überprüfen möchte, kann man die Anforderungen entfernen, oder das schon angeforderte Zertifikat kann installiert werden. Der Administrator sieht die Anforderung in der MMC und stellt das Zertifikat aus. Der User kann jetzt das Zertifikat installieren.

Vertraut der Client dem CA-Server noch nicht, erscheint die Frage, ob das CA-Zertifikat zum Speicher der vertrauenswürdigen CA's hinzugefügt werden soll:

In Zukunft werden dann alle Zertifikate dieser CA als vertrauenswürdig eingestuft, wenn man ja anklickt. Die eigentliche Zertifikatsinstallation geschieht automatisch.

Die Zertifikate, die man sich hat ausstellen lassen, kann man sich in der Zertifikats-MMC anschauen:

Unter eigenen Zertifikaten ist man im Besitz eines privaten Schlüssels für das Zertifikat. Unter vertrauenswürdige Stamm-CA's sieht man die Stamm-CA's, denen ich vertraue. Das ist auch die Vorraussetzung für deren Nutzung. Die Zwischen-CA's sind alle untergeordneten CA's, denen ich vertraue. Unter AD-Benutzerobjekte findet man Zertifikate des Benutzers, die in AD veröffentlicht sind. SPC zeigt aus Dateien importierte Zertifikate, und unter Anforderungen sind die Zertifikate aufgelistet, die noch ausstehen. Letzterer Punkt gilt aber nur für Organisations-CA's.

Zertifizierungsstellen und Zertifikatsverwaltung:

Auf dem Server in der MMC-Zertifizierungsstelle werden die Zertifikate verwaltet. Dort sind die gesperrten Zertifikate, die ausgestellten Zertifikate, die ausstehenden und die fehlgeschlagenen Zertifikate:

Eine Anforderung landet als erstes unter ausstehend. Dort kann man dann hauptsächlich verweigern oder ausstellen:

Beim Verweigern erhält der Client einmal die Nachricht, dass das Zertifikat verweigert wurde, dann erfährt er nichts mehr davon und die Anforderung verschwindet aus der Sicht des Clients. Unter fehlgeschlagene Anforderungen wird es dann dauerhaft gespeichert. Ist es ausgestellt, landet es in dem entsprechendem Ordner. Dort kann man ihn mit Angabe von Gründen verweigern:

Schlüsselkompromiss bedeutet nichts weiter, als dass der Schlüssel kompromittiert wurde...

Wenn man gesperrte Zertifikate veröffentlicht, ist die CRL über den Webdienst verfügbar. Standardmässig ist sie nicht verfügbar. Man muss sie also, bevor man sie abrufen kann, öffentlich zugänglich machen.

Die Zertifizierungsstelle kann man sichern und wiederherstellen. Dies ist eine Alternative zum normalen Backup, wo in den Systemstatusdaten die Zertifikatsdatenbank mit ihrer Konfiguration gesichert werden kann. Ebenfalls kann das CA-Zertifikat wie alle anderen Zertifikate erneuert werden.

Man  klickt man die Eigenscaften des Zertifikats an und dann das Richtlinienmodul. So kann man entscheiden, ob der Admin die Zertifikate ausstellt oder Zertifikate immer ausgestellt werden. Ersterer ist der Standard für eine eigenständige CA, letztere ist der Standard für Organisations-CA:

Das Beendigungsmodul (kann man das essen?) hat folgende beiden Funktionen:

Die Veröffentlichung im AD geht natürlich nicht bei einer eigenständigen CA, deswegen ist es hier ausgegraut. Die Speicherung zeigt nur die Ordner an, in denen die Datenbank gespeichert ist:

Da die Zertifikatsdienste ein ActiveDirectory-Objekt sind, kann man die Rechte explizit einstellen:

Man kann Zertifikate im- und exportieren. Das geschieht über Dateien.

Es erscheint ein Assistent. Wir werden gefragt, ob wir den privaten Schlüssel exportieren möchte, welcher kennwortgeschützt wird, oder nicht. Der Sinn dahinter ist beim Rechnerwechsel oder bei der Verwendung mehrerer Rechner erreicht. Der Export ist abhängig vom Zertifikatstyp und die Markierung zum Export beim Anfordern des Zertifikats in den erweiterten Optionen. Als nächstes ist der Typ anzugeben:

DER ist wie Base64 ein X.509-Typ und für CA's, die nicht W2k-fähig sind. Die Endung ist cer. Dateien des Formats PKCS#12 (Public Key Cryptographic Standard) mit der Endung pfx und Dateien des Typs PKCS#7 (p7b-Endung) sind für W2k-Rechner geeignet. Letztere bieten weitere Optionen: Standardmässig bleibt der Schlüssel nach dem Export erhalten.

Beim Import ist der Dateiname, das Kennwort (beim Beantragen des Zertifikats muss das Kennwort bei jedem Zugriff eingegeben werden), die Exportierbarkeit und der Zertifikatsspeicherort anzugeben.

Troubleshooting:

richtiger CA-Typ?

Anmeldung beim Webserver => Authentifizierung

"geht nicht mehr" => abgelaufen => erneuern; => gesperrt => warum?, neues anfordern.

"geht nicht" => Vertrauen zu CA? => CA-Zertifikat installieren.