Registrierungseinstellungen für Transport Layer Security (TLS)
Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 11, Windows 10 und frühere Versionen, wie erwähnt
In diesem Artikel werden die unterstützten Registrierungseinstellungen für die Windows-Implementierung des TLS-Protokolls (Transport Layer Security) und des SSL-Protokolls (Secure Sockets Layer) über den Schannel Security Support Provider (SSP) erläutert. Die in diesem Artikel behandelten Registrierungsunterschlüssel und -einträge helfen Ihnen bei der Verwaltung und Problembehandlung des Schannel SSP, speziell bei den Protokollen TLS und SSL.
Achtung
Diese Informationen dienen als Referenz, die Sie nutzen, wenn Sie eine Problembehandlung durchführen oder prüfen, ob die erforderlichen Einstellungen vorhanden sind. Es wird empfohlen, die Registrierung nur dann direkt zu bearbeiten, wenn es keine andere Alternative gibt. Änderungen an der Registrierung werden weder vom Registrierungs-Editor noch vom Windows-Betriebssystem überprüft, bevor sie angewendet werden. Daher können falsche Werte gespeichert werden, was zu nicht behebbaren Fehlern im System führen kann. Statt die Registrierung direkt zu bearbeiten, verwenden Sie nach Möglichkeit „Gruppenrichtlinie“ oder andere Windows-Tools wie die Microsoft Management Console (MMC). Wenn Sie die Registrierung bearbeiten müssen, gehen Sie äußerst umsichtig vor.
Schannel-Protokollierung
Es gibt acht Protokollierungsebenen für Schannel-Ereignisse, die im Systemereignisprotokoll gespeichert und mithilfe der Ereignisanzeige angezeigt werden können. Dieser Registrierungspfad wird in HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL unter dem Schlüssel EventLogging gespeichert, wobei ein DWORD-Wert auf 1 festgelegt wird.
| Dezimal oder Hexadezimal | Schannel-Protokollierungsereignisse |
|---|---|
| 0 | Keine Ereignisse |
| 1 | Fehlerereignisse |
| 2 | Warnungsereignisse |
| 3 | Fehler- und Warnungsereignisse |
| 4 | Informations- und Erfolgsereignisse |
| 5 | Fehler, Informations- und Erfolgsereignisse |
| 6 | Warnungs-, Informations- und Erfolgsereignisse |
| 7 | Fehler-, Warnungs-, Informations- und Erfolgsereignisse |
Hinweis
Nachdem Sie die Schannel-Protokollierungsebene geändert haben, müssen Sie Ihr Gerät neu starten.
CertificateMappingMethods
Wenn eine Serveranwendung die Clientauthentifizierung anfordert, versucht SChannel automatisch das Zertifikat, das vom Clientcomputer bereitgestellt wird, einem Benutzerkonto zuzuordnen. Sie können Benutzer authentifizieren, die sich mit einem Clientzertifikat anmelden, indem Sie Zuordnungen erstellen, die die Zertifikatsinformationen einem Windows-Benutzerkonto zuordnen.
Nachdem Sie eine Zertifikatzuordung erstellt und aktiviert haben, ordnet Ihre Serveranwendung immer dann, wenn ein Client ein Clientzertifikat vorlegt, diesen Benutzer dem entsprechenden Windows-Benutzerkonto zu.
In den meisten Fällen wird ein Zertifikat einem Benutzerkonto auf eine von zwei Arten zugeordnet:
- Ein einzelnes Zertifikat wird einem einzelnen Benutzerkonto zugeordnet (1:1-Zuordnung).
- Mehrere Zertifikate werden einem Benutzerkonto zugeordnet (n:1-Zuordnung).
Der SChannel-Anbieter verwendet vier (4) Zertifikatzuordnungsmethoden:
- Kerberos-S4U-Zuordnung (Service-for-User) (standardmäßig aktiviert)
- Zuordnung von Benutzerprinzipalnamen
- 1:1-Zuordnung (auch bekannt als Antragsteller/Aussteller- Zuordnung)
- n:1-Zuordnung
Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
| Eintragsname | DWORD | Standardmäßig aktiviert |
|---|---|---|
| Subject/Issuer (Antragsteller/Aussteller) | 0x000000001 | Nein |
| Issuer (Aussteller) | 0x000000002 | Nein |
| UPN | 0x000000004 | Nein |
| S4U2Self | 0x000000008 | Ja |
| S4U2Self Explicit | 0x000000010 | Ja |
Geltende Versionen: Entsprechend der Angabe in der Liste Gilt für am Anfang dieses Artikels.
Ciphers
TLS/SSL-Verschlüsselungen sollten durch Konfigurieren der Reihenfolge von Verschlüsselungssammlungen gesteuert werden. Details finden Sie unter Konfigurieren der Reihenfolge von TLS-Verschlüsselungssammlungen.
Informationen zu Standardreihenfolgen von Verschlüsselungssammlungen, die vom SChannel SSP verwendet werden, finden Sie unter Verschlüsselungssammlungen in TLS/SSL (SChannel SSP).
CipherSuites
TLS/SSL-Verschlüsselungssammlungen sollten mithilfe von Gruppenrichtlinien, MDM oder PowerShell konfiguriert werden. Details dazu finden Sie unter Konfigurieren der Reihenfolge von TLS-Verschlüsselungssammlungen.
Informationen zu Standardreihenfolgen von Verschlüsselungssammlungen, die vom SChannel SSP verwendet werden, finden Sie unter Verschlüsselungssammlungen in TLS/SSL (SChannel SSP).
ClientCacheTime
Dieser Eintrag gibt die Lebensdauer von Client-TLS-Sitzungscacheelementen in Millisekunden an. Ab Windows Server 2008 und Windows Vista beträgt die Standardeinstellung 10 Stunden. Der Wert 0 deaktiviert die TLS-Sitzungszwischenspeicherung auf dem Client.
Wenn sich ein Client über den SChannel SSP erstmals mit einem Server verbindet, erfolgt ein vollständiger TLS/SSL-Handshake. Wenn dieser abgeschlossen ist, werden der geheime Hauptschlüssel, die Verschlüsselungssammlung und Zertifikate im Sitzungscache auf dem jeweiligen Client und Server gespeichert.
Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
EnableOcspStaplingForSni
Das Online Certificate Status-Protokoll (OCSP) ermöglicht es einem Webserver, z. B. Internetinformationsdienste (IIS), den aktuellen Sperrstatus eines Serverzertifikats bereitzustellen, wenn er dieses Zertifikat während des TLS-Handshakes an einen Client sendet. Dieses Feature verringert die Last auf OCSP-Servern, weil der Webserver den aktuellen OCSP-Status des Serverzertifikats zwischenspeichern und an mehrere Webclients senden kann. Ohne dieses Feature würde jeder Webclient versuchen, den aktuellen OCSP-Status des Serverzertifikats vom OCSP-Server abzurufen. Dadurch würde eine hohe Last auf diesem OCSP-Server generiert.
Neben IIS können auch Webdienste über „http.sys“ von dieser Einstellung profitieren, darunter Active Directory-Verbunddienste (AD FS) und Webanwendungsproxy (WAP).
Bei IIS-Websites, die eine einfache sichere Bindung (SSL/TLS) haben, ist die OCSP-Unterstützung standardmäßig aktiviert. Diese Unterstützung ist jedoch nicht standardmäßig aktiviert, wenn die IIS-Website eine oder beide der folgenden Arten von SSL/TLS-Bindungen verwendet:
- Servernamensanzeige anfordern
- Zentralisierten Zertifikatspeicher verwenden
In diesem Fall enthält die „Hello“-Antwort des Servers während des TLS-Handshakes standardmäßig keinen OCSP-Status „stapled“ (gestapelt). Dieses Verhalten verbessert die Leistung: Die Windows-Implementierung der OCSP-Stapelung wird auf Hunderte von Serverzertifikaten skaliert. SNI (Server Name Indication, Servernamensanzeige) und CCS (Central Certificate Store, zentraler Zertifikatspeicher) ermöglichen IIS jedoch die Skalierung auf Tausende von Websites mit potenziell Tausenden von Serverzertifikaten. Daher kann die Aktivierung der OCSP-Stapelung für CCS-Bindungen zu Leistungsproblemen führen.
Geltende Versionen: Alle Versionen ab Windows Server 2012 und Windows 8.
Registrierungspfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Fügen Sie den folgenden Schlüssel hinzu:
„EnableOcspStaplingForSni“=dword:00000001
Legen Sie zum Deaktivieren den DWORD-Wert auf „0“ fest:
„EnableOcspStaplingForSni“=dword:00000000
Hinweis
Die Aktivierung dieses Registrierungsschlüssels kann die Leistung möglicherweise beeinträchtigen.
Hashes
TLS/SSL-Hashalgorithmen sollten durch Konfigurieren der Reihenfolge von Verschlüsselungssammlungen gesteuert werden. Details dazu finden Sie unter Konfigurieren der Reihenfolge von TLS-Verschlüsselungssammlungen.
IssuerCacheSize
Dieser Eintrag steuert die Größe des Ausstellercache und wird mit der Ausstellerzuordnung verwendet. Der SChannel SSP versucht, alle Aussteller in der Zertifikatkette des Clients (und nicht nur den direkten Aussteller des Clientzertifikats) zuzuordnen. Wenn die Aussteller keinem Konto zugeordnet werden – was der Normalfall ist –, versucht der Server möglicherweise, denselben Ausstellernamen wiederholt (hunderte Male pro Sekunde) zuzuordnen.
Um dies zu verhindern, hat der Server einen negativen Cache. Wenn also ein Ausstellername keinem Konto zugeordnet ist, wird er dem Cache hinzugefügt. Dann versucht der SChannel SSP nicht, den Ausstellernamen erneut zuzuordnen, bis der Cacheeintrag abläuft. Dieser Registrierungseintrag gibt die Cachegröße an. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Der Standardwert lautet 100.
Geltende Versionen: Alle Versionen ab Windows Server 2008 und Windows Vista.
Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
IssuerCacheTime
Dieser Eintrag steuert das Zeitlimit für den Cache in Millisekunden. Der SChannel SSP versucht, alle Aussteller in der Zertifikatkette des Clients (und nicht nur den direkten Aussteller des Clientzertifikats) zuzuordnen. Wenn die Aussteller keinem Konto zugeordnet werden – was der Normalfall ist –, versucht der Server möglicherweise, denselben Ausstellernamen wiederholt (hunderte Male pro Sekunde) zuzuordnen.
Um dies zu verhindern, hat der Server einen negativen Cache. Wenn also ein Ausstellername keinem Konto zugeordnet ist, wird er dem Cache hinzugefügt. Dann versucht der SChannel SSP nicht, den Ausstellernamen erneut zuzuordnen, bis der Cacheeintrag abläuft. Dieser Cache wird aus Leistungsgründen eingerichtet, damit das System nicht laufend versucht, dieselben Aussteller zuzuordnen. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Der Standardwert beträgt 10 Minuten.
Geltende Versionen: Alle Versionen ab Windows Server 2008 und Windows Vista.
Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
KeyExchangeAlgorithm-Schlüsselgrößen
Diese unten aufgeführten Einträge sind in der Registrierung standardmäßig möglicherweise nicht vorhanden und müssen manuell erstellt werden. Die Verwendung von Schlüsselaustauschalgorithmen sollte durch Konfigurieren der Reihenfolge von Verschlüsselungssammlungen gesteuert werden.
Wurde in Windows 10, Version 1507, und Windows Server 2016 hinzugefügt.
Registrierungspfad: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman
Erstellen Sie einen Eintrag vom Typ ClientMinKeyBitLength, um einen unterstützten Minimalbereich der Diffie-Hellman-Schlüsselbitlänge für den TLS-Client anzugeben. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert auf die gewünschte Bitlänge. Wenn nicht konfiguriert, ist 1024 Bit das Minimum.
Erstellen Sie einen Eintrag vom Typ ClientMaxKeyBitLength, um einen unterstützten Maximalbereich der Diffie-Hellman-Schlüsselbitlänge für den TLS-Client anzugeben. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert auf die gewünschte Bitlänge.
Erstellen Sie einen Eintrag vom Typ ServerMinKeyBitLength, um die Diffie-Hellman-Schlüsselbitlänge für den TLS-Serverstandard anzugeben. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert auf die gewünschte Bitlänge. Wenn nicht konfiguriert, ist 2048 Bit der Standard.
Hinweis
Konfigurierte elliptische Kurven bestimmen die kryptografische Stärke des ECDHE-Schlüsselaustauschs. Weitere Informationen finden Sie unter Verwalten von Transport Layer Security (TLS).
Weitere Informationen zu Kryptografiealgorithmen der TLS/SSL-Verschlüsselungssammlung finden Sie unter:
- Verschlüsselungssammlungen in TLS/SSL (Schannel SSP)
- Demystifying SChannel (Entmystifizieren von Schannel) (Blog)
MaximumCacheSize
Dieser Eintrag steuert die maximale Anzahl von TLS-Sitzungen, die zwischengespeichert werden soll. Durch Festlegen von „MaximumCacheSize“ auf 0 wird der serverseitige Sitzungscache deaktiviert, um die Sitzungswiederaufnahme zu verhindern. Das Erhöhen von "MaximumCacheSize" über die Standardwerte hinaus bewirkt, dass "Lsass.exe" zusätzlichen Arbeitsspeicher beansprucht. Für jedes Element im Sitzungscache sind normalerweise 2 bis 4 KB Arbeitsspeicher erforderlich. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Der Standardwert ist 20.000 Elemente.
Geltende Versionen: Alle Versionen ab Windows Server 2008 und Windows Vista.
Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Nachrichten – Fragmentanalyse
Dieser Eintrag steuert die maximal zulässige Größe einer TLS-Handshakenachricht, die akzeptiert wird. Nachrichten, die die zulässige Größe überschreiten, werden nicht akzeptiert, und der TLS-Handshake schlägt fehl. Diese Einträge sind in der Registrierung standardmäßig nicht enthalten.
Wenn Sie den Wert auf 0x0 festlegen, werden fragmentierte Nachrichten nicht verarbeitet und führen zu einem Fehlschlagen des TLS-Handshakes. Dadurch sind TLS-Clients oder -Server auf dem aktuellen Computer nicht mit den TLS-RFCs kompatibel.
Die maximal zulässige Größe kann auf bis zu 2^16 Bytes erhöht werden. Es ist keine gute Idee, einem Client oder Server das Lesen und Speichern von großen Mengen nicht überprüfter Daten aus dem Netzwerk zu gestatten und so zusätzlichen Arbeitsspeicher für jeden Sicherheitskontext zu verbrauchen.
Wurde in Windows 7 und Windows Server 2008 R2 hinzugefügt: Ein Update, das es Internet Explorer unter Windows XP, Windows Vista oder Windows Server 2008 ermöglicht, fragmentierte TLS/SSL-Handshakenachrichten zu analysieren, ist verfügbar.
Registrierungspfad: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging
Erstellen Sie einen Eintrag vom Typ MessageLimitClient, um eine maximal zulässige Größe für fragmentierte TLS-Handshakenachrichten, die der TLS-Client akzeptiert, anzugeben. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert auf die gewünschte Bitlänge. Wenn der DWORD-Wert nicht konfiguriert wurde, lautet der Standardwert gleich 0x8000 Bytes.
Erstellen Sie einen Eintrag vom Typ MessageLimitServer, um eine maximal zulässige Größe für fragmentierte TLS-Handshakenachrichten anzugeben, die der TLS-Server bei einer Clientauthentifizierung akzeptiert. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert auf die gewünschte Bitlänge. Wenn der DWORD-Wert nicht konfiguriert wurde, lautet der Standardwert gleich 0x4000 Bytes.
Erstellen Sie einen Eintrag vom Typ MessageLimitServerClientAuth, um eine maximal zulässige Größe für fragmentierte TLS-Handshakenachrichten anzugeben, die der TLS-Server bei einer Clientauthentifizierung akzeptiert. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert auf die gewünschte Bitlänge. Wenn der DWORD-Wert nicht konfiguriert wurde, lautet der Standardwert gleich 0x8000 Bytes.
SendTrustedIssuerList
TLS-Server können beim Anfordern der Clientauthentifizierung eine Liste der Distinguished Names der zulässigen Zertifizierungsstellen senden. Dies kann TLS-Clients bei der Auswahl eines geeigneten TLS-Clientzertifikats helfen. SChannel-basierte TLS-Server senden diese Liste der vertrauenswürdigen Aussteller standardmäßig nicht, da sie die vom Server als vertrauenswürdig eingestuften Zertifizierungsstellen für passive Beobachter verfügbar macht und zudem die Menge der im Rahmen des TLS-Handshakes ausgetauschten Daten erhöht. Wenn Sie diesen Wert auf 1 festlegen, senden SChannel-basierte Server ihre Listen mit vertrauenswürdigen Ausstellern.
Wenn keine Liste vertrauenswürdiger Aussteller gesendet wird, kann dies Auswirkungen darauf haben, was der Client sendet, wenn von ihm ein Clientzertifikat angefordert wird. Wenn z. B. Internet Explorer eine Anforderung für die Clientauthentifizierung empfängt, zeigt der Browser nur Clientzertifikate an, die mit einer der Zertifizierungsstellen verkettet sind, die vom Server gesendet wird. Wenn der Server keine Liste gesendet hat, zeigt Internet Explorer alle Clientzertifikate, die auf dem Client installiert sind.
Dieses Verhalten ist möglicherweise wünschenswert. Wenn z. B. PKI-Umgebungen übergreifende Zertifikate enthalten, haben die Client- und Serverzertifikate nicht die gleiche Stammzertifizierungsstelle. Aus diesem Grund kann Internet Explorer kein Zertifikat wählen, das mit einer der Zertifizierungsstellen des Servers verkettet ist. TLS-Clients bieten möglicherweise jedes verfügbare Clientzertifikat an, wenn ein Server die Liste der vertrauenswürdigen Aussteller nicht sendet. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden.
Standardverhalten der Liste „Send Trusted Issuer“ (Vertrauenswürdigen Aussteller senden)
| Windows-Version | Standardverhalten |
|---|---|
| Windows Server 2012, Windows 8 und höher | false |
| Windows Server 2008 R2, Windows 7 und früher | TRUE |
Geltende Versionen: Alle Versionen ab Windows Server 2008 und Windows Vista.
Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
ServerCacheTime
Dieser Eintrag gibt die Lebensdauer von Server-TLS-Sitzungscacheelementen in Millisekunden an. Der Standardwert ist 10 Stunden. Der Wert 0 deaktiviert die TLS-Sitzungszwischenspeicherung auf dem Server und verhindert die Wiederaufnahme der Sitzung. Das Erhöhen von "ServerCacheTime" über die Standardwerte bewirkt, dass "Lsass.exe" zusätzlichen Arbeitsspeicher beansprucht. Für jedes Element im Sitzungscache sind normalerweise 2 bis 4 KB Arbeitsspeicher erforderlich. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden.
Geltende Versionen: Alle Versionen ab Windows Server 2008 und Windows Vista.
Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Standardzeit im Servercache: 10 Stunden
Einstellungen für die TLS-, DTLS- und SSL-Protokollversion
SChannel SSP implementiert Versionen der Protokolle TLS, DTLS und SSL. Verschiedene Windows-Versionen unterstützen verschiedene Protokollversionen. Die systemweit verfügbaren (D)TLS- und SSL-Versionen können durch SSPI-Aufrufer eingeschränkt (aber nicht erweitert) werden, die im AcquireCredentialsHandle-Aufruf die Struktur SCH_CREDENTIALS angeben. Es wird empfohlen, dass SSPI-Aufrufer die Systemstandardeinstellungen verwenden, statt Einschränkungen bei der Protokollversion aufzuerlegen.
Eine unterstützte (D)TLS- oder SSL-Protokollversion kann es in einem der folgenden Status geben:
- Aktiviert: Wenn der SSPI-Aufrufer diese Protokollversion nicht explizit mithilfe der SCH_CREDENTIALS-Struktur deaktiviert, kann SChannel SSP sie mit einem unterstützenden Peer aushandeln.
- Deaktiviert: SChannel SSP handelt diese Protokollversion – unabhängig von den Einstellungen, die der SSPI-Aufrufer möglicherweise angibt, – nicht aus.
Diese Registrierungswerte werden separat für die Protokoll-Client- und -Serverrollen unter den benannten Registrierungsunterschlüsseln im folgenden Format konfiguriert:
<SSL/TLS/DTLS><Hauptversionsnummer>.<Nebenversionsnummer><Client\Server>
Diese versionsspezifischen Unterschlüssel können unter dem folgenden Registrierungspfad erstellt werden:
HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Hier sind beispielsweise einige gültige Registrierungspfade mit versionsspezifischen Unterschlüsseln:
HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client
HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\DTLS 1.2\Client
Wenn Sie einen Systemstandard außer Kraft setzen und eine unterstützte (D)TLS- oder SSL-Protokollversion auf den Status Aktiviert festlegen möchten, erstellen Sie unter dem entsprechenden versionsspezifischen Unterschlüssel den DWORD-Registrierungswert mit dem Eintragswert 1.
Das folgende Beispiel zeigt, dass der TLS 1.0-Client auf den Status Aktiviert festgelegt wurde:
Wenn Sie einen Systemstandard außer Kraft setzen und eine unterstützte (D)TLS- oder SSL-Protokollversion auf den Status Deaktiviert festlegen möchten, ändern Sie unter dem entsprechenden versionsspezifischen Unterschlüssel den DWORD-Registrierungswert von „Aktiviert“ in 0.
Das folgende Beispiel zeigt, dass DTLS 1.2 in der Registrierung deaktiviert ist:
Das Ändern einer (D)TLS- oder SSL-Protokollversion in den Status Deaktiviert kann dazu führen, dass AcquireCredentialsHandle-Aufrufe aufgrund von fehlenden Protokollversionen fehlschlagen, die systemweit aktiviert und gleichzeitig von bestimmten SSPI-Aufrufern zugelassen wurden. Darüber hinaus kann die Reduzierung der (D)TLS- und SSL-Versionen mit dem Status Aktiviert die Interoperabilität mit Remotepeers beeinträchtigen.
Sobald die Einstellungen der (D)TLS- oder SSL-Protokollversion geändert wurden, werden sie für Verbindungen wirksam, die mithilfe von Anmeldeinformationshandles hergestellt werden, die wiederum durch nachfolgende AcquireCredentialsHandle-Aufrufe geöffnet werden. (D)TLS- und SSL-Client- und Serveranwendungen und -dienste tendieren aus Leistungsgründen dazu, Anmeldeinformationshandles für mehrere Verbindungen wiederzuverwenden. Damit diese Anwendungen ihre Anmeldeinformationshandles erneut abrufen, ist möglicherweise ein Neustart der Anwendung oder des Diensts erforderlich.
Diese Registrierungseinstellungen gelten nur für SChannel SSP und wirken sich nicht auf (D)-TLS- und SSL-Implementierungen von Drittanbietern aus, die auf dem System möglicherweise installiert werden.