ChangeIntelIT change radar
Public mode

No access to your tenant or devices. Every item links to its source. What this means

Some sources or documents need attention: 258/260 feeds/APIs · 416/439 docs · checked 22:55 UTC Customize Public modeDiscuss ChangeIntel on Discord

TLS registry settings

This page's changes and edits · All guidance changes

Microsoft's edit ·

Light refresh

Microsoft's commit message in MicrosoftDocs/windowsserverdocs · commit 24dc636 · +37 −37 lines · also on GitHub

⋯ 1 unchanged line
22 title: Transport Layer Security (TLS) registry settings
33 description: Learn about supported registry setting information for the Windows implementation of the Transport Layer Security (TLS) protocol.
44 ms.topic: article
5 −ms.date: 07/16/2024
5 +ms.date: 08/19/2024
66 ---
77
88 # Transport Layer Security (TLS) registry settings
99
1010 > Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 11, Windows 10, and earlier versions as noted
1111
12 −This article explains the supported registry setting information for the Windows implementation of the Transport Layer Security (TLS) protocol and the Secure Sockets Layer (SSL) protocol through the SChannel Security Support Provider (SSP). The registry subkeys and entries covered in this article help you administer and troubleshoot the SChannel SSP, specifically the TLS, and SSL protocols.
12 +This article explains the supported registry setting information for the Windows implementation of the Transport Layer Security (TLS) protocol and the Secure Sockets Layer (SSL) protocol through the SChannel Security Support Provider (SSP). The registry subkeys and entries covered in this article help you administer and troubleshoot the SChannel SSP, specifically the TLS and SSL protocols.
1313
1414 > [!CAUTION]
1515 > This information is provided as a reference to use when you are troubleshooting or verifying that the required settings are applied. We recommend that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the Registry Editor or by the Windows operating system before they are applied. As a result, incorrect values can be stored, and this can result in unrecoverable errors in the system. When possible, instead of editing the registry directly, use Group Policy or other Windows tools such as the Microsoft Management Console (MMC). If you must edit the registry, use extreme caution.
1616
1717 ## SChannel logging
1818
19 −There are eight logging levels for SChannel events saved to the system event log and viewable using Event Viewer. This registry path is stored in **HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL** under the **EventLogging** key with a DWORD value set to **1**.
19 +There are eight logging levels for SChannel events saved to the system event log and viewable using Event Viewer. This registry path is stored in **HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL** under the **EventLogging** key with a DWORD value set to *1*.
2020
2121 | Decimal or Hex | SChannel logging events |
2222 |---|---|
⋯ 20 unchanged lines
4343 - A single certificate is mapped to a single user account (one-to-one mapping).
4444 - Multiple certificates are mapped to one user account (many-to-one mapping).
4545
46 −The SChannel provider uses four (4) certificate mapping methods:
46 +The SChannel provider uses four certificate mapping methods:
4747
48 −1. Kerberos service-for-user (S4U) mapping (**enabled by default**)
48 +1. Kerberos service-for-user (S4U) mapping (enabled by default)
4949 1. User principal name mapping
5050 1. One-to-one mapping (also known as subject/issuer mapping)
5151 1. Many-to-one mapping
⋯ 8 unchanged lines
6060 |S4U2Self|0x000000008|Yes|
6161 |S4U2Self Explicit|0x000000010|Yes|
6262
63 −Applicable versions: As designated in the **Applies To** list at the beginning of this article.
63 +Applicable versions: As designated in the **Applies to** list at the beginning of this article.
6464
6565 ## Ciphers
6666
⋯ 3 unchanged lines
7070
7171 ## CipherSuites
7272
73 −Configuring TLS/SSL cipher suites should be done using group policy, MDM or PowerShell, see [Configuring TLS Cipher Suite Order](manage-tls.md#configuring-tls-cipher-suite-order) for details.
73 +Configuring TLS/SSL cipher suites should be done using group policy, MDM, or PowerShell, see [Configuring TLS Cipher Suite Order](manage-tls.md#configuring-tls-cipher-suite-order) for details.
7474
7575 For information about default cipher suite orders that are used by the SChannel SSP, see [Cipher Suites in TLS/SSL (SChannel SSP)](/windows/win32/secauthn/cipher-suites-in-schannel).
7676
7777 ## ClientCacheTime
7878
79 −This entry specifies client TLS session cache item lifetime in milliseconds. Beginning with Windows Server 2008 and Windows Vista the default is 10 hours. A value of **0** turns off TLS session caching on the client.
79 +This entry specifies client TLS session cache item lifetime in milliseconds. Beginning with Windows Server 2008 and Windows Vista the default is 10 hours. A value of *0* turns off TLS session caching on the client.
8080
81 −The first time a client connects to a server through the SChannel SSP, a full TLS/SSL handshake is performed. When complete, the master secret, cipher suite, and certificates are stored in the session cache on the respective client and server.
81 +The first time a client connects to a server through the SChannel SSP, a full TLS/SSL handshake is performed. When complete, the main secret, cipher suite, and certificates are stored in the session cache on the respective client and server.
8282
8383 Registry path: **HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL**
8484
⋯ 8 unchanged lines
9393 - Require Server Name Indication
9494 - Use Centralized Certificate Store
9595
96 −In this case, the server hello response during the TLS handshake won't include an OCSP stapled status by default. This behavior improves performance: The Windows OCSP stapling implementation scales to hundreds of server certificates. However, Server Name Indication (SNI) and Central Certificate Store (CCS) enable IIS to scale to thousands of websites that potentially have thousands of server certificates, therefore enabling OCSP stapling for CCS bindings may cause performance issues.
96 +In this case, the server hello response during the TLS handshake won't include an OCSP stapled status by default. This behavior improves performance: The Windows OCSP stapling implementation scales to hundreds of server certificates. However, Server Name Indication (SNI) and Central Certificate Store (CCS) enable IIS to scale to thousands of websites that potentially have thousands of server certificates, therefore enabling OCSP stapling for CCS bindings might cause performance issues.
9797
9898 Applicable versions: All versions beginning with Windows Server 2012 and Windows 8.
9999
⋯ 1 unchanged line
101101
102102 Add the following key:
103103
104 −"EnableOcspStaplingForSni"=dword:00000001
104 +`"EnableOcspStaplingForSni"=dword:00000001`
105105
106106 To disable, set the DWORD value to 0:
107107
108 −"EnableOcspStaplingForSni"=dword:00000000
108 +`"EnableOcspStaplingForSni"=dword:00000000`
109109
110110 > [!NOTE]
111111 > Enabling this registry key has potential performance impact.
⋯ 6 unchanged lines
118118
119119 This entry controls the size of the issuer cache, and it's used with issuer mapping. The SChannel SSP attempts to map all of the issuers in the client's certificate chain, not just the direct issuer of the client certificate. When the issuers don't map to an account, which is the typical case, the server might attempt to map the same issuer name repeatedly, hundreds of times per second.
120120
121 −To prevent this, the server has a negative cache, so if an issuer name doesn't map to an account, it's added to the cache and the SChannel SSP won't attempt to map the issuer name again until the cache entry expires. This registry entry specifies the cache size. This entry does **not** exist in the registry by default. The default value is **100**.
121 +To prevent this, the server has a negative cache, so if an issuer name doesn't map to an account, it's added to the cache and the SChannel SSP won't attempt to map the issuer name again until the cache entry expires. This registry entry specifies the cache size. This entry does *not* exist in the registry by default. The default value is *100*.
122122
123123 Applicable versions: All versions beginning with Windows Server 2008 and Windows Vista.
124124
⋯ 11 unchanged lines
136136
137137 ## KeyExchangeAlgorithm key sizes
138138
139 −These following entries may not exist in the registry by default and must be manually created. Use of key exchange algorithms should be controlled by configuring the cipher suite order. To learn more about TLS/SSL cipher suite cryptographic algorithms, see [Cipher Suites in TLS/SSL (SChannel SSP)](/windows/win32/secauthn/cipher-suites-in-schannel).
139 +These following entries might not exist in the registry by default and must be manually created. Use of key exchange algorithms should be controlled by configuring the cipher suite order. To learn more about TLS/SSL cipher suite cryptographic algorithms, see [Cipher Suites in TLS/SSL (SChannel SSP)](/windows/win32/secauthn/cipher-suites-in-schannel).
140140
141141 # [Diffie-Hellman](#tab/diffie-hellman)
142142
143 −Added in Windows 10, version 1507 and Windows Server 2016.
143 +Added in Windows 10, version 1507, and Windows Server 2016.
144144
145145 Registry path: **HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman**
146146
147 −To specify a minimum supported range of Diffie-Hellman key bit length for the TLS client, create a **ClientMinKeyBitLength** entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, 1024 bits is the minimum.
147 +To specify a minimum supported range of Diffie-Hellman key bit length for the TLS client, create a *ClientMinKeyBitLength* entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, 1024 bits is the minimum.
148148
149 −To specify a maximum supported range of Diffie-Hellman key bit length for the TLS client, create a **ClientMaxKeyBitLength** entry. After you've created the entry, change the DWORD value to the desired bit length.
149 +To specify a maximum supported range of Diffie-Hellman key bit length for the TLS client, create a *ClientMaxKeyBitLength* entry. After you've created the entry, change the DWORD value to the desired bit length.
150150
151 −To specify the Diffie-Hellman key bit length for the TLS server default, create a **ServerMinKeyBitLength** entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, 2048 bits is the default.
151 +To specify the Diffie-Hellman key bit length for the TLS server default, create a *ServerMinKeyBitLength* entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, 2048 bits is the default.
152152
153153 # [RSA](#tab/rsa)
154154
155 −Added in Windows 10, version 1507 and Windows Server 2016.
155 +Added in Windows 10, version 1507, and Windows Server 2016.
156156
157157 Registry path: **HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS**
158158
159 −To specify a minimum supported range of RSA key bit length for the TLS client, create a **ClientMinKeyBitLength** entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, 1024 bits is the minimum.
159 +To specify a minimum supported range of RSA key bit length for the TLS client, create a *ClientMinKeyBitLength* entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, 1024 bits is the minimum.
160160
161 −To specify a maximum supported range of RSA key bit length for the TLS client, create a **ClientMaxKeyBitLength** entry. After you've created the entry, change the DWORD value to the desired bit length. On the server-side, the strength of the RSA key exchange is controlled by the specified server certificate.
161 +To specify a maximum supported range of RSA key bit length for the TLS client, create a *ClientMaxKeyBitLength* entry. After you've created the entry, change the DWORD value to the desired bit length. On the server-side, the strength of the RSA key exchange is controlled by the specified server certificate.
162162
163163 ---
164164
⋯ 2 unchanged lines
167167
168168 ## MaximumCacheSize
169169
170 −This entry controls the maximum number of TLS sessions to cache. Setting MaximumCacheSize to **0** disables the
170 +This entry controls the maximum number of TLS sessions to cache. Setting MaximumCacheSize to *0* disables the
171171 server-side session cache to prevent session resumption. Increasing MaximumCacheSize above the
172172 default values causes Lsass.exe to consume additional memory. Each session-cache element typically
173173 requires 2 KB to 4 KB of memory. This entry doesn't exist in the registry by default. The default
⋯ 5 unchanged lines
179179
180180 ## Messaging – fragment parsing
181181
182 −This entry controls the maximum allowed size of a TLS handshake message that's accepted. Messages larger than the allowed size isn't accepted and the TLS handshake fails. These entries don't exist in the registry by default.
182 +This entry controls the maximum allowed size of a TLS handshake message that's accepted. Messages larger than the allowed size aren't accepted and the TLS handshake fails. These entries don't exist in the registry by default.
183183
184 −When you set the value to **0x0**, fragmented messages aren't processed and causes the TLS handshake to fail. This makes TLS clients or servers on the current machine noncompliant with the TLS RFCs.
184 +When you set the value to *0x0*, fragmented messages aren't processed and causes the TLS handshake to fail. This makes TLS clients or servers on the current machine noncompliant with the TLS RFCs.
185185
186186 The maximum allowed size can be increased up to 2^16 bytes. Allowing a client or server to read and store large amounts of unverified data from the network isn't a good idea and consumes additional memory for each security context.
187187
⋯ 1 unchanged line
189189
190190 Registry path: **HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging**
191191
192 −To specify a maximum allowed size of fragmented TLS handshake messages that the TLS client accepts, create a **MessageLimitClient** entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, the default value is **0x8000** bytes.
192 +To specify a maximum allowed size of fragmented TLS handshake messages that the TLS client accepts, create a *MessageLimitClient* entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, the default value is *0x8000* bytes.
193193
194 −To specify a maximum allowed size of fragmented TLS handshake messages that the TLS server accepts when there's no client authentication, create a **MessageLimitServer** entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, the default value is **0x4000** bytes.
194 +To specify a maximum allowed size of fragmented TLS handshake messages that the TLS server accepts when there's no client authentication, create a *MessageLimitServer* entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, the default value is *0x4000* bytes.
195195
196 −To specify a maximum allowed size of fragmented TLS handshake messages that the TLS server accepts when there's client authentication, create a **MessageLimitServerClientAuth** entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, the default value is **0x8000** bytes.
196 +To specify a maximum allowed size of fragmented TLS handshake messages that the TLS server accepts when there's client authentication, create a *MessageLimitServerClientAuth* entry. After you've created the entry, change the DWORD value to the desired bit length. If not configured, the default value is *0x8000* bytes.
197197
198198 ## SendTrustedIssuerList
199199
200 −TLS servers may send a list of the distinguished names of acceptable certificate authorities when requesting client authentication. This may help TLS clients select an appropriate TLS client certificate. SChannel-based TLS servers don't send this trusted issuer list by default because it exposes the certificate authorities trusted by the server to passive observers and also increases the amount of data exchanged in the course of the TLS handshake. Setting this value to **1** causes SChannel-based servers to send their lists of trusted issuers.
200 +TLS servers might send a list of the distinguished names of acceptable certificate authorities when requesting client authentication. This can help TLS clients select an appropriate TLS client certificate. SChannel-based TLS servers don't send this trusted issuer list by default because it exposes the certificate authorities trusted by the server to passive observers and also increases the amount of data exchanged in the course of the TLS handshake. Setting this value to *1* causes SChannel-based servers to send their lists of trusted issuers.
201201
202202 Not sending a list of trusted issuers might impact what the client sends when it's asked for a client certificate. For example, when Microsoft Edge receives a request for client authentication, it only displays the client certificates that chain up to one of the certification authorities that's sent by the server. If the server didn't send a list, Microsoft Edge displays all of the client certificates that are installed on the client.
203203
204 −This behavior might be desirable. For example, when PKI environments include cross certificates, the client and server certificates won't have the same root CA. Therefore, Microsoft Edge can't choose a certificate that chains up to one of the server's CAs. TLS clients may offer any available client certificate when a server doesn't send the trusted issuer list. This entry doesn't exist in the registry by default.
204 +This behavior might be desirable. For example, when PKI environments include cross certificates, the client and server certificates won't have the same root CA. Therefore, Microsoft Edge can't choose a certificate that chains up to one of the server's CAs. TLS clients might offer any available client certificate when a server doesn't send the trusted issuer list. This entry doesn't exist in the registry by default.
205205
206206 ### Default Send Trusted Issuer List behavior
207207
208208 | Windows version | Default behavior |
209209 |-----------------|------|
210 −| Windows Server 2012, Windows 8 and later | FALSE |
210 +| Windows Server 2012, Windows 8, and later | FALSE |
211211 | Windows Server 2008 R2, Windows 7, and earlier | TRUE |
212212
213213 Applicable versions: All versions beginning with Windows Server 2008 and Windows Vista.
⋯ 2 unchanged lines
216216
217217 ## ServerCacheTime
218218
219 −This entry specifies server TLS session cache item lifetime in milliseconds. The default is 10 hours. A value of **0** turns off TLS session caching on the server and prevents session resumption. Increasing ServerCacheTime above the default values causes Lsass.exe to consume additional memory. Each session cache element typically requires 2 KB to 4 KB of memory. This entry doesn't exist in the registry by default.
219 +This entry specifies server TLS session cache item lifetime in milliseconds. The default is 10 hours. A value of *0* turns off TLS session caching on the server and prevents session resumption. Increasing ServerCacheTime above the default values causes Lsass.exe to consume additional memory. Each session cache element typically requires 2 KB to 4 KB of memory. This entry doesn't exist in the registry by default.
220220
221221 Applicable versions: All versions beginning with Windows Server 2008 and Windows Vista.
222222
⋯ 12 unchanged lines
235235
236236 These registry values are configured separately for the protocol client and server roles under the registry subkeys named using the following format:
237237
238 −<SSL/TLS/DTLS> \<major version number\>.\<minor version number\>\<Client\Server>
238 +`<SSL/TLS/DTLS> <major version number>.<minor version number><Client\Server>`
239239
240240 These version-specific subkeys can be created under the following registry path:
241241
242 −**HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols**
242 +- **HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols**
243243
244244 For example, here are some valid registry paths with version-specific subkeys:
245245
⋯ 7 unchanged lines
253253
254254 The following example shows TLS 1.0 client set to the **Enabled** state:
255255
256 −![Screenshot of Set TLS 1.0 client-side to enabled in Windows Server registry setting.](images/tls-10-client-enabled.png)
256 +:::image type="content" source="images/tls-10-client-enabled.png" alt-text="Screenshot of Set TLS 1.0 client-side to enabled in Windows Server registry setting.":::
257257
258 −In order to override a system default and set a supported (D)TLS or SSL protocol version to the **Disabled** state, change the DWORD registry value of "Enabled" to "**0**" under the corresponding version-specific subkey.
258 +In order to override a system default and set a supported (D)TLS or SSL protocol version to the *Disabled* state, change the DWORD registry value of "Enabled" to *0* under the corresponding version-specific subkey.
259259
260260 The following example shows DTLS 1.2 disabled in the registry:
261261
262 −![Screenshot of Windows Server registry setting for DTLS 1.2 set to disabled by default.](images/dtls-12-server-disabled.png)
262 +:::image type="content" source="images/dtls-12-server-disabled.png" alt-text="Screenshot of Windows Server registry setting for DTLS 1.2 set to disabled by default.":::
263263
264 −Switching a (D)TLS or SSL protocol version to **Disabled** state may cause [AcquireCredentialsHandle](/windows/win32/secauthn/acquirecredentialshandle--schannel) calls to fail due to the lack of protocol versions enabled system-wide and at the same time allowed by particular SSPI callers. In addition, reducing the set of **Enabled** (D)TLS and SSL versions may break interoperability with remote peers.
264 +Switching a (D)TLS or SSL protocol version to *Disabled* state might cause [AcquireCredentialsHandle](/windows/win32/secauthn/acquirecredentialshandle--schannel) calls to fail due to the lack of protocol versions enabled system-wide and at the same time allowed by particular SSPI callers. In addition, reducing the set of *Enabled* (D)TLS and SSL versions may break interoperability with remote peers.
265265
266266 Once the (D)TLS or SSL protocol version settings are modified, they take effect on connections established using credential handles opened by subsequent [AcquireCredentialsHandle](/windows/win32/secauthn/acquirecredentialshandle--schannel) calls. (D)TLS and SSL client and server applications and services tend to reuse credential handles for multiple connections, for performance reasons. In order to get these applications to reacquire their credential handles, an application, or service restart may be required.
267267
⋯ 6 unchanged lines

Microsoft's Markdown source from MicrosoftDocs/windowsserverdocs, © Microsoft Corporation, under CC BY 4.0. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 10 Oct 08:07 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.

ChangeIntel

An IT change radar: releases, security, known issues, retirements, documentation changes, and service status from public sources. Every item links to supporting evidence; dates and statuses can change after they are read.

Sources read 20 Oct 22:55 UTC · 258 of 260 readable · 256 fully read · documentation 416/439 current

No accounts or analytics; your preferences stay in your browser. Information, not advice. ChangeIntel is an independent tool and is not affiliated with or endorsed by Microsoft, Apple, Google, Broadcom (VMware), Jamf, Oracle, Mozilla, or any other vendor it covers. Product names are trademarks of their owners. Built by Evotec.