Verwenden von Zertifikaten
Bei der Programmierung der Windows Communication Foundation (WCF)-Sicherheit werden digitale X.509-Zertifikate häufig zur Authentifizierung von Clients und Servern, zur Codierung von Nachrichten sowie zur digitalen Signierung von Nachrichten verwendet. In diesem Thema wird ein Überblick über die Zertifikatfunktionen und ihre Verwendung in WCF gegeben, und es werden Hyperlinks zu Themen bereitgestellt, die weitergehende Informationen bereithalten oder veranschaulichen, wie gängige Aufgaben mit WCF und Zertifikaten ausgeführt werden.
Digitale Zertifikate sind Teil einer Public Key-Infrastruktur (PKI). Dabei handelt es sich um ein System aus digitalen Zertifikaten, Zertifizierungsstellen und anderen Registrierungsstellen zur Überprüfung und Authentifizierung der Gültigkeit aller beteiligten Parteien in einer elektronischen Transaktion unter Verwendung der Public Key-Kryptologie. Die Zertifikate werden von einer Zertifizierungsstelle ausgegeben, und jedes Zertifikat verfügt über eine Reihe von Feldern mit Daten, beispielsweise Antragsteller (die Entität, für die das Zertifikat ausgestellt wird), Gültigkeitsdaten, Aussteller und öffentlicher Schlüssel. In WCF werden alle entsprechenden Eigenschaften als Claim verarbeitet, und jeder Anspruch wird nach zwei Typen unterschieden: Identität und Recht. Weitere Informationen finden Sie unter Verwalten von Ansprüchen und Autorisierung mit dem Identitätsmodell. Weitere Informationen zum Implementieren einer PKI finden Sie unter Empfohlene Vorgehensweisen für das Implementieren einer Infrastruktur für öffentliche Schlüssel unter Microsoft Windows Server 2003 (möglicherweise in englischer Sprache).
Eine zentrale Funktion des Zertifikats ist die Authentifizierung der Identität des Antragstellers gegenüber anderen. Ein Zertifikat enthält auch den öffentlichen Schlüssel des Antragstellers, während der Antragsteller den privaten Schlüssel behält. Der öffentliche Schlüssel kann von allen zum Verschlüsseln einer Nachricht verwendet werden. Beide Schlüssel sind jedoch zum Entschlüsseln einer Nachricht erforderlich, sodass nur der Inhaber des privaten Schlüssels auch Nachrichten entschlüsseln kann. Der öffentliche Schlüssel kann zum Verschlüsseln von Nachrichten an den Besitzer des Zertifikats verwendet werden. Nur der Besitzer hat Zugriff auf den privaten Schlüssel, sodass niemand anders diese Nachrichten entschlüsseln kann.
Zertifikate müssen von einer Zertifizierungsstelle ausgegeben werden, bei der es sich oft um einen Drittanbieter handelt. Windows-Domänen verfügen über eine Zertifizierungsstelle, von der Zertifikate für Computer in dieser Domäne ausgegeben werden können.
Weitere Informationen zu Zertifikaten finden Sie unter Zertifikate (möglicherweise in englischer Sprache).
Anzeigen von Zertifikaten
Zertifikate müssen häufig angezeigt und ihre Eigenschaften überprüft werden. Dies geschieht am einfachsten mit dem MMC (Microsoft Management Console)-Snap-In-Tool. Weitere Informationen finden Sie unter Gewusst wie: Anzeigen von Zertifikaten mit dem MMC-Snap-In. Weitere Dokumente mit Anleitungen zur Verwendung dieses Tools finden Sie unter Httpcfg-Übersicht (möglicherweise in englischer Sprache).
Zertifikatspeicher
Zertifikate werden in Speichern abgelegt. Die zwei Hauptspeicherorte teilen sich in weitere Unterspeicher auf. Administratoren können beide Hauptspeicher mit dem MMC-Snap-In-Tool anzeigen. Alle anderen Benutzer können lediglich den Speicher des aktuellen Benutzers anzeigen.
- Lokaler Computerspeicher Dieser enthält die Zertifikate, die von den Prozessen des Computers verwendet werden, z. B. ASP.NET. Speichern Sie die Zertifikate zur Authentifizierung des Servers gegenüber Clients im lokalen Computerspeicher.
- Aktueller Benutzerspeicher. Interaktive Anwendungen legen Zertifikate für den aktuellen Benutzer des Computers normalerweise im aktuellen Benutzerspeicher ab. Beim Erstellen einer Clientanwendung werden die Zertifikate zur Authentifizierung eines Benutzers gegenüber einem Dienst normalerweise hier abgelegt.
Diese beiden Speicher teilen sich in weitere Unterspeicher auf. Die wichtigsten Unterspeicher für die Programmierung mit WCF sind folgende:
Vertrauenswürdige Stammzertifizierungsstellen. Mit den Zertifikaten in diesem Speicher können Sie eine Zertifikatskette erstellen, die zum Zertifikat einer Zertifizierungsstelle in diesem Speicher zurückverfolgt werden kann.
Tipp
Der lokale Computer stuft alle Zertifikate in diesem Speicher als implizit vertrauenswürdig ein; dies gilt auch, wenn das Zertifikat im Speicher nicht von einer vertrauenswürdigen Zertifizierungsstelle eines Drittanbieters stammt. Aus diesem Grund sollten Sie in diesem Speicher nur Zertifikate ablegen, wenn Sie dem Aussteller uneingeschränkt vertrauen und sich der möglichen Folgen bewusst sind.
Persönlich. Dieser Speicher wird für Zertifikate verwendet, die dem Benutzer eines Computers zugeordnet sind. Dieser Speicher wird normalerweise für Zertifikate verwendet, die von einem der Zertifikate der Zertifizierungsstelle im Speicher vertrauenswürdiger Stammzertifizierungsstellen stammen. Darüber hinaus können in diesem Speicher auch selbst ausgestellte Zertifikate abgelegt werden, die von einer Anwendung als vertrauenswürdig eingestuft werden.
Weitere Informationen zu Zertifikatspeichern finden Sie unter Zertifikatspeicher (möglicherweise in englischer Sprache).
Auswählen eines Speichers
Die Auswahl des Speicherorts für ein Zertifikat hängt von der Ausführung des Diensts oder Clients ab. Dabei gelten folgende allgemeine Regeln:
- Verwenden Sie den lokalen Computerspeicher, wenn es sich um einen Windows-Dienst handelt, also um einen Dienst, der im Servermodus ohne Benutzeroberfläche unter einem Netzwerkdienstkonto ausgeführt wird. Sie benötigen Administratorrechte, wenn Sie Zertifikate im lokalen Computerspeicher installieren möchten.
- Verwenden Sie den aktuellen **** Benutzerspeicher, wenn der Dienst oder der Client in eine Anwendung integriert sind, die unter einem Benutzerkonto ausgeführt wird.
Zugreifen auf Speicher
Speicher werden analog zu Ordnern auf einem Computer durch Zugriffssteuerungslisten (ACLs) geschützt. Beim Erstellen eines Diensts, der von Internet Information Services (IIS) gehostet wird, wird der ASP.NET-Prozess unter dem ASP.NET-Konto ausgeführt. Dieses Konto muss über Zugriff auf den Speicher mit den Zertifikaten verfügen, die von einem Dienst verwendet werden. Die zentralen Speicher werden durch eine Standardzugriffssteuerungsliste geschützt, eine Änderung der Listen ist jedoch möglich. Wenn Sie eine separate Rolle für den Speicherzugriff erstellen, muss diese über die entsprechende Zugriffsberechtigung verfügen. Informationen zur Bearbeitung der Zugriffssteuerungsliste mit dem Tool WinHttpCertConfig.exe finden Sie unter Gewusst wie: Erstellen von temporären Zertifikaten für die Verwendung während der Entwicklung. Weitere Informationen zur Verwendung von Clientzertifikaten mit IIS finden Sie unter Aufrufen eines Webdiensts mit einem Clientzertifikat zur Authentifizierung in einer ASP.NET-Webanwendung (möglicherweise in englischer Sprache).
Vertrauensketten und Zertifizierungsstellen
Digitale Zertifikate werden zur Authentifizierung von Entitäten anhand einer Kette von Vertrauensstellungen verwendet. Die Kette wird, ausgehend von der Stammzertifizierungsstelle, von oben nach unten gebildet. Sie können die Kette eines beliebigen Zertifikats mit dem MMC-Snap-In anzeigen, indem Sie auf das Zertifikat doppelklicken und anschließend auf die Registerkarte Zertifikatpfad klicken. Das Zertifikat der Stammzertifizierungsstelle zu Beginn einer Zertifikatkette ist selbst ausgestellt. Dies bedeutet, dass der Aussteller identisch mit der Entität ist, für die das Zertifikat ausgestellt wird. Weitere Informationen zum Importieren von Zertifikatketten für Zertifizierungsstellen finden Sie unter Gewusst wie: Angeben der Zertifizierungsstellenzertifikatskette, die verwendet wird, um Signaturen (WCF) zu überprüfen.
Tipp
Sie können jeden Aussteller zu einer vertrauenswürdigen Stammzertifizierungsstelle machen, indem Sie das Zertifikat des Ausstellers im Zertifikatspeicher der Stammzertifizierungsstelle ablegen.
Deaktivieren von Vertrauensketten
Wenn Sie einen neuen Dienst erstellen, verwenden Sie möglicherweise ein Zertifikat, das nicht von einer vertrauenswürdigen Stammzertifizierungsstelle ausgegeben wurde, oder das ausstellende Zertifikat befindet sich nicht im Speicher vertrauenswürdiger Stammzertifizierungsstellen. Sie können die Überprüfung der Kette von Vertrauensstellungen für ein Zertifikat in Entwicklungsumgebungen vorübergehend deaktivieren. Legen Sie dazu die CertificateValidationMode-Eigenschaft auf entweder PeerTrust oder PeerOrChainTrust fest. Durch den jeweiligen Modus wird angegeben, dass das Zertifikat entweder selbst ausgegeben (Peervertrauenszertifikat) oder Teil einer Kette von Vertrauensstellungen ist. Die Eigenschaft kann auf eine der folgenden Klassen festgelegt werden:
Sie können die Eigenschaft auch in der Konfiguration festlegen. Folgende Elemente werden verwendet, um den Validierungsmodus anzugeben:
- <authentication> of <serviceCertificate> Element
- <peerAuthentication> Element
- <messageSenderAuthentication> element
Benutzerdefinierte Authentifizierung
Die CertificateValidationMode-Eigenschaft ermöglicht es auch, die Authentifizierung von Zertifikaten anzupassen. Die Standardvertrauensebene ist ChainTrust. Wenn Sie den Custom-Wert verwenden möchten, müssen Sie auch das CustomCertificateValidatorType-Attribut auf eine Assembly und einen Typ festlegen, die zur Validierung des Zertifikats verwendet werden. Wenn Sie eine benutzerdefinierte Überprüfung erstellen möchten, müssen Sie die abstrakte X509CertificateValidator-Klasse vererben.
Wenn Sie eine benutzerdefinierte Authentifizierung erstellen, müssen Sie auf jeden Fall die Validate-Methode überschreiben. Ein Beispiel für eine benutzerdefinierte Authentifizierung finden Sie unter X.509 Certificate Validator. Weitere Informationen finden Sie unter Benutzerdefinierte Anmeldeinformationen und Überprüfung der Anmeldeinformationen.
Verwenden von Makecert.exe zum Erstellen einer Zertifikatkette
Mit dem Certificate Creation-Tool (Makecert.exe) werden X.509-Zertifikate sowie Paare aus privaten und öffentlichen Schlüsseln erstellt. Sie können den privaten Schlüssel speichern und zum Ausstellen und Signieren neuer Zertifikate verwenden, um eine Hierarchie von Zertifikaten in einer Kette zu simulieren. Dieses Tool ist lediglich als Unterstützung bei der Entwicklung von Diensten gedacht und sollte niemals zur Erstellung von Zertifikaten für tatsächliche Bereitstellungen verwendet werden. Wenn Sie einen WCF-Dienst entwickeln, können Sie mit Makecert.exe anhand der folgenden Schritte eine Kette von Vertrauensstellungen erstellen.
So erstellen Sie eine Kette von Vertrauensstellungen mit Makecert.exe
Erstellen Sie ein (selbst signiertes) temporäres Zertifikat für eine Stammzertifizierungsstelle mit MakeCert.exe. Speichern Sie den privaten Schlüssel.
Verwenden Sie das neue Zertifikat, um ein anderes Zertifikat auszustellen, das den öffentlichen Schlüssel enthält.
Importieren Sie das Zertifikat der Stammzertifizierungsstelle in den Speicher vertrauenswürdiger Stammzertifizierungsstellen.
Schritt-für-Schritt-Anweisungen finden Sie unter Gewusst wie: Erstellen von temporären Zertifikaten für die Verwendung während der Entwicklung.
Welches Zertifikat soll verwendet werden?
Im Zusammenhang mit Zertifikaten wird häufig danach gefragt, welches Zertifikat und warum dieses verwendet werden soll. Die Antwort hängt davon ab, ob Sie einen Client oder einen Dienst programmieren. Die folgenden Informationen bieten eine allgemeine Orientierung und stellen keine erschöpfende Antwort auf diese Fragen dar.
Dienstzertifikate
Dienstzertifikate werden in erster Linie zur Authentifizierung von Servern gegenüber Clients verwendet. Bei der Authentifizierung eines Servers durch einen Client wird u. a. zunächst überprüft, ob der Wert im Feld Antragsteller mit dem Uniform Resource Identifier (URI) übereinstimmt, der zum Herstellen der Verbindung mit dem Dienst verwendet wird: das DNS von Client und Server muss übereinstimmen. Angenommen, der URI des Diensts lautet "https://www.contoso.com/endpoint/". In diesem Fall muss das Feld Antragsteller ebenfalls den Wert "https://www.contoso.com/endpoint/" enthalten.
Das Feld kann mehrere Werte enthalten, denen jeweils eine Initialisierung zur Angabe des Werts vorangeht. Die am häufigsten verwendete Initialisierung lautet "CN" (Common Name), z. B. "CN = www.contoso.com". Das Feld Antragsteller kann auch leer sein. In diesem Fall kann das Feld Alternativer Antragstellername den Wert DNS-Name enthalten.
Der Wert des Felds Beabsichtigte Zwecke des Zertifikats sollte einen entsprechenden Wert enthalten, z. B. "Serverauthentifizierung" oder "Clientauthentifizierung".
Clientzertifikate
Clientzertifikate werden normalerweise nicht von der Zertifizierungsstelle eines Drittanbieters ausgegeben. Stattdessen enthält der persönliche Speicher des aktuellen Benutzers für gewöhnlich Zertifikate, die von einer Stammzertifizierungsstelle dort abgelegt wurden und deren beabsichtigter Zweck die "Clientauthentifizierung" ist. Diese Zertifikate können vom Client verwendet werden, wenn eine wechselseitige Authentifizierung erforderlich ist.
Online-Sperrüberprüfung und Offline-Sperrüberprüfung
Zertifikatsgültigkeit
Jedes Zertifikat ist nur für einen angegebenen Zeitraum gültig, der auch als Gültigkeitsdauer bezeichnet wird. Die Gültigkeitsdauer wird durch die Felder Gültig ab und Gültig bis eines X.509-Zertifikats bestimmt. Während der Authentifizierung wird überprüft, ob das Zertifikat eine entsprechende Gültigkeitsdauer aufweist.
Zertifikatsperrliste
Zertifikate können innerhalb der Gültigkeitsdauer jederzeit von der Zertifizierungsstelle widerrufen werden. Dafür kann es viele Gründe geben, beispielsweise kann die Sicherheit des privaten Schlüssels eines Zertifikats gefährdet sein.
In diesem Fall werden auch alle untergeordneten Zertifikate des widerrufenen Zertifikats ungültig und im Rahmen des Authentifizierungsprozesses als nicht vertrauenswürdig eingestuft. Mithilfe einer Zertifikatsperrliste (CRL), die über Datums- und Zeitstempel verfügt, können Sie herausfinden, welche Zertifikate widerrufen wurden. Diese Liste kann mit einer Online-Sperrüberprüfung oder mit einer Offline-Sperrüberprüfung überprüft werden, indem die RevocationMode-Eigenschaft oder die DefaultRevocationMode-Eigenschaft der folgenden Klassen einschließlich der IssuedTokenServiceCredential-Klassen auf einen der X509RevocationMode-Enumerationswerte festgelegt wird: X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthentication. Der Standardwert aller Eigenschaften lautet Online.
Sie können den Modus auch mit dem revocationMode-Attribut von <authentication> of <clientCertificate> Element (für serviceBehaviors section) und von <authentication> of <clientCertificate> Element (für endpointBehaviors section) in der Konfiguration festlegen.
SetCertificate-Methode
In WCF müssen häufig Zertifikate oder Gruppen von Zertifikaten angegeben werden, die von einem Dienst oder von einem Client zum Authentifizieren, Verschlüsseln oder digitalen Signieren von Nachrichten verwendet werden. Dies kann programmgesteuert mit der SetCertificate-Methode verschiedener Klassen geschehen, die X.509-Zertifikate darstellen. Folgende Klassen geben mit der SetCertificate-Methode ein Zertifikat an.
| Klasse | Methode |
|---|---|
Bei der SetCertificate-Methode werden ein Speicherort und ein Speicher angegeben sowie ein Suchtyp (x509FindType-Parameter), der ein Feld des Zertifikats bestimmt, und ein Wert, der im Feld gefunden werden soll. So wird beispielsweise mit dem folgenden Code eine ServiceHost-Instanz erstellt, und das Dienstzertifikat, mit dem der Dienst gegenüber Clients mit der SetCertificate -Methode authentifiziert wird, wird festgelegt.
Mehrere Zertifikate mit dem gleichen Wert
Ein Speicher kann mehrere Zertifikate mit dem gleichen Antragstellernamen enthalten. Wenn Sie also FindBySubjectName oder FindBySubjectDistinguishedName als x509FindType angeben und mehrere Zertifikate den gleichen Wert aufweisen, wird eine Ausnahme ausgelöst, da es keine Möglichkeit gibt ****, das erforderliche Zertifikat zu ermitteln. Legen Sie den x509FindType auf FindByThumbprint fest, um dem entgegenzuwirken. Das Fingerabdruckfeld enthält einen eindeutigen Wert, mit dem ein bestimmtes Zertifikat in einem Speicher gefunden werden kann. Dies hat jedoch einen Nachteil: Wenn das Zertifikat widerrufen oder erneuert wird, schlägt die SetCertificate-Methode fehl, da der Fingerabdruck ebenfalls nicht mehr verfügbar ist. Ist das Zertifikat nicht mehr gültig ist, schlägt die Authentifizierung fehl. Legen Sie den x590FindType-Parameter auf FindByIssuerName fest, und geben Sie den Namen des Ausstellers an, um dem entgegenzuwirken. Wenn kein bestimmter Aussteller angegeben werden muss, können Sie auch einen der anderen X509FindType-Enumerationswerte wie FindByTimeValid festlegen.
Zertifikate in der Konfiguration
Sie können Zertifikate auch in der Konfiguration festlegen. Wenn Sie einen Dienst erstellen, werden die Anmeldeinformationen, einschließlich der Zertifikate unter serviceBehaviors section angegeben. Wenn Sie einen Client programmieren, werden die Zertifikate unter endpointBehaviors section angegeben.
Zuordnen eines Zertifikats zu einem Benutzerkonto
IIS und Active Directory bieten u. a. die Möglichkeit, ein Zertifikat einem Windows-Benutzerkonto zuzuordnen. Weitere Informationen zu dieser Möglichkeit finden Sie unter Zuordnen von Zertifikaten zu Benutzerkonten (möglicherweise in englischer Sprache).
Weitere Informationen zur Active Directory-Zuordnung finden Sie unter Zuordnen von Clientzertifikaten mit der Verzeichnisdienstzuordnung (möglicherweise in englischer Sprache).
Wenn diese Funktion aktiviert ist, können Sie die MapClientCertificateToWindowsAccount-Eigenschaft der X509ClientCertificateAuthentication-Klasse auf true festlegen. In der Konfiguration können Sie das mapClientCertificateToWindowsAccount-Attribut des <authentication>-Elements wie im folgenden Codebeispiel auf true festlegen.
<serviceBehaviors>
<behavior name="MappingBehavior">
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="None" mapClientCertificateToWindowsAccount="true" />
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
Die Zuordnung eines X.509-Zertifikats zu einem Token, das ein Windows-Benutzerkonto darstellt, wird als Erweiterung der Berechtigungen angesehen, da das Windows-Token nach der Zuordnung Zugriff auf geschützte Ressourcen ermöglicht. Das X.509-Zertifikat muss daher vor der Zuordnung die entsprechenden Anforderungen der Domänenrichtlinie erfüllen. Dies wird durch das SChannel-Sicherheitspaket sichergestellt.
WCF stellt bei Verwendung von .NET Framework, Version 3.5 oder höher sicher, dass das Zertifikat der Domänenrichtlinie entspricht, bevor es dem Windows-Konto zugeordnet wird.
In der ersten Version von WCF erfolgt die Zuordnung ohne auf die Domänenrichtlinie zurückzugreifen. Möglicherweise tritt daher bei älteren Anwendungen, die mit der ersten Version ausgeführt werden konnten, ein Fehler auf, wenn die Zuordnung aktiviert ist und die Anforderungen der Domänenrichtlinie vom X.509-Zertifikat nicht erfüllt werden.
Siehe auch
Referenz
System.ServiceModel.Channels
System.ServiceModel.Security
System.ServiceModel
X509FindType