Exportieren (0) Drucken
Alle erweitern
Dieser Artikel wurde manuell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen. Weitere Informationen
Übersetzung
Original

Verwenden von Zertifikaten

Bei der Programmierung der Windows Communication Foundation (WCF)-Sicherheit werden digitale X.509-Zertifikate häufig zum Authentifizieren von Clients und Servern sowie zum Verschlüsseln und digitalen Signieren von Nachrichten verwendet. Dieses Thema bietet einen Überblick über die Funktionen digitaler X.509-Zertifikate und ihre Verwendung in WCF und enthält Links zu Themen, in denen diese Konzepte näher beschrieben oder die Ausführung allgemeiner Aufgaben mit WCF und Zertifikaten erläutert 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 ausgestellt, und jedes Zertifikat enthält eine Reihe von Feldern mit Daten wie Antragsteller (die Entität, für die das Zertifikat ausgestellt wird), Gültigkeitsdatum (das Datum, bis zu dem das Zertifikat gültig ist), Aussteller (die Entität, von der das Zertifikat ausgestellt wurde) und öffentlichem Schlüssel. In WCF werden diese Eigenschaften als Claim verarbeitet, und jeder Anspruch wird weiter in zwei Typen unterteilt: Identität und Recht. Weitere Informationen finden Sie unter zur X.509-Zertifikaten finden Sie unter X.509-Zertifikate mit öffentlichem SchlüsselWeitere Informationen finden Sie unter zu Ansprüchen und zur Autorisierung in WCF finden Sie unter Verwalten von Ansprüchen und Autorisierung mit dem Identitätsmodell. Weitere Informationen finden Sie unter zum Implementieren einer PKI finden Sie unter Windows Server 2008 R2 - Zertifikatdienste.

Eine zentrale Funktion des Zertifikats ist die Authentifizierung der Identität des Besitzers des Zertifikats gegenüber anderen. Ein Zertifikat enthält den öffentlichen Schlüssel des Besitzers, während der Besitzer den privaten Schlüssel behält. Der öffentliche Schlüssel kann zum Verschlüsseln von Nachrichten verwendet werden, die an den Besitzer des Zertifikats gesendet 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 ausgestellt werden, bei der es sich oft um einen Drittanbieter-Zertifikataussteller handelt. Windows-Domänen verfügen über eine Zertifizierungsstelle, von der Zertifikate für Computer in der Domäne ausgestellt werden können.

Bei der Verwendung von Zertifikaten ist es oft erforderlich, die Zertifikate anzuzeigen und ihre Eigenschaften zu überprüfen. Die einfachste Methode dazu ist das MMC (Microsoft Management Console)-Snap-In-Tool. Weitere Informationen finden Sie unterVorgehensweise: Anzeigen von Zertifikaten mit dem MMC-Snap-In.

Zertifikate werden in Speichern abgelegt. Die zwei Hauptspeicherorte sind in weitere Unterspeicher unterteilt. 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.

    Wichtiger Hinweis Wichtig

    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 finden Sie unter zu Zertifikatspeichern finden Sie unter Zertifikatspeicher.

ms731899.collapse_all(de-de,VS.110).gifAuswählen eines Speichers

Die Auswahl des Speichers für ein Zertifikat hängt davon ab, wie und wann der Dienst oder Client ausgeführt wird. Dabei gelten folgende allgemeine Regeln:

  • Wenn der WCF-Dienst in einem Windows-Dienst gehostet wird, wird der Speicher des lokalen Computers verwendet. Sie benötigen Administratorrechte, wenn Sie Zertifikate im lokalen Computerspeicher installieren möchten.

  • Wenn es sich beim Dienst oder Client um eine Anwendung handelt, die unter einem Benutzerkonto ausgeführt wird, wird der Speicher des aktuellen Benutzers verwendet.

ms731899.collapse_all(de-de,VS.110).gifZugreifen 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 zum Bearbeiten 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 finden Sie unter zur Verwendung von Clientzertifikaten mit IIS finden Sie unter Aufrufen eines Webdiensts mit einem Clientzertifikat zur Authentifizierung in einer ASP.NET-Webanwendung

Zertifikate werden in einer Hierarchie erstellt, in der jedes einzelne Zertifikat mit der Zertifizierungsstelle verknüpft ist, von der es ausgestellt wurde. Dieser Link verweist auf das Zertifikat der Zertifizierungsstelle. Das Zertifikat der Zertifizierungsstelle wird dann mit der Zertifizierungsstelle verknüpft, von der das ursprüngliche Zertifikat der Zertifizierungsstelle ausgestellt wurde. Dieser Prozess wird wiederholt, bis das Zertifikat der Stammzertifizierungsstelle erreicht wird. Das Zertifikat der Stammzertifizierungsstelle ist grundsätzlich vertrauenswürdig.

Digitale Zertifikate werden verwendet, um eine Entität anhand dieser als Zertifikatskette bezeichneten Hierarchie zu authentifizieren. 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. Weitere Informationen finden Sie unter zum Importieren von Zertifikatketten für Zertifizierungsstellen finden Sie unter Vorgehensweise: Angeben der Zertifizierungsstellenzertifikatskette, die verwendet wird, um Signaturen (WCF) zu überprüfen.

Hinweis Hinweis

Sie können jeden Aussteller zu einer vertrauenswürdigen Stammzertifizierungsstelle machen, indem Sie das Zertifikat des Ausstellers im Zertifikatspeicher der Stammzertifizierungsstelle ablegen.

ms731899.collapse_all(de-de,VS.110).gifDeaktivieren 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:

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-Zertifikats-Validierungssteuerelement. Weitere Informationen finden Sie unterBenutzerdefinierte Anmeldeinformationen und Validierung der Anmeldeinformationen.

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

  1. Erstellen Sie ein (selbst signiertes) temporäres Zertifikat für eine Stammzertifizierungsstelle mit MakeCert.exe. Speichern Sie den privaten Schlüssel.

  2. Verwenden Sie das neue Zertifikat, um ein anderes Zertifikat auszustellen, das den öffentlichen Schlüssel enthält.

  3. Importieren Sie das Zertifikat der Stammzertifizierungsstelle in den Speicher vertrauenswürdiger Stammzertifizierungsstellen.

  4. Schritt-für-Schritt-Anweisungen finden Sie unter Gewusst wie: Erstellen von temporären Zertifikaten für die Verwendung während der Entwicklung.

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.

ms731899.collapse_all(de-de,VS.110).gifDienstzertifikate

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 "http://www.contoso.com/endpoint/". In diesem Fall muss das Feld Antragsteller ebenfalls den Wert "http://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".

ms731899.collapse_all(de-de,VS.110).gifClientzertifikate

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.

ms731899.collapse_all(de-de,VS.110).gifZertifikatsgü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.

ms731899.collapse_all(de-de,VS.110).gifZertifikatsperrliste

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> des <clientCertificate>-Elements<serviceBehaviors><authentication> des <clientCertificate>-Elements<endpointBehaviors>) und von (für ) in der Konfiguration festlegen.

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.

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.


Uri baseAddress = new Uri("http://cohowinery.com/services");
ServiceHost sh = new ServiceHost(typeof(CalculatorService), baseAddress );
sh.Credentials.ServiceCertificate.SetCertificate(
StoreLocation.LocalMachine, StoreName.My,
X509FindType.FindBySubjectName, "cohowinery.com");


ms731899.collapse_all(de-de,VS.110).gifMehrere Zertifikate mit dem gleichen Wert

Ein Speicher kann mehrere Zertifikate mit dem gleichen Antragstellernamen enthalten. Wenn Sie also x509FindType auf FindBySubjectName oder FindBySubjectDistinguishedName festlegen und mehrere Zertifikate den gleichen Wert aufweisen, wird eine Ausnahme ausgelöst, da nicht ermitteltwerdenkann, welches Zertifikat benötigt wird. 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.

Sie können Zertifikate auch in der Konfiguration festlegen. Wenn Sie einen Dienst erstellen, werden die Anmeldeinformationen, einschließlich der Zertifikate unter <serviceBehaviors> angegeben. Wenn Sie einen Client programmieren, werden die Zertifikate unter <endpointBehaviors> angegeben.

IIS und Active Directory bieten u. a. die Möglichkeit, ein Zertifikat einem Windows-Benutzerkonto zuzuordnen. Weitere Informationen finden Sie unter zur Funktion finden Sie unter Zuordnen von Zertifikaten zu Benutzerkonten

Weitere Informationen finden Sie unter 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> des <serviceCertificate>-Elementstrue-Elements wie im folgenden Codebeispiel auf 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.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2015 Microsoft