Registrierungseinstellungen für Transport Layer Security (TLS)

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 10 und früheren Versionen wie erwähnt.

In diesem Artikel werden die unterstützten Registrierungseinstellungsinformationen für die Windows Implementierung des Transport Layer Security (TLS)-Protokolls und das Secure Sockets Layer (SSL)-Protokoll über den Schannel Security Support Provider (SSP) erläutert. Die Registrierungsunterschlüssel und Einträge, die in diesem Thema behandelt werden, helfen Ihnen bei der Verwaltung und Problembehandlung des Schannel-SSP, insbesondere der TLS- und SSL-Protokolle.

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. Wenn möglich, verwenden Sie Gruppenrichtlinie oder andere Windows Tools wie die Microsoft Management Console (MMC). Wenn Sie die Registrierung bearbeiten müssen, gehen Sie äußerst umsichtig vor.

CertificateMappingMethods

Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Der Standardwert ist, dass alle vier unten aufgeführten Methoden für die Clientzertifikatzuordnung unterstützt werden.

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 standardmäßig die folgenden vier Methoden für die Clientzertifikatzuordnung, die nach Priorität aufgeführt sind:

  1. Kerberos-S4U-Clientzertifikatzuordnung (Service-for-User)
  2. Zuordnung von Benutzerprinzipalnamen
  3. 1:1-Zuordnung (auch bekannt als Antragsteller/Aussteller- Zuordnung)
  4. n:1-Zuordnung

Anwendbare Versionen: Wie in der Liste "Gilt für" am Anfang dieses Themas angegeben.

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Ciphers

TLS/SSL-Verschlüsselungen sollten durch Konfigurieren der Cipher-Suite-Reihenfolge gesteuert werden. Ausführliche Informationen finden Sie unter Konfigurieren der TLS-Cipher Suite-Bestellung.

Informationen zur Standard-Verschlüsselungssuitenreihenfolge, die von der Schannel-SSP verwendet werden, finden Sie unter Cipher Suites in TLS/SSL (Schannel SSP).

CipherSuites

Die Konfiguration von TLS/SSL-Verschlüsselungssuiten sollte mithilfe von Gruppenrichtlinien, MDM oder PowerShell erfolgen, siehe Konfigurieren der TLS-Cipher Suite-Bestellung für Details.

Informationen zur Standard-Verschlüsselungssuitenreihenfolge, die von der Schannel-SSP verwendet werden, finden Sie unter Cipher Suites in TLS/SSL (Schannel SSP).

ClientCacheTime

Dieser Eintrag steuert die Dauer in Millisekunden, die das Betriebssystem benötigt, um Einträge im clientseitigen Cache ablaufen zu lassen. Der Wert 0 deaktiviert das Zwischenspeichern sicherer Verbindungen. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden.

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.

Ab Windows Server 2008 und Windows Vista beträgt die Standardclientcachezeit 10 Stunden.

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

EnableOcspStaplingForSni

Online-Zertifikatstatusprotokoll (OCSP) ermöglicht die Heftung eines Webservers, z. B. Internetinformationsdienste (IIS), den aktuellen Sperrstatus eines Serverzertifikats bereitzustellen, wenn das Serverzertifikat während des TLS-Handshakes an einen Client gesendet wird. Dieses Feature reduziert die Auslastung auf OCSP-Servern, da 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. Dies würde eine hohe Last auf diesem OCSP-Server generieren.

Zusätzlich zu IIS können Webdienste über http.sys auch von dieser Einstellung profitieren, einschließlich Active Directory-Verbunddienste (AD FS) (AD FS) und Web Anwendungsproxy (WAP).

Standardmäßig ist OCSP-Unterstützung für IIS-Websites aktiviert, die über eine einfache sichere (SSL/TLS)-Bindung verfügen. Diese Unterstützung ist jedoch standardmäßig nicht aktiviert, wenn die IIS-Website entweder oder beide der folgenden Arten von SSL/TLS-Bindungen verwendet:

  • Servernamensanzeige anfordern
  • Zentralisierten Zertifikatspeicher verwenden

In diesem Fall enthält die Server hello-Antwort während der TLS-Handshake standardmäßig keinen OCSP-Klammerstatus. Dieses Verhalten verbessert die Leistung: Die Windows OCSP-Staplierungsimplementierung skaliert auf Hunderte von Serverzertifikaten. Da SNI und CCS IIS ermöglichen, auf Tausende von Websites zu skalieren, die potenziell Tausende von Serverzertifikaten haben, kann das Festlegen dieses Verhaltens standardmäßig zu Leistungsproblemen führen.

Anwendbare Versionen: Alle Versionen beginnend mit 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

Um zu deaktivieren, legen Sie den DWORD-Wert auf 0 fest:

"EnableOcspStaplingForSni"=dword:0000000000

Hinweis

Das Aktivieren dieses Registrierungsschlüssels hat einen potenziellen Leistungseffekt.

FIPSAlgorithmPolicy

Dieser Eintrag steuert die FIPS-Einhaltung (Federal Information Processing Standard). Die Standardeinstellung ist 0.

Anwendbare Versionen: Alle Versionen beginnend mit Windows Server 2012 und Windows 8.

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\LSA

Windows Server FIPS-Verschlüsselungssuiten: Siehe Unterstützte Cipher Suites und Protokolle im Schannel SSP.

Hashes

TLS/SSL-Hashalgorithmen sollten durch Konfigurieren der Cipher-Suite-Reihenfolge gesteuert werden. Weitere Informationen finden Sie unter Konfigurieren der TLS-Cipher Suite-Bestellung .

IssuerCacheSize

Dieser Eintrag steuert die Größe des Ausstellercaches und wird mit der Ausstellerzuordnung verwendet. Der Schannel-SSP versucht, alle Aussteller in der Zertifikatkette des Clients zuzuordnen, nicht nur der direkte Aussteller des Clientzertifikats. Wenn die Aussteller keine Zuordnung zu einem Konto haben, was der typische Fall ist, versucht der Server möglicherweise, denselben Ausstellernamen wiederholt, Hunderte von Zeiten pro Sekunde zuzuordnen.

Um dies zu verhindern, hat der Server einen negativen Cache. Wenn also ein Ausstellernamen keinem Konto zugeordnet ist, wird er dem Cache hinzugefügt, woraufhin Schannel SSP nicht versucht, 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 ist 100.

Anwendbare Versionen: Alle Versionen, die mit Windows Server 2008 und Windows Vista beginnen.

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 zuzuordnen, nicht nur der direkte Aussteller des Clientzertifikats. In dem Fall, in dem die Aussteller keine Zuordnung zu einem Konto haben, was der typische Fall ist, kann der Server versuchen, denselben Ausstellernamen wiederholt zuzuordnen, Hunderte von Zeiten pro Sekunde.

Um dies zu verhindern, hat der Server einen negativen Cache, sodass ein Ausstellername nicht einem Konto zugeordnet ist, wird er dem Cache hinzugefügt und der Schannel-SSP versucht 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.

Anwendbare Versionen: Alle Versionen, die mit Windows Server 2008 und Windows Vista beginnen.

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

KeyExchangeAlgorithm – Client RSA-Schlüsselgrößen

Dieser Eintrag steuert die Client-RSA-Schlüsselgrößen.

Die Verwendung von Schlüsselaustauschalgorithmen sollte durch Konfigurieren der Verschlüsselungssuitereihenfolge gesteuert werden.

In Windows 10, Version 1507 und Windows Server 2016 hinzugefügt.

Registrierungspfad: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS

Um einen mindest unterstützten Bereich von RSA-Schlüsselbitlänge für den TLS-Client anzugeben, erstellen Sie einen ClientMinKeyBitLength-Eintrag . Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert in die gewünschte Bitlänge. Wenn dies nicht konfiguriert ist, sind 1024-Bits das Minimum.

Um einen maximalen unterstützten Bereich von RSA-Schlüsselbitlänge für den TLS-Client anzugeben, erstellen Sie einen ClientMaxKeyBitLength-Eintrag . Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert in die gewünschte Bitlänge. Wenn sie nicht konfiguriert ist, wird kein Maximum erzwungen.

KeyExchangeAlgorithm – Diffie-Hellman Schlüsselgrößen

Dieser Eintrag steuert die Diffie-Hellman Schlüsselgrößen.

Die Verwendung von Schlüsselaustauschalgorithmen sollte durch konfigurieren der Verschlüsselungssuitereihenfolge gesteuert werden.

In Windows 10, Version 1507 und Windows Server 2016 hinzugefügt.

Registrierungspfad: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman

Um einen minimalen unterstützten Bereich von Diffie-Helman Schlüsselbitlänge für den TLS-Client anzugeben, erstellen Sie einen ClientMinKeyBitLength-Eintrag . Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert in die gewünschte Bitlänge. Wenn dies nicht konfiguriert ist, sind 1024-Bits das Minimum.

Um einen maximalen unterstützten Bereich von Diffie-Helman Schlüsselbitlänge für den TLS-Client anzugeben, erstellen Sie einen ClientMaxKeyBitLength-Eintrag . Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert in die gewünschte Bitlänge. Wenn sie nicht konfiguriert ist, wird kein Maximum erzwungen.

Um die Diffie-Helman Schlüsselbitlänge für den TLS-Serverstandard anzugeben, erstellen Sie einen ServerMinKeyBitLength-Eintrag . Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert in die gewünschte Bitlänge. Wenn dies nicht konfiguriert ist, sind 2048-Bits die Standardeinstellung.

MaximumCacheSize

Dieser Eintrag steuert die maximale Anzahl von Elementen im Cache. Durch Festlegen von "MaximumCacheSize" auf 0 werden der serverseitige Sitzungscache deaktiviert und erneute Verbindungen verhindert. Das Erhöhen von "MaximumCacheSize" über die Standardwerte hinaus bewirkt, dass "Lsass.exe" zusätzlichen Arbeitsspeicher beansprucht. Jedes Element im Sitzungscache belegt in der Regel 2 bis 4 KB Arbeitsspeicher. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Der Standardwert ist 20.000 Elemente.

Anwendbare Versionen: Alle Versionen, die mit Windows Server 2008 und Windows Vista beginnen.

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Messaging – Fragmentanalyse

Dieser Eintrag steuert die maximale zulässige Größe von fragmentierten TLS-Handshake-Nachrichten, die akzeptiert werden. Nachrichten, die größer als die zulässige Größe sind, werden nicht akzeptiert, und die TLS-Handshake schlägt fehl. Diese Einträge sind in der Registrierung standardmäßig nicht vorhanden.

Wenn Sie den Wert auf 0x0 festlegen, werden fragmentierte Nachrichten nicht verarbeitet und führen dazu, dass der TLS-Handshake fehlschlägt. Dadurch werden TLS-Clients oder -Server auf dem aktuellen Computer nicht kompatibel mit den TLS RFCs.

Die maximale zulässige Größe kann bis zu 2^24-1 Bytes erhöht werden. Ein Client oder Server kann große Mengen von nicht überprüften Daten aus dem Netzwerk lesen und speichern, ist keine gute Idee und nutzt zusätzlichen Arbeitsspeicher für jeden Sicherheitskontext.

In Windows 7 und Windows Server 2008 R2 hinzugefügt: Ein Update, das Internet Explorer in Windows XP, in Windows Vista oder in Windows Server 2008 zum Analysieren fragmentierter TLS/SSL-Handshake-Nachrichten ermöglicht, ist verfügbar.

Registrierungspfad: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging

Um eine maximale zulässige Größe von fragmentierten TLS-Handshake-Nachrichten anzugeben, die der TLS-Client akzeptiert, erstellen Sie einen MessageLimitClient-Eintrag . Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert in die gewünschte Bitlänge. Wenn dies nicht konfiguriert ist, wird der Standardwert 0x8000 Bytes angezeigt.

Um eine maximale zulässige Größe von fragmentierten TLS-Handshake-Nachrichten anzugeben, die der TLS-Server akzeptiert, wenn keine Clientauthentifizierung vorhanden ist, erstellen Sie einen MessageLimitServer-Eintrag . Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert in die gewünschte Bitlänge. Wenn dies nicht konfiguriert ist, wird der Standardwert 0x4000 Bytes angezeigt.

Um eine maximale zulässige Größe von fragmentierten TLS-Handshake-Nachrichten anzugeben, die der TLS-Server akzeptiert, wenn die Clientauthentifizierung vorhanden ist, erstellen Sie einen MessageLimitServerClientAuth-Eintrag . Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert in die gewünschte Bitlänge. Wenn dies nicht konfiguriert ist, wird der Standardwert 0x8000 Bytes angezeigt.

SendTrustedIssuerList

Dieser Eintrag steuert das Kennzeichen, das verwendet wird, wenn die Liste der vertrauenswürdigen Aussteller gesendet wird. Bei Servern, die für die Clientauthentifizierung Hunderten von Zertifizierungsstellen vertrauen, gibt es zu viele Aussteller, die der Server nicht alle an den Clientcomputer senden kann, wenn die Clientauthentifizierung angefordert wird. In diesem Fall kann dieser Registrierungsschlüssel festgelegt werden. Anstatt eine Teilliste zu senden, sendet der Schannel SSP keine Liste an den Client.

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 zertifikateübergreifende Zertifikate enthalten, verfügen die Client- und Serverzertifikate nicht über dieselbe Stammzertifizierungsstelle; Daher kann Internet Explorer kein Zertifikat auswählen, das bis zu einem der CAs des Servers verkettet wird. Indem Sie konfigurieren, dass der Server keine Liste der vertrauenswürdigen Aussteller sendet, sendet Internet Explorer alle seine Zertifikate.

Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden.

Standardverhalten der vertrauenswürdigen Ausstellerliste

Windows-Version Standardverhalten
Windows Server 2012 und Windows 8 und höher FALSE
Windows Server 2008 R2 und Windows 7 und früher TRUE

Anwendbare Versionen: Alle Versionen, die mit Windows Server 2008 und Windows Vista beginnen.

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

ServerCacheTime

Dieser Eintrag steuert die Dauer, die das Betriebssystem in Millisekunden benötigt, um Einträge im serverseitigen Cache ablaufen zu lassen. Durch Festlegen auf 0 werden der serverseitige Sitzungscache deaktiviert und erneute Verbindungen verhindert. Das Erhöhen von "ServerCacheTime" über die Standardwerte bewirkt, dass "Lsass.exe" zusätzlichen Arbeitsspeicher beansprucht. Jedes Element im Sitzungscache belegt in der Regel 2 bis 4 KB Arbeitsspeicher. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden.

Anwendbare Versionen: Alle Versionen, die mit Windows Server 2008 und Windows Vista beginnen.

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Standardzeit im Servercache: 10 Stunden

TLS-, DTLS- und SSL-Protokollversionseinstellungen

Schannel SSP implementiert Versionen der TLS-, DTLS- und SSL-Protokolle. Unterschiedliche Windows Versionen unterstützen unterschiedliche Protokollversionen. Der Satz von (D)TLS- und SSL-Versionen, die systemweit verfügbar sind, können durch SSPI-Aufrufer eingeschränkt (aber nicht erweitert) werden, die entweder SCH_CREDENTIALS oder SCHANNEL_CRED Struktur im AcquireCredentialsHandle-Aufruf angeben. Es wird empfohlen, dass SSPI-Aufrufer die Systemstandardwerte verwenden, anstatt Protokollversionseinschränkungen zu erzwingen.

Eine unterstützte (D)TLS- oder SSL-Protokollversion kann in einem der folgenden Zustände vorhanden sein:

  • Aktiviert: Es sei denn, der SSPI-Aufrufer deaktiviert diese Protokollversion explizit mithilfe der SCH_CREDENTIALS-Struktur , schannel SSP kann diese Protokollversion mit einem unterstützenden Peer aushandeln.
  • Standardmäßig deaktiviert: Es sei denn, der SSPI-Aufrufer fordert diese Protokollversion explizit mit der veralteten SCHANNEL_CRED-Struktur an, Schannel SSP führt diese Protokollversion nicht aus.
  • Deaktiviert: Schannel SSP führt diese Protokollversion nicht aus, unabhängig von den Einstellungen, die der SSPI-Aufrufer angeben kann.

Der Systemadministrator kann die Standardeinstellungen (D)TLS und SSL-Protokollversion überschreiben, indem DWORD-Registrierungswerte "Enabled" und "DisabledByDefault" erstellt werden. Diese Registrierungswerte werden separat für die Protokollclient- und Serverrollen unter den Registrierungsunterschlüsseln mit dem folgenden Format konfiguriert:

<SSL/TLS/DTLSmajor>< Versionsnummer>.< NebenversionsnummerClient><\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\Protocol\SSL 3.0\Client

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocol\TLS 1.2\Server

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocol\DTLS 1.2\Client

Um einen Systemstandard außer Kraft zu setzen und eine unterstützte (D)TLS- oder SSL-Protokollversion auf den Aktivierten Zustand festzulegen, erstellen Sie einen DWORD-Registrierungswert namens "Enabled" mit einem Wert ohne Null und einen DWORD-Registrierungswert namens "DisabledByDefault" mit einem Wert von null unter dem entsprechenden versionsspezifischen Unterschlüssel.

Im folgenden Beispiel wird der TLS 1.0-Client auf den aktivierten Zustand festgelegt:

TLS 1.0 client enabled

Um einen Systemstandard außer Kraft zu setzen und eine unterstützte (D)TLS- oder SSL-Protokollversion auf den Standardzustand "Deaktiviert " festzulegen, erstellen Sie DWORD-Registrierungswerte namens "Enabled" und "DisabledByDefault" mit einem nicht null wert unter dem entsprechenden versionspezifischen Unterschlüssel. Im folgenden Beispiel wird der TLS 1.0-Server auf den Standardzustand "Deaktiviert " festgelegt:

TLS 1.0 server disabled by default

Um einen Systemstandard außer Kraft zu setzen und eine unterstützte (D)TLS- oder SSL-Protokollversion auf den Status "Deaktiviert " festzulegen, erstellen Sie einen DWORD-Registrierungswert namens "Enabled", mit einem Wert von Null, unter dem entsprechenden versionspezifischen Unterschlüssel.

Im folgenden Beispiel wird DTLS 1.2 in der Registrierung deaktiviert:

DTLS 1.2 disabled

Das Wechseln einer (D)TLS- oder SSL-Protokollversion zu "Deaktiviert" oder "Deaktiviert" kann dazu führen, dass AcquireCredentialsHandle-Aufrufe aufgrund der fehlenden Protokollversionen systemweit und gleichzeitig von bestimmten SSPI-Anrufern zulässig sind. Darüber hinaus kann die Verringerung der Gruppe von aktivierten (D)TLS- und SSL-Versionen die Interoperabilität mit Remote-Peers unterbrechen.

Nachdem die (D)TLS- oder SSL-Protokollversionseinstellungen geändert wurden, wirken sie sich auf Verbindungen aus, die mithilfe von Anmeldeinformationshandle-Aufrufen geöffnet wurden. (D) TLS- und SSL-Client- und Serveranwendungen und -Dienste neigen dazu, Anmeldeinformationen für mehrere Verbindungen aus Leistungsgründen wiederzuverwenden. Um diese Anwendungen zum Erneuten Abrufen ihrer Anmeldeinformationen zu erhalten, kann ein Anwendungs- oder Dienststart erforderlich sein.

Bitte beachten Sie, dass diese Registrierungseinstellungen nur für Schannel SSP gelten und keine Drittanbieter-TLS- und SSL-Implementierungen betreffen, die möglicherweise auf dem System installiert werden können.