Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Zum Programmieren der Sicherheit von Windows Communication Foundation (WCF) werden digitale X.509-Zertifikate häufig verwendet, um Clients und Server zu authentifizieren, nachrichten zu verschlüsseln und digital zu signieren. In diesem Thema werden kurz X.509-Features für digitale Zertifikate und deren Verwendung in WCF erläutert und Links zu Themen enthalten, die diese Konzepte weiter erläutern oder zeigen, wie allgemeine Aufgaben mithilfe von WCF und Zertifikaten ausgeführt werden.
Kurz gesagt ist ein digitales Zertifikat Teil einer Public Key-Infrastruktur (PKI), bei der es sich um ein System digitaler Zertifikate, Zertifizierungsstellen und anderer Registrierungsbehörden handelt, die die Gültigkeit der einzelnen Parteien, die an einer elektronischen Transaktion beteiligt sind, über die Verwendung von Kryptografie für öffentliche Schlüssel überprüfen und authentifizieren. Eine Zertifizierungsstelle gibt Zertifikate aus, und jedes Zertifikat verfügt über eine Reihe von Feldern, die Daten enthalten, z. B. Betreff (die Entität, für die das Zertifikat ausgestellt wird), Gültigkeitsdaten (wenn das Zertifikat gültig ist), Aussteller (die Entität, die das Zertifikat ausgestellt hat) und einen öffentlichen Schlüssel. In WCF wird jede dieser Eigenschaften als ein Claim verarbeitet, und jeder Anspruch weiter in die zwei Typen Identität und Recht unterteilt. Weitere Informationen zu X.509-Zertifikaten finden Sie unter X.509 Public Key Certificates. Weitere Informationen zu Ansprüchen und Autorisierung in WCF finden Sie unter Verwalten von Ansprüchen und Autorisierung mit dem Identitätsmodell. Weitere Informationen zur Implementierung einer PKI finden Sie unter Enterprise PKI mit Windows Server 2012 R2 Active Directory-Zertifikatdiensten.
Die primäre Funktion eines Zertifikats besteht darin, die Identität des Besitzers des Zertifikats für andere zu authentifizieren. 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 nur der Besitzer diese Nachrichten entschlüsseln kann.
Zertifikate müssen von einer Zertifizierungsstelle ausgestellt werden, die häufig ein Drittanbieter von Zertifikaten ist. In einer Windows-Domäne ist eine Zertifizierungsstelle enthalten, die verwendet werden kann, um Zertifikate für Computer in der Domäne auszustellen.
Zertifikate anzeigen
Bei der Verwendung von Zertifikaten ist es oft erforderlich, die Zertifikate anzuzeigen und ihre Eigenschaften zu überprüfen. Dies erfolgt ganz einfach mit dem Microsoft Management Console (MMC)-Snap-In-Tool. Weitere Informationen finden Sie unter How to: View Certificates with the MMC Snap-in.
Zertifikatspeicher
Zertifikate werden in Stores gefunden. Es gibt zwei wichtige Geschäftsstandorte, die weiter in Filialen unterteilt sind. Administratoren können beide Hauptspeicher mit dem MMC-Snap-In-Tool anzeigen. Nicht-Administratoren können nur den aktuellen Benutzerspeicher anzeigen.
Der lokale Computerspeicher. Dies enthält die Zertifikate, auf die Computerprozesse zugreifen, z. B. ASP.NET. Verwenden Sie diesen Speicherort, um Zertifikate zu speichern, die den Server für Clients authentifizieren.
Aktueller Benutzerspeicher Interaktive Anwendungen platzieren in der Regel Zertifikate für den aktuellen Benutzer des Computers. Wenn Sie eine Clientanwendung erstellen, platzieren Sie in der Regel Zertifikate, die einen Benutzer bei einem Dienst authentifizieren.
Diese beiden Filialen sind weiter in Unterfilialen unterteilt. Zu den wichtigsten Informationen bei der Programmierung mit WCF gehören:
Vertrauenswürdige Stammzertifizierungsstellen. Sie können die Zertifikate in diesem Speicher verwenden, um eine Kette von Zertifikaten zu erstellen, die auf ein Zertifizierungsstellenzertifikat in diesem Speicher zurückverfolgt werden können.
Von Bedeutung
Der lokale Computer vertraut implizit allen Zertifikaten in diesem Speicher, auch wenn das Zertifikat nicht von einer vertrauenswürdigen Zertifizierungsstelle von Drittanbietern 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.
Privat. Dieser Speicher wird für Zertifikate verwendet, die einem 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.
Auswählen eines Stores
Die Auswahl des Speicherorts eines Zertifikats hängt davon ab, wie und wann der Dienst oder Client ausgeführt wird. Es gelten die folgenden allgemeinen Regeln:
Wenn der WCF-Dienst in einem Windows-Dienst gehostet wird, verwenden Sie den lokalen Computerspeicher . Beachten Sie, dass Administratorrechte erforderlich sind, um Zertifikate im lokalen Computerspeicher zu installieren.
Wenn der Dienst oder Client eine Anwendung ist, die unter einem Benutzerkonto ausgeführt wird, verwenden Sie den aktuellen Benutzerspeicher .
Zugriffsspeicher
Stores sind durch Zugriffssteuerungslisten (ACCESS Control Lists, ACLs) geschützt, genau wie Ordner auf einem Computer. Beim Erstellen eines Diensts, der von Internetinformationsdienste (Internet Information Services, IIS) gehostet wird, wird der ASP.NET Prozess unter dem ASP.NET Konto ausgeführt. Dieses Konto muss Zugriff auf den Speicher haben, der die von einem Dienst verwendeten Zertifikate enthält. Jedes der größeren Geschäfte ist durch eine Standardzugriffsliste geschützt, die Listen können jedoch geändert werden. Wenn Sie eine separate Rolle für den Zugriff auf einen Speicher erstellen, müssen Sie diese Rollenzugriffsberechtigung erteilen. Unter How to: Create Temporary Certificates for Use During Development (Vorgehensweise: Erstellen temporärer Zertifikate zur Verwendung während der Entwicklung) erfahren Sie, wie Sie die Zugriffsliste mit dem Tool „WinHttpCertConfig.exe“ bearbeiten.
Vertrauensketten und Zertifizierungsstellen
Zertifikate werden in einer Hierarchie erstellt, in der jedes einzelne Zertifikat mit der Zertifizierungsstelle verknüpft ist, die das Zertifikat ausgestellt hat. Dieser Link ist mit dem Zertifikat der Zertifizierungsstelle verknüpft. Anschließend wird das Zertifikat der CA mit der CA verknüpft, die das ursprüngliche Zertifikat der CA ausgestellt hat. Dieser Prozess wird wiederholt, bis das Zertifikat der Stammzertifizierungsstelle erreicht wird. Das Zertifikat der Stammzertifizierungsstelle ist inhärent vertrauenswürdig.
Digitale Zertifikate werden verwendet, um eine Entität zu authentifizieren, indem sie auf diese Hierarchie vertrauen, auch als Vertrauenskette bezeichnet. Sie können die Kette eines beliebigen Zertifikats mithilfe des MMC-Snap-Ins anzeigen, indem Sie auf ein beliebiges Zertifikat doppelklicken und dann auf die Registerkarte " Zertifikatpfad " klicken. Weitere Informationen zum Importieren von Zertifikatketten für eine Zertifizierungsstelle finden Sie unter How to: Specify the Certificate Authority Certificate Chain Used to Verify Signatures.
Hinweis
Jeder Aussteller kann als eine vertrauenswürdige Stammzertifizierungsstelle festgelegt werden, indem man das Zertifikat des Ausstellers in den Zertifikatspeicher der vertrauenswürdigen Stammzertifizierungsstelle legt.
Vertrauenskette deaktivieren
Beim Erstellen eines neuen Diensts verwenden Sie möglicherweise ein Zertifikat, das nicht von einem vertrauenswürdigen Stammzertifikat ausgestellt wird, oder das ausstellende Zertifikat selbst befindet sich möglicherweise nicht im Speicher der vertrauenswürdigen Stammzertifizierungsstellen. Nur zu Entwicklungszwecken können Sie den Mechanismus vorübergehend deaktivieren, der die Vertrauenskette für ein Zertifikat überprüft. Legen Sie dazu die CertificateValidationMode Eigenschaft auf PeerTrust oder PeerOrChainTrust fest. In beiden Modus wird angegeben, dass das Zertifikat entweder selbst ausgestellt (Peer trust) oder Teil einer Vertrauenskette sein kann. Die Eigenschaft kann auf eine der folgenden Klassen festgelegt werden:
Sie können die Eigenschaft auch mithilfe der Konfiguration festlegen. Die folgenden Elemente werden verwendet, um den Überprüfungsmodus anzugeben:
Benutzerdefinierte Authentifizierung
Mit der CertificateValidationMode Eigenschaft können Sie auch anpassen, wie Zertifikate authentifiziert werden. Die Standardvertrauensebene ist ChainTrust. Um den Custom Wert zu verwenden, müssen Sie auch das CustomCertificateValidatorType Attribut auf eine Assembly und einen Typ festlegen, der zum Überprüfen des Zertifikats verwendet wird. Um einen benutzerdefinierten Validator zu erstellen, müssen Sie von der abstrakten Klasse erben X509CertificateValidator .
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 im X.509-Zertifikatüberprüfungsbeispiel . Weitere Informationen finden Sie unter Benutzerdefinierte Berechtigungen und Überprüfung der Anmeldeinformationen.
Verwenden des PowerShell-New-SelfSignedCertificate-Cmdlets zum Erstellen einer Zertifikatkette
Das PowerShell-New-SelfSignedCertificate-Cmdlet erstellt X.509-Zertifikate und private Schlüssel/öffentliche Schlüsselpaare. Sie können den privaten Schlüssel auf dem Datenträger speichern und dann verwenden, um neue Zertifikate auszugeben und zu signieren, wodurch eine Hierarchie von verketteten Zertifikaten simuliert wird. Das Cmdlet ist nur für die Verwendung als Hilfe beim Entwickeln von Diensten vorgesehen und sollte niemals zum Erstellen von Zertifikaten für die tatsächliche Bereitstellung verwendet werden. Verwenden Sie beim Entwickeln eines WCF-Diensts die folgenden Schritte, um eine Vertrauenskette mit dem Cmdlet New-SelfSignedCertificate zu erstellen.
Erstellen Sie mithilfe des Cmdlets New-SelfSignedCertificate ein (selbstsigniertes) temporäres Stammzertifikat. Speichern Sie den privaten Schlüssel auf dem Datenträger.
Verwenden Sie das neue Zertifikat, um ein anderes Zertifikat auszugeben, das den öffentlichen Schlüssel enthält.
Importieren Sie das Zertifikat der Stammzertifizierungsstelle in den Speicher vertrauenswürdiger Stammzertifizierungsstellen.
Schritt-für-Schritt-Anleitungen finden Sie unter So erstellen Sie temporäre Zertifikate zur Verwendung während der Entwicklung.
Welches Zertifikat soll verwendet werden?
Häufig gestellte Fragen zu Zertifikaten sind das zu verwendende Zertifikat und warum. Die Antwort hängt davon ab, ob Sie einen Client oder Dienst programmieren. Die folgenden Informationen enthalten eine allgemeine Richtlinie und sind keine vollständige Antwort auf diese Fragen.
Dienstzertifikate
Dienstzertifikate haben die primäre Aufgabe, den Server für Clients zu authentifizieren. Eine der ersten Überprüfungen, wenn ein Client einen Server authentifiziert, besteht darin, den Wert des Felds "Betreff " mit dem URI (Uniform Resource Identifier) zu vergleichen, der zum Kontaktieren des Diensts verwendet wird: Das DNS beider Muss übereinstimmen. Wenn beispielsweise der URI des Diensts ist http://www.contoso.com/endpoint/ , muss das Feld "Betreff " auch den Wert www.contoso.comenthalten.
Beachten Sie, dass das Feld mehrere Werte enthalten kann, wobei jedem eine Initialisierung vorangestellt wird, um den Wert anzugeben. In der Regel ist die Initialisierung "CN" für allgemeiner Name, z. B. CN = www.contoso.com. Es ist auch möglich, dass das Feld " Betreff " leer ist, in diesem Fall kann das Feld " Alternativer Antragstellername " den DNS-Namenwert enthalten.
Beachten Sie außerdem, dass der Wert des Felds " Beabsichtigte Zwecke " des Zertifikats einen geeigneten Wert enthalten sollte, z. B. "Serverauthentifizierung" oder "Clientauthentifizierung".
Clientzertifikate
Clientzertifikate werden in der Regel nicht von einer Drittanbieterzertifizierungsstelle ausgestellt. 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. Der Client kann ein solches Zertifikat verwenden, wenn eine gegenseitige Authentifizierung erforderlich ist.
Onlinesperrung und Offlinesperrung
Gültigkeit des Zertifikats
Jedes Zertifikat gilt nur für einen bestimmten Zeitraum, der als Gültigkeitszeitraum bezeichnet wird. Der Gültigkeitszeitraum wird durch die Felder Gültig von und Gültig bis eines X.509-Zertifikats definiert. Während der Authentifizierung wird das Zertifikat überprüft, um festzustellen, ob das Zertifikat noch innerhalb des Gültigkeitszeitraums liegt.
Zertifikatsperrliste
Jederzeit während des Gültigkeitszeitraums kann die Zertifizierungsstelle ein Zertifikat widerrufen. Dies kann aus vielen Gründen auftreten, z. B. eine Kompromittierung des privaten Schlüssels des Zertifikats.
In diesem Fall sind alle Ketten, die vom widerrufenen Zertifikat absteigen, ebenfalls ungültig und während der Authentifizierungsverfahren nicht vertrauenswürdig. Um herauszufinden, welche Zertifikate widerrufen werden, veröffentlicht jeder Aussteller eine Zeit- und datumsstempelte Zertifikatsperrliste (CRL). Die Liste kann entweder mithilfe des Onlinesperrens oder des Offlinesperrens überprüft werden, indem die RevocationMode- oder DefaultRevocationMode-Eigenschaft der folgenden Klassen auf einen der X509RevocationMode-Enumerationswerte festgelegt wird: X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthentication und die IssuedTokenServiceCredential-Klassen. Der Standardwert für alle Eigenschaften lautet Online.
Sie können den Modus auch über die Konfiguration festlegen. Verwenden Sie dazu das revocationMode-Attribut – sowohl von <authentication> (von <serviceBehaviors>) als auch von <authentication> (von <endpointBehaviors>).
Die SetCertificate-Methode
In WCF müssen Sie häufig ein Zertifikat oder eine Gruppe von Zertifikaten angeben, die ein Dienst oder ein Client verwenden soll, um eine Nachricht zu authentifizieren, zu verschlüsseln oder digital zu signieren. Sie können dies programmgesteuert ausführen, indem Sie die SetCertificate Methode verschiedener Klassen verwenden, die X.509-Zertifikate darstellen. Die folgenden Klassen verwenden die SetCertificate Methode, um ein Zertifikat anzugeben.
Die SetCertificate Methode funktioniert durch Festlegen eines Speicherorts und eines Speichers sowie eines "Find"-Typs (x509FindType Parameter), der ein Feld des Zertifikats angibt und einen Wert, der in diesem Feld gesucht wird. Der folgende Code erstellt beispielsweise eine ServiceHost Instanz und legt das Dienstzertifikat fest, das zum Authentifizieren des Diensts für Clients mit der SetCertificate Methode verwendet wird.
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");
Dim baseAddress As New Uri("http://cohowinery.com/services")
Dim sh As New ServiceHost(GetType(CalculatorService), baseAddress)
sh.Credentials.ServiceCertificate.SetCertificate( _
StoreLocation.LocalMachine, StoreName.My, _
X509FindType.FindBySubjectName, "cohowinery.com")
Mehrere Zertifikate mit demselben Wert
Ein Speicher kann mehrere Zertifikate mit dem gleichen Antragstellernamen enthalten. Dies bedeutet, dass eine Ausnahme ausgelöst wird, wenn Sie angeben, dass das x509FindType-Zertifikat, FindBySubjectName oder FindBySubjectDistinguishedName sein soll und mehrere Zertifikate denselben Wert aufweisen, da es keine Möglichkeit gibt zu unterscheiden, welches Zertifikat erforderlich ist. Sie können dies verringern, indem Sie x509FindType auf FindByThumbprint setzen. Das Fingerabdruckfeld enthält einen eindeutigen Wert, mit dem ein bestimmtes Zertifikat in einem Speicher gefunden werden kann. Dies hat jedoch einen eigenen Nachteil: Wenn das Zertifikat widerrufen oder erneuert wird, schlägt die SetCertificate Methode fehl, da auch der Fingerabdruck nicht mehr vorhanden ist. Oder wenn das Zertifikat nicht mehr gültig ist, schlägt die Authentifizierung fehl. Der Weg, dies zu mindern, besteht darin, den x590FindType Parameter auf FindByIssuerName festzulegen und den Namen des Ausstellers anzugeben. Wenn kein bestimmter Aussteller erforderlich ist, können Sie auch einen der anderen X509FindType Enumerationswerte festlegen, wie z.B. FindByTimeValid.
Zertifikate in der Konfiguration
Sie können Zertifikate auch mithilfe der Konfiguration festlegen. Wenn Sie einen Dienst erstellen, werden Anmeldeinformationen, einschließlich Zertifikaten, unter den <ServiceBehaviors> angegeben. Wenn Sie einen Client programmieren, werden Zertifikate unter <endpointBehaviors> spezifiziert.
Zuordnen eines Zertifikats zu einem Benutzerkonto
Ein Feature von IIS und Active Directory ist die Möglichkeit, ein Zertifikat einem Windows-Benutzerkonto zuzuordnen. Weitere Informationen zum Feature finden Sie unter Zuordnen von Zertifikaten zu Benutzerkonten.
Weitere Informationen zur Verwendung der Active Directory-Zuordnung finden Sie unter Zuordnen von Clientzertifikaten mit Verzeichnisdienstzuordnung.
Wenn diese Funktion aktiviert ist, können Sie die MapClientCertificateToWindowsAccount Eigenschaft der X509ClientCertificateAuthentication Klasse auf truefestlegen. In der Konfiguration können Sie das mapClientCertificateToWindowsAccount-Attribut des <Authentifizierungselements> auf true festlegen, wie im folgenden Code gezeigt.
<serviceBehaviors>
<behavior name="MappingBehavior">
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="None" mapClientCertificateToWindowsAccount="true" />
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
Das Zuordnen eines X.509-Zertifikats zum Token, das ein Windows-Benutzerkonto darstellt, wird als Rechteerweiterung betrachtet, da das Windows-Token nach der Zuordnung verwendet werden kann, um Zugriff auf geschützte Ressourcen zu erhalten. Daher erfordert die Domänenrichtlinie, dass das X.509-Zertifikat ihrer Richtlinie entspricht, bevor es zugeordnet wird. Das SChannel-Sicherheitspaket erzwingt diese Anforderung.
Bei Verwendung von .NET Framework 3.5 oder höher stellt WCF sicher, dass das Zertifikat der Domänenrichtlinie entspricht, bevor es einem Windows-Konto zugeordnet wird.
In der ersten Version von WCF erfolgt die Zuordnung ohne Konsultation der Domänenrichtlinie. Daher ist es möglich, dass ältere Anwendungen, die bei der Ausführung unter der ersten Veröffentlichung funktionieren, fehlschlagen, wenn das Mapping aktiviert ist und das X.509-Zertifikat die Domänenrichtlinie nicht erfüllt.