Schannel SSP – technische Übersicht

  • Artikel

 

Veröffentlicht: August 2016

Gilt für: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

In diesem Referenzthema für IT-Experten wird erklärt, was der Security Support Provider (SSP) für den sicheren Kanal (Secure Channel, Schannel) ist, und welche Authentifizierungsdienste er mithilfe der Protokolle Transport Layer Security (TLS) und Secure Sockets Layer (SSL) bereitstellt.

Dieses Thema enthält die folgenden Abschnitte:

Hinweis

TLS wird im Thema Transport Layer Security-Protokoll beschrieben.

DTLS, das im Schannel SSP enthalten ist, wird im Thema Datagram Transport Layer Security protocol beschrieben.

Was sind TLS, SSL und Schannel?

Ein Problem beim Verwalten eines Netzwerks ist das Sichern von Daten, die in einem nicht vertrauenswürdigen Netzwerk zwischen Anwendungen gesendet werden. Sie können Server- und Clientcomputer mit TLS/SSL authentifizieren und dann dazu verwenden, Nachrichten zwischen den authentifizierten Parteien zu verschlüsseln.

TLS-Protokolle, SSL-Protokolle, DTLS-Protokoll und das Private Communications Transport-Protokoll (PCT) basieren auf Kryptografie mit öffentlichen Schlüsseln. Die Schannel-Authentifizierungsprotokollsammlung enthält diese Protokolle. Alle Schannel-Protokolle verwenden ein Client- und Servermodell. Eine Liste der unterstützten Protokolle finden Sie unter Unterstützte Verschlüsselungssammlungen und Protokolle im Schannel-SSP.

Bei der Authentifizierung sendet ein TLS/SSL-Client eine Nachricht an einen TLS/SSL-Server, und der Server antwortet mit den entsprechenden Informationen, um sich zu authentifizieren. Client und Server führen einen weiteren Austausch der Sitzungsschlüssel durch, und der Authentifizierungsdialog wird beendet. Nach Abschluss der Authentifizierung kann die SSL-Kommunikation zwischen dem Server und dem Client mithilfe der symmetrischen Verschlüsselungsschlüssel, die während des Authentifizierungsprozesses eingerichtet werden, beginnen.

Für die Authentifizierung von Servern bei Clients setzt TLS/SSL nicht voraus, dass Serverschlüssel auf Domänencontrollern oder in einer Datenbank, wie z. B. Active Directory-Domänendiensten, gespeichert werden. Clients überprüfen die Gültigkeit der Anmeldeinformationen eines Servers mit Zertifikaten vertrauenswürdiger Stammzertifizierungsstellen (Certification Authority, CA), die geladen werden, wenn Sie ein Windows-Betriebssystem installieren. Darum müssen Benutzer keine Konten einrichten, bevor sie eine sichere Verbindung mit einem Server herstellen, solange der Server keine Benutzerauthentifizierung fordert.

Geschichte und Standards von TLS und SSL

SSL wurde 1994 von der Netscape Communications Corporation zur Sicherung von Transaktionen über das World Wide Web entwickelt. Bald danach begann die Internet Engineering Task Force (IETF), ein Standardprotokoll zu entwickeln, das die gleichen Funktionen bieten sollte. Sie verwendete SSL 3.0 als Grundlage dieser Arbeit, aus der das TLS-Protokoll hervorging. Die mit Windows Server 2003 beginnende Implementierung des TLS-Protokolls orientiert sich eng an der Spezifikation, die in den folgenden, in der IETF RFC-Datenbank aufgeführten Spezifikationen definiert ist:

TLS und SSL sind vorwiegend als Protokolle bekannt, die eine sichere HTTP-Verbindung (HTTP Secure, HTTPS) für Internettransaktionen zwischen Webbrowsern und Webservern bereitstellen. TLS/SSL kann auch auf anderer Anwendungsebene als Protokoll eingesetzt werden, z. B. als FTP (File Transfer Protocol), LDAP (Lightweight Directory Access Protocol) und SMTP (Simple Mail Transfer Protocol). TLS/SSL ermöglicht Serverauthentifizierung, Clientauthentifizierung, Datenverschlüsselung und Datenintegrität über Netzwerke wie das World Wide Web.

Unterschiede zwischen TLS und SSL

Es gibt zwar einige geringfügige Unterschiede zwischen SSL 3.0 und den TLS-Versionen, doch dieses Referenzhandbuch bezieht sich mit TLS/SSL auf das Protokoll.

Hinweis

TLS und SSL 3.0 sind nicht untereinander austauschbar, obwohl ihre Unterschiede minimal sind. Wenn Client und Server nicht das gleiche Protokoll unterstützen, müssen sie ein gemeinsames Protokoll aushandeln, um miteinander kommunizieren zu können.

Da SSL aufgrund der steigenden Zahl sicherheitsgefährdender Angriffe anfälliger wurde, entwickelte die IETF Internetstandards für ein sichereres Protokoll – TLS. In der folgenden Liste werden TLS-Verbesserungen aufgeführt, die die Fähigkeit von SSL zur sicheren Kommunikation über nicht vertrauenswürdige Netzwerke übertreffen.

  • Der Algorithmus für den Nachrichtenauthentifizierungscode mit Schlüsselhash (Hash Message Authentication Code, HMAC) ersetzt den Algorithmus für den SSL-Nachrichtenauthentifizierungscode (Message Authentication Code, MAC).

  • TLS ist standardisiert, und zwar ein Internetstandard, während SSL in zahlreichen Varianten vorliegt.

  • TLS enthält zusätzliche Warnmeldungen.

  • SSL benötigt Zertifikate, die von der Stammzertifizierungsstelle ausgegeben werden (oder mit ihr rückverkettet sind). Wenn Sie TLS verwenden, benötigen Sie nicht immer mit der Stammzertifizierungsstelle rückverkettete Zertifikate. Sie können eine zwischengeschaltete Autorität verwenden.

  • Fortezza-Algorithmen sind nicht in der RFC TLS enthalten, da sie nicht zur öffentlichen Prüfung offenliegen.

Vorteile von TLS und SSL

TLS/SSL bietet zahlreiche Vorteile gegenüber anderen Methoden der Authentifizierung für Clients und Server. In der folgenden Tabelle werden einige dieser Vorteile beschrieben:

Vorteil

Beschreibung

Sichere Authentifizierung, starker Datenschutz von Nachrichten sowie Integrität.

TLS/SSL kann die sichere Datenübertragung mithilfe der Verschlüsselung unterstützen. TLS/SSL authentifiziert Server und optional Clients, um die Identität der Systeme zu prüfen, die an der sicheren Kommunikation beteiligt sind.

Darüber hinaus sorgt ein Integritätsprüfwert für die Datenintegrität.

Zusätzlich zum Schutz vor Offenlegung von Daten kann das Sicherheitsprotokoll TLS/SSL zur Unterstützung zum Schutz gegen maskierte Angriffe, Man-in-the-Middle- oder Bucket-Brigade-Angriffe, Rollback-Angriffe sowie Replay-Angriffe verwendet werden.

Interoperabilität

TLS/SSL ist mit den meisten Webbrowsern und auf den meisten Betriebssystemen und Webservern einsetzbar. Es ist häufig in Newsreader, LDAP-Server sowie eine Vielzahl anderer im Handel erhältlicher Anwendungen integriert.

Algorithmusflexibilität

TLS/SSL bietet Optionen für die Authentifizierungsmechanismen, Verschlüsselungsalgorithmen und Hashalgorithmen, die während der sicheren Sitzung verwendet werden.

Mühelose Bereitstellung

Viele Anwendungen verwenden TLS/SSL transparent in Windows Server-Betriebssystemen. Sie können TLS für sichereres Surfen nutzen, wenn Sie Internet Explorer und Internet Information Services (IIS) verwenden. Wenn auf dem Server bereits ein Serverzertifikat installiert wurde, müssen Sie nur das Kontrollkästchen im Internet Explorer aktivieren.

Einfache Verwendung

Da Sie TLS/SSL unter der Anwendungsschicht implementieren, sind die meisten TLS/SSL-Vorgänge für den Clientcomputer vollständig unsichtbar. So benötigt der Client nur wenige oder gar keine Kenntnisse über die Sicherheit der Kommunikation und ist dennoch vor Angriffen geschützt.

Einschränkungen bei TLS und SSL

Es gibt einige Einschränkungen bei der Verwendung von TLS/SSL, wie in der folgenden Tabelle beschrieben.

Einschränkung

Beschreibung

Erhöht die Prozessorauslastung

Dies ist die wichtigste Einschränkung bei der Implementierung von TLS/SSL. Kryptografie, insbesondere bei Vorgängen mit öffentlichen Schlüsseln, beansprucht die CPU sehr. Folglich variiert die Leistung bei der Verwendung von SSL. Leider können Sie nicht ermitteln, wie viel Leistung Sie verlieren. Die Leistung variiert, je nachdem, wie oft Verbindungen hergestellt werden, und wie lange sie andauern. TLS belastet die Ressourcen vor allem beim Einrichten von Verbindungen.

Verwaltungsaufwand

Eine TLS/SSL-Umgebung ist komplex und muss gewartet werden. Der Systemadministrator muss das System konfigurieren und Zertifikate verwalten.

Gängige TLS- und SSL-Szenarien

Viele sehen in TLS und SSL Protokolle, die in Verbindung mit Webbrowsern verwendet werden, um ein sichereres Surfen im Internet zu ermöglichen. Sie sind jedoch auch Allzweckprotokolle, die immer dann verwendet werden können, wenn Authentifizierung und Datenschutz erforderlich sind. In der Tat bedeutet die Fähigkeit, auf diese Protokolle über die Security Support Provider-Schnittstelle (Security Support Provider Interface, SSPI) zugreifen zu können, dass Sie sie für fast jede Anwendung verwenden können. Viele Anwendungen werden so geändert, dass sie die Funktionen von TLS/SSL nutzen können. Die folgende Tabelle enthält Beispiele für die Verwendung von TLS/SSL.

Szenario

Beschreibung

SSL-Transaktionen mit einer E-Commerce-Website

Diese Situation ist typisch für die Verwendung von SSL bei der Verbindung zwischen einem Browser und einem Webserver. Beispiel: Auf einer E-Commerce-Einkaufswebsite müssen Kunden ihre Kreditkartennummern angeben. Das Protokoll prüft zunächst, ob das Zertifikat der Website gültig ist. Wenn dies zutrifft, sendet es die Kreditkartendaten als verschlüsselten Text. Bei dieser Art der Transaktion erfolgt die Authentifizierung nur für den Server, wenn das Zertifikat des Servers aus einer vertrauenswürdigen Quelle stammt. TLS/SSL muss für die Webseite, z. B. ein Bestellformular, auf dem die Datentransaktion stattfindet, aktiviert werden.

Authentifizierter Clientzugriff auf eine SSL-gesicherte Website

Client und Server benötigen Zertifikate von einer Zertifizierungsstelle (Certification Authority, CA), die beide als vertrauenswürdig einstufen. Mit dem Schannel SSP können Clientzertifikate auf "Eins-zu-eins"- oder "Viele-zu-eins"-Basis Benutzer- oder Computerkonten auf einem Windows Server-Betriebssystem zugeordnet werden. Anschließend können sie über Active Directory-Benutzer und -Computer verwaltet werden, und Benutzer können ohne Angabe eines Kennworts auf einer Website authentifiziert werden.

Für die "Viele-zu-eins"-Zuordnung gibt es verschiedene Nutzungsmöglichkeiten. Wenn Sie z. B. mehreren Benutzern Zugriff auf vertrauliches Material gewähren möchten, können Sie eine Gruppe erstellen, der Gruppe die Zertifikate der Benutzer zuordnen und ihr die erforderlichen Berechtigungen für das Material erteilen.

Bei der "Eins-zu-eins"-Zuordnung besitzt der Server eine Kopie des Zertifikats des Clients, und wenn sich ein Benutzer vom Clientcomputer aus anmeldet, überprüft der Server die Identität. Diese "Eins-zu-eins"-Zuordnung wird normalerweise für privates Material verwendet, z. B. eine Bankingwebsite, wo nur eine einzige Person zur Anzeige eines persönlichen Kontos berechtigt ist.

Remotezugriff

SSP-Schannel wird häufig für Telearbeit verwendet. Mit dieser Technologie können Sie Authentifizierung und Datenschutz für die Remoteanmeldung von Benutzern bei Systemen oder Netzwerken auf Windows-Basis bereitstellen. Die Benutzer können sicherer von zu Hause oder unterwegs auf ihre E-Mail- oder Unternehmensanwendungen zugreifen, und das Risiko der Offenlegung von Informationen gegenüber beliebigen Internetnutzern ist reduziert.

SQL-Serverzugriff

Sie können die Authentifizierung eines Clientcomputers anfordern, wenn er sich mit einem Server verbindet, der SQL Server ausführt. Der Client oder Server kann dazu konfiguriert werden, die Verschlüsselung zwischen ihnen übertragener Daten anzufordern. Höchst vertrauliche Daten, z. B. aus Finanz-oder medizinischen Datenbanken, können vor unautorisiertem Zugriff und Offenlegung von Informationen über das Netzwerk geschützt werden.

E-Mail

Wenn Sie Exchange Server verwenden, können Sie mit dem Schannel SSP Daten schützen, während sie über Intranet oder Internet von Server zu Server verschoben werden. Vollständige "End-to-End"-Sicherheit könnte die Verwendung von Secure/Multipurpose Internet Mail Extensions (S/MIME) erfordern. Der Beitrag zum Schutz von Daten in einem "Server-zu-Server"-Austausch erlaubt Unternehmen jedenfalls, E-Mail zwischen Abteilungen des Unternehmens, Tochtergesellschaften und Partnern sicher über das Internet zu übertragen. Dies kann unabhängig davon geschehen, ob S/MIME verwendet wird.

Schannel SSP-Architektur

In den Windows Server-Betriebssystemen enthält die Schannel-Authentifizierungsprotokollsuite TLS. Das folgende Diagramm zeigt, wo der Schannel SSP zwischen diesen und anderen Technologien seinen Platz hat. Client- oder Serveranwendungen verwenden Secur32.dll über SSPI-Aufrufe, um mit dem Subsystemdienst für die lokale Sicherheitsautorität (Local Security Authority Subsystem Service, LSASS) zu kommunizieren.

Schannel SSP-Architektur

Schannel Architecture

Die folgende Tabelle enthält Beschreibungen der Elemente, die an TLS/SSL beteiligt sind.

Bei der TLS- und SSL-Authentifizierung verwendete Sicherheitssubsystemelemente

Element

Beschreibung

Schannel.dll

TLS/SSL-Authentifizierungsprotokoll. Dieses Protokoll ermöglicht die Authentifizierung über einen verschlüsselten Kanal anstelle eines weniger sicheren unverschlüsselten Kanals.

Lsasrv.dll

Der LSASS erzwingt Sicherheitsrichtlinien und fungiert als Sicherheitspaket-Manager für die lokale Sicherheitsautorität.

Netlogon.dll

Im Hinblick auf die TLS-Dienste übergibt der Netlogon-Dienst die Zertifikatinformationen des Benutzers über einen SSL-Kanal an den Domänencontroller, um das Benutzerzertifikat einem Benutzerkonto zuordnen.

Secur32.dll

Der Mehrfachauthentifizierungsanbieter, der SSPI implementiert.

Die Authentifizierungsprotokollsuite wird durch den Schannel SSP aktiviert, der von der SSPI-Anwendungsprogrammierschnittstelle (Application Programming Interface, API) unterstützt wird, die die Sicherheitsdienste für Windows Server-Betriebssysteme bereitstellt.

Die Microsoft Security Support Provider-Schnittstelle (SSPI) ist die Grundlage für die Authentifizierung im Windows-Betriebssystem. D. h., Anwendungen und Infrastrukturdienste, die eine Authentifizierung erfordern, verwenden SSPI, um die Authentifizierungsfunktionalität bereitzustellen. Wenn ein Client und ein Server authentifiziert werden müssen, damit sie sicherer kommunizieren können, werden die Anforderungen für die Authentifizierung an die SSPI weitergeleitet, die den Authentifizierungsvorgang unabhängig vom derzeit ausgeführten Netzwerkprotokoll ausführt. Die SSPI ist die Implementierung der Generic Security Service API (GSSAPI). Weitere Informationen über die GSSAPI finden Sie unter den folgenden RFCs in der IETF RFC-Datenbank.

Informationen über die SSPI-Architektur für alle SSPs und darüber, wie der Kerberos-Anbieter in diese Architektur passt, finden Sie unter Security Support Provider Interface Architecture.

Sie können den Schannel SSP für den Zugriff auf webfähige Dienste, wie z. B. E-Mail oder persönliche Daten verwenden, die auf Webseiten bereitgestellt werden. Der Schannel SSP verwendet Zertifikate für öffentliche Schlüssel zum Authentifizieren von Parteien. Er enthält vier Authentifizierungsprotokolle in der Suite. Beim Authentifizieren von Parteien wählt er eines der vier Protokolle in der folgenden Prioritätsreihenfolge aus:

  1. TLS Version 1.2

  2. TLS Version 1.1

  3. TLS Version 1.0

  4. SSL Version 3.0

Der Schannel SSP wählt dann das bevorzugte Authentifizierungsprotokoll, das Client und Server unterstützen können. Wenn ein Server beispielsweise alle vier Schannel-Protokolle, und der Client-Computer nur SSL 3.0 unterstützt, verwendet der Schannel-Anbieter SSL 3.0 für die Authentifizierung.

Verwaltung vertrauenswürdiger Aussteller für die Clientauthentifizierung

Vor Windows Server 2012 und Windows 8 konnten Anwendungen oder Prozesse, die den Schannel SSP verwendeten (einschließlich HTTP.sys und IIS), eine Liste der vertrauenswürdigen Aussteller übermitteln, die von ihnen für die Clientauthentifizierung unterstützt wurden. Diese Information wurde durch eine Zertifikatvertrauensliste (Certificate Trust List, CTL) bereitgestellt.

Wenn die Authentifizierung des Clientcomputers über SSL oder TLS erforderlich ist, kann der Server so konfiguriert werden, dass er eine Liste vertrauenswürdiger Zertifikataussteller sendet. Diese Liste enthält die Gruppe der Zertifikataussteller, denen der Server vertraut, und gibt dem Clientcomputer einen Hinweis zur Auswahl des Clientzertifikats, falls mehrere Zertifikate vorhanden sind. Darüber hinaus muss die Zertifikatkette, die der Clientcomputer an den Server sendet, anhand der Liste der konfigurierten vertrauenswürdigen Aussteller überprüft werden.

In Windows Server 2012 und Windows 8 wurden folgende Änderungen am zugrunde liegenden Authentifizierungsprozess vorgenommen:

  1. Eine CTL-basierte Verwaltung der Liste vertrauenswürdiger Aussteller wird nicht mehr unterstützt.

  2. Das Verhalten, die Liste vertrauenswürdiger Aussteller zu senden, ist standardmäßig deaktiviert. Der Standardwert des Registrierungsschlüssels SendTrustedIssuerList ist jetzt 0 (deaktiviert) anstatt 1.

  3. Die Kompatibilität mit früheren Versionen von Windows-Betriebssystemen wurde gewahrt.

Dies ermöglicht eine vertrautere Verwaltung mithilfe der vorhandenen Cmdlets zur Zertifikatverwaltung im Windows PowerShell-Anbieter und von Befehlszeilentools wie certutil.exe. Obwohl die maximale Größe der Liste der von Schannel SSP unterstützten vertrauenswürdigen Zertifizierungsstellen (16 KB) gegenüber Windows Server 2008 R2 gleich geblieben ist, gibt es in Windows Server 2012 einen neuen, dedizierten Zertifikatspeicher für Clientauthentifizierungsaussteller, sodass die Client-/Servernachricht keine nicht zugehörigen Zertifikate enthält.

Funktionsweise

Die Liste vertrauenswürdiger Aussteller wird mithilfe von Zertifikatspeichern konfiguriert: einem standardmäßigen globalen Computerzertifikatspeicher und einem optional vorhandenen websitespezifischen Zertifikatspeicher. Die Quelle der Liste wird wie folgt bestimmt:

  • Wenn ein bestimmter Anmeldeinformationsspeicher für diese Website konfiguriert ist, wird dieser als Quelle verwendet.

  • Wenn keine Zertifikate in dem von der Anwendung definierten Speicher vorhanden sind, prüft Schannel den Speicher Clientauthentifizierungsaussteller auf dem lokalen Computer. Wenn Zertifikate vorhanden sind, verwendet Schannel diesen Speicher als Quelle.

  • Wenn weder die globalen noch die lokalen Speicher Zertifikate enthalten, verwendet der Schannel SSP den Speicher Vertrauenswürdige Stammzertifizierungsstellen als Quelle der Liste vertrauenswürdiger Aussteller. (Dies ist identisch mit dem Verhalten in Windows Server 2008 R2.)

Sie können eine Liste der Namen wahrscheinlicher Zertifikataussteller erstellen, die dem Endbenutzer Hinweise liefert, welchen er auswählen soll. Diese Liste kann mit einer Gruppenrichtlinie konfiguriert werden.

Wenn der Speicher Vertrauenswürdige Stammzertifizierungsstellen eine Mischung aus (selbstsignierten) Zertifikaten von Stammausstellern und Zertifikaten von Zertifizierungsstellen enthält, werden standardmäßig nur die Zertifikate von Zertifizierungsstellen an den Server gesendet.

Konfigurieren von Schannel zur Verwendung des Zertifikatspeichers für vertrauenswürdige Aussteller

Der Schannel SSP verwendet standardmäßig den oben beschriebenen Speicher zur Verwaltung der Liste vertrauenswürdiger Aussteller. Sie können weiterhin die vorhandenen Cmdlets für die Zertifikatverwaltung im Windows PowerShell-Anbieter und Befehlszeilentools wie certutil.exe verwenden, um Zertifikate zu verwalten.

Informationen zum Verwalten von Zertifikaten mithilfe des Windows PowerShell-Anbieters finden Sie unter AD CS-Verwaltungs-Cmdlets in Windows PowerShell.

Informationen zum Verwalten von Zertifikaten mithilfe des Zertifikatdienstprogramms finden Sie unter certutil.exe.

Informationen dazu, welche Daten (einschließlich des anwendungsdefinierten Speichers) als Anmeldeinformationen für Schannel definiert sind, finden Sie unter SCHANNEL_CRED-Struktur (Windows).

Konfigurieren einer Anwendung oder eines Features, um den Clientauthentifizierungsaussteller-Speicher zu verwenden

Einige Technologien verwenden standardmäßig nicht den Clientauthentifizierungsaussteller-Speicher. In diesen Fällen müssen Sie die Technologie konfigurieren, um den Speicher zu verwenden.

HTTP.sys, die den Windows-HTTP-Serverstapel implementiert, wird z. B. nicht standardmäßig mit dem Webserver zur Verwendung des Clientauthentifizierungsaussteller-Speicher konfiguriert.

Um HTTP. SYS zur Verwendung des Clientauthentifizierungsaussteller-Speichers zu konfigurieren, können Sie den folgenden Befehl verwenden:

netsh http add sslcert ipport=0.0.0.0:443 certhash=GUID hash value appid={GUID application identifier}  sslctlstorename=ClientAuthIssuer

Um die Werte für "certhash" und "appid" auf Ihrem Server zu finden, können Sie den folgenden Befehl verwenden:

netsh http show sslcert

Standardeinstellungen für Vertrauensstellungsmodi

Es gibt drei Vertrauensstellungsmodi für die Clientauthentifizierung durch den Schannel SSP. Der vertrauenswürdige Modus steuert, wie die Überprüfung der Zertifikatkette des Clients ausgeführt wird. Dabei handelt es sich um eine systemweite Einstellung, die durch den REG_DWORD-Wert "ClientAuthTrustMode" unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel gesteuert wird.

Wert

Vertrauensstellungsmodus

Beschreibung

0

Maschinenvertrauensstellung (Standard)

Erfordert, dass das Clientzertifikat von einem Zertifikat in der Liste der vertrauenswürdigen Aussteller ausgestellt wird.

1

Exklusive Stammvertrauensstellung

Erfordert, dass das Clientzertifikat in der Zertifikatkette auf ein Stammzertifikat zurückgeht, das in dem durch den Aufrufer festgelegten Speicher für vertrauenswürdige Aussteller enthalten ist. Das Zertifikat muss auch von einem Aussteller aus der Liste der vertrauenswürdigen Aussteller ausgestellt worden sein.

2

Exklusive Zertifizierungsstellen-Vertrauensstellung

Erfordert, dass das Clientzertifikat in der Zertifikatkette auf ein dazwischenliegendes Zertifizierungsstellenzertifikat oder ein Stammzertifikat zurückgeht, das in dem durch den Aufrufer festgelegten Speicher für vertrauenswürdige Aussteller enthalten ist.

Informationen zu Authentifizierungsfehlern aufgrund von Konfigurationsproblemen in der Liste vertrauenswürdiger Aussteller finden Sie in der Microsoft Knowledge Base in Artikel 280256.

TLS- und SSL-Abhängigkeiten

TLS und SSL hängen von der ordnungsgemäßen Funktion mehrerer verwandter Technologien und Ressourcen ab. Die folgende Tabelle beschreibt diese Technologien und Ressourcen und fasst deren Beziehung zur TLS/SSL-Authentifizierung zusammen.

Abhängigkeit

Beschreibung

Betriebssystem

TLS- und SSL-Authentifizierung basieren auf der Clientfunktionalität, die in die Windows Server-Betriebssysteme und Windows-Clientbetriebssysteme integriert ist. Wenn ein Client oder Server ein Betriebssystem ausführt, das TLS/SSL nicht unterstützt, kann er die TLS/SSL-Authentifizierung nicht verwenden.

TCP/IP-Netzwerkkonnektivität

Voraussetzung der TLS- oder SSL-Authentifizierung ist die TCP/IP-Netzwerkkonnektivität zwischen Client und Zielserver. Weitere Informationen finden Sie unter TCP/IP.

Active Directory-Domäne

Wenn eine Serveranwendung eine Clientauthentifizierung durchführen muss, versucht Schannel SSP automatisch, das vom Client angebotene Zertifikat einem Benutzerkonto zuzuordnen. Sie können Benutzer authentifizieren, die sich mit einem Clientzertifikat anmelden, indem Sie manuell Zuordnungen erstellen, die die Zertifikatsinformationen mit einem Windows-Benutzerkonto verknüpfen. Nach dem Erstellen und Aktivieren einer Zertifikatszuordnung verknüpft Ihre Serveranwendung jedes Mal, wenn ein Client ein Zertifikat vorlegt, diesen Benutzer mit dem entsprechenden Benutzerkonto im Windows-Betriebssystem. Wenn Sie die Zertifikatzuordnung verwenden möchten, müssen Sie Benutzerkonten im Active Directory-Domänendienst verwenden. Weitere Informationen finden Sie unter Übersicht über Active Directory-Domänendienste.

Vertrauenswürdige Zertifizierungsstellen

Da die Authentifizierung von digitalen Zertifikaten abhängig ist, sind Zertifizierungsstellen (CAs) (wie z. B. Verisign oder Active Directory-Zertifikatdienste) ein wichtiger Teil von TLS/SSL. Eine Zertifizierungsstelle ist ein einvernehmlich vertrauenswürdiges Zertifikat außerhalb von Microsoft, das die Identität eines Zertifikatantragstellers (für gewöhnlich ein Benutzer oder Computer) bestätigt und dem Antragsteller dann ein Zertifikat ausstellt. Das Zertifikat bindet die Identität des Antragstellers an einen öffentlichen Schlüssel. Zertifizierungsstellen erneuern und widerrufen Zertifikate auch je nach Bedarf. Wenn beispielsweise ein Client das Zertifikat eines Servers erhält, kann der Clientcomputer die Zertifizierungsstelle des Servers mit der Liste vertrauenswürdiger Zertifizierungsstellen des Clients vergleichen. Wenn die ausstellende Zertifizierungsstelle vertrauenswürdig ist, wird der Client überprüfen, ob das Zertifikat echt ist und nicht manipuliert wurde. Weitere Informationen über Zertifizierungsstellen finden Sie unter Active Directory-Zertifikatdienste (Übersicht).

Siehe auch

Schannel Security Support Provider technische Referenz