Paramètres du Registre protocole TLS
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 11, Windows 10 et versions antérieures indiquées
Cet article décrit les informations de paramètre de Registre prises en charge pour l’implémentation Windows des protocoles TLS (Transport Layer Security) et SSL (Secure Sockets Layer) par le biais du fournisseur SSP (Security Support Provider) Schannel. Les sous-clés et entrées de Registre couvertes dans cet article vous aident à administrer et à dépanner le SSP Schannel, en particulier avec les protocoles TLS et SSL.
Attention
Ces informations sont fournies à titre de référence et peuvent être utilisées dans le cadre de la résolution de problèmes ou de la vérification de l’application des paramètres requis. Nous vous recommandons de ne pas modifier directement le Registre, sauf s’il n’y a pas d’autre solution. Les modifications apportées au Registre ne sont pas validées par l’Éditeur du Registre ni par le système d’exploitation Windows avant d’être appliquées. Par conséquent, des valeurs incorrectes peuvent être stockées et cela peut générer des erreurs irrécupérables dans le système. Plutôt que de modifier directement le Registre, utilisez si possible la stratégie de groupe ou d’autres outils Windows tels que la console MMC (Microsoft Management Console). Si vous devez modifier le Registre, soyez très vigilant.
Journalisation Schannel
Il existe huit niveaux de journalisation pour les événements Schannel enregistrés dans le journal des événements système et visibles à l’aide de l’observateur d’événements. Ce chemin de Registre est stocké dans HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL sous la clé EventLogging avec une valeur DWORD définie sur 1.
| Décimal ou hexadécimal | Événements de journalisation Schannel |
|---|---|
| 0 | Aucun événement |
| 1 | Événements d’erreur |
| 2 | Événements d’avertissement |
| 3 | Événements d’erreur et d’avertissement |
| 4 | Événements d’information et de réussite |
| 5 | Événements d’erreur, d’information et de réussite |
| 6 | Événements d’avertissement, d’information et de réussite |
| 7 | Événements d’erreur, d’avertissement, d’information et de réussite |
Notes
Vous devez redémarrer votre appareil après avoir modifié le niveau de journalisation Schannel.
CertificateMappingMethods
Quand une application serveur nécessite une authentification du client, SChannel tente automatiquement de mapper le certificat fourni par l’ordinateur client à un compte d’utilisateur. Vous pouvez authentifier les utilisateurs qui se connectent avec un certificat client en créant des mappages qui lient les informations de certificat à un compte d’utilisateur Windows.
Après avoir créé et activé un mappage de certificat, chaque fois qu’un client présente un certificat client, votre application serveur associe automatiquement cet utilisateur au compte d’utilisateur Windows approprié.
Dans la plupart des cas, un certificat est mappé avec un compte d’utilisateur de deux manières :
- Un seul certificat est mappé avec un compte d’utilisateur (mappage un-à-un).
- Plusieurs certificats sont mappés avec un compte d’utilisateur (mappage plusieurs-à-un).
Le fournisseur SChannel utilise quatre (4) méthodes de mappage de certificats :
- Mappage S4U (service-for-user) Kerberos (activé par défaut)
- Mappage du nom principal de l’utilisateur
- Mappage un-à-un (également appelé mappage objet/émetteur)
- Mappage plusieurs-à-un
Chemin de Registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
| Nom de l’entrée | DWORD | Activée par défaut |
|---|---|---|
| Subject/Issuer | 0x000000001 | Non |
| Émetteur | 0x000000002 | Non |
| UPN | 0x000000004 | Non |
| S4U2Self | 0x000000008 | Oui |
| S4U2Self Explicit | 0x000000010 | Oui |
Versions applicables : comme indiqué dans la liste S’applique à qui se trouve au début de cet article.
Chiffrements
Les chiffrements TLS/SSL doivent être contrôlés en configurant l’ordre de la suite de chiffrement. Pour plus d’informations, consultez Configuration de l’ordre de la suite de chiffrement TLS.
Pour plus d’informations sur les ordres de la suite de chiffrement par défaut utilisés par le fournisseur SSP SChannel, consultez Suites de chiffrement dans TLS/SSL (SSP SChannel).
CipherSuites
La configuration des suites de chiffrement TLS/SSL doit être effectuée à l’aide d’une stratégie de groupe, de la MDM ou de PowerShell. Pour plus d’informations, consultez Configuration de l’ordre de la suite de chiffrement TLS.
Pour plus d’informations sur les ordres de la suite de chiffrement par défaut utilisés par le fournisseur SSP SChannel, consultez Suites de chiffrement dans TLS/SSL (SSP SChannel).
ClientCacheTime
Cette entrée spécifie la durée de vie de l’élément de cache de session TLS du client en millisecondes. À compter de Windows Server 2008 et de Windows Vista, la valeur par défaut est de 10 heures. La valeur 0 désactive la mise en cache de session TLS sur le client.
La première fois qu’un client se connecte à un serveur via le fournisseur SSP SChannel, une liaison TLS/SSL complète est établie. Ensuite, le secret principal, la suite de chiffrement et les certificats sont stockés dans le cache de session sur le client et le serveur correspondants.
Chemin de Registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
EnableOcspStaplingForSni
L’association OCSP (Online Certificate Status Protocol) permet à un serveur web, par exemple IIS (Internet Information Services), de fournir l’état de révocation actuel d’un certificat de serveur lorsqu’il envoie le certificat de serveur à un client pendant l’établissement d’une liaison TLS. Cette fonctionnalité réduit la charge des serveurs OCSP, car le serveur web peut mettre en cache l’état OCSP actuel du certificat de serveur et l’envoyer à plusieurs clients web. Sans cette fonctionnalité, chaque client web tenterait de récupérer l’état OCSP actuel du certificat de serveur auprès du serveur OCSP, ce qui générerait une charge élevée sur ce serveur OCSP.
En dehors d’IIS, les services web sur http.sys peuvent également tirer parti de ce paramètre, notamment les services de fédération Active Directory (AD FS) et le Proxy d’application web (WAP).
Par défaut, la prise en charge d’OCSP est activée pour les sites web IIS comportant une liaison sécurisée (SSL/TLS) simple. Cependant, cette prise en charge n’est pas activée par défaut si le site web IIS utilise l’un des types de liaisons SSL/TLS suivants ou les deux :
- Exiger l'indication de nom de serveur
- Utiliser le magasin de certificats centralisés
Dans ce cas, la réponse hello du serveur pendant l’établissement d’une liaison TLS n’inclut pas d’état associé OCSP par défaut. Ce comportement améliore les performances : l’implémentation de l’association OCSP Windows s’adapte à des centaines de certificats de serveur. Cependant, l’indication du nom du serveur (SNI) et le magasin de certificats central (CCS) permettent à IIS de mettre à l’échelle des milliers de sites web qui ont potentiellement des milliers de certificats de serveur. Par conséquent, l’activation de l’agrafage OCSP pour les liaisons CCS peut entraîner des problèmes de performances.
Versions applicables : toutes les versions à compter de Windows Server 2012 et Windows 8.
Chemin de Registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Ajoutez la clé suivante :
"EnableOcspStaplingForSni"=dword:00000001
Pour désactiver l’option, définissez la valeur DWORD sur 0 :
"EnableOcspStaplingForSni"=dword:00000000
Notes
L’activation de cette clé de Registre peut avoir un impact sur les performances.
Codes de hachage
Les algorithmes de hachage TLS/SSL doivent être contrôlés en configurant l’ordre de la suite de chiffrement. Pour plus d’informations, consultez Configuration de l’ordre de la suite de chiffrement TLS.
IssuerCacheSize
Cette entrée contrôle la taille du cache de l’émetteur et est utilisée avec le mappage d’émetteur. Le fournisseur SSP SChannel tente de mapper tous les émetteurs de la chaîne de certificats du client, et pas seulement l’émetteur direct du certificat du client. Lorsque les émetteurs ne correspondent pas à un compte (cas classique), le serveur peut tenter de mapper le même nom d’émetteur à plusieurs reprises, des centaines de fois par seconde.
Pour éviter ce problème, le serveur possède un cache négatif. Ainsi, tout nom d’émetteur qui ne correspond pas à un compte est ajouté au cache. Le fournisseur SSP SChannel ne tente pas de le mapper à nouveau tant que l’entrée de cache n’a pas expiré. Cette entrée de Registre spécifie la taille du cache. Par défaut, cette entrée n’existe pas dans le Registre. La valeur par défaut est 100.
Versions applicables : toutes les versions à compter de Windows Server 2008 et Windows Vista.
Chemin de Registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
IssuerCacheTime
Cette entrée contrôle l’intervalle de temps d’expiration du cache en millisecondes. Le fournisseur SSP SChannel tente de mapper tous les émetteurs de la chaîne de certificats du client, et pas seulement l’émetteur direct du certificat du client. Lorsque les émetteurs ne correspondent pas à un compte (cas classique), le serveur peut tenter de mapper le même nom d’émetteur à plusieurs reprises, des centaines de fois par seconde.
Pour éviter ce problème, le serveur possède un cache négatif. Ainsi, tout nom d’émetteur qui ne correspond pas à un compte est ajouté au cache. Le fournisseur SSP SChannel ne tente pas de le mapper à nouveau tant que l’entrée de cache n’a pas expiré. Ce cache est conservé pour des raisons de performances, afin que le système ne continue pas de tente de mapper les mêmes émetteurs. Par défaut, cette entrée n’existe pas dans le Registre. La valeur par défaut est 10 minutes.
Versions applicables : toutes les versions à compter de Windows Server 2008 et Windows Vista.
Chemin de Registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Tailles de clés KeyExchangeAlgorithm
Les entrées de la liste suivante peuvent ne pas exister par défaut dans le Registre, auquel cas elles doivent être créées manuellement. L’utilisation d’algorithmes d’échange de clés doit être contrôlée en configurant l’ordre de la suite de chiffrement.
Ajoutée dans Windows 10 version 1507 et Windows Server 2016.
Chemin du Registre : HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman
Pour spécifier une plage minimale prise en charge de longueur de clé en bits Diffie-Hellman pour le client TLS, créez une entrée ClientMinKeyBitLength. Remplacez ensuite la valeur DWORD par la longueur souhaitée en bits. 1 024 bits est le minimum par défaut.
Pour spécifier une plage maximale prise en charge de longueur de clé en bits Diffie-Hellman pour le client TLS, créez une entrée ClientMaxKeyBitLength. Remplacez ensuite la valeur DWORD par la longueur souhaitée en bits.
Pour spécifier la longueur de clé en bits Diffie-Hellman par défaut du serveur TLS, créez une entrée ServerMinKeyBitLength. Remplacez ensuite la valeur DWORD par la longueur souhaitée en bits. S’il n’est pas configuré, 2048 bits est la valeur par défaut.
Notes
Les courbes elliptiques configurées déterminent la force de chiffrement de l’échange de clés ECDHE. Pour plus d’informations, consultez Gérer TLS (Transport Layer Security).
Pour en savoir plus sur les algorithmes de suite de chiffrement TLS/SSL, consultez les pages suivantes :
MaximumCacheSize
Cette entrée contrôle le nombre maximal de sessions TLS à mettre en cache. En définissant MaximumCacheSize sur 0, vous désactivez le cache de session côté serveur et empêchez la reprise de session. Lorsque la valeur de cette entrée est supérieure aux valeurs par défaut, Lsass.exe consomme plus de mémoire. Chaque élément du cache de session exige généralement 2 à 4 Ko de mémoire. Par défaut, cette entrée n’existe pas dans le Registre. La valeur par défaut est 20 000 éléments.
Versions applicables : toutes les versions à compter de Windows Server 2008 et Windows Vista.
Chemin de Registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Messagerie : analyse de fragments
Cette entrée contrôle la taille maximale autorisée d’un message d’établissement de liaison TLS. Les messages d’une taille supérieure à la taille maximale autorisée ne sont pas acceptés, et l’établissement de la liaison TLS échoue. Par défaut, ces entrées n’existent pas dans le Registre.
Quand vous définissez la valeur sur 0x0, les messages fragmentés ne sont pas traités et entraînent l’échec de l’établissement de la liaison TLS. Les clients ou serveurs TLS de la machine active se retrouvent donc en non-conformité avec les RFC TLS.
La taille maximale autorisée peut être augmentée jusqu’à 2^16 octets. Il n’est pas judicieux d’autoriser un client ou un serveur à lire et à stocker de grandes quantités de données non vérifiées en provenance du réseau. De plus, une quantité de mémoire supplémentaire sera consommée pour chaque contexte de sécurité.
Ajout dans Windows 7 et Windows Server 2008 R2 : une mise à jour permettant à Internet Explorer dans Windows XP, Windows Vista et Windows Server 2008 d’analyser des messages fragmentés d’établissement d’une liaison TLS/SSL est disponible.
Chemin de Registre : HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging
Pour spécifier la taille maximale autorisée des messages fragmentés d’établissement d’une liaison TLS que le client TLS acceptera, créez une entrée MessageLimitClient. Remplacez ensuite la valeur DWORD par la longueur souhaitée en bits. Si elle n’est pas configurée, la valeur par défaut est de 0x8000 octets.
Pour spécifier la taille maximale autorisée des messages fragmentés d’établissement de liaison TLS que le serveur TLS acceptera en l’absence d’authentification client, créez une entrée MessageLimitServer. Remplacez ensuite la valeur DWORD par la longueur souhaitée en bits. Si elle n’est pas configurée, la valeur par défaut est de 0x4000 octets.
Pour spécifier la taille maximale autorisée des messages fragmentés d’établissement de liaison TLS que le serveur TLS acceptera en présence d’une authentification client, créez une entrée MessageLimitServerClientAuth. Remplacez ensuite la valeur DWORD par la longueur souhaitée en bits. Si elle n’est pas configurée, la valeur par défaut est de 0x8000 octets.
SendTrustedIssuerList
Les serveurs TLS peuvent envoyer une liste des noms uniques d’autorités de certification acceptables lors de la demande d’authentification du client. Cela peut aider les clients TLS à sélectionner un certificat client TLS approprié. Les serveurs TLS basés sur SChannel n’envoient pas cette liste d’émetteurs approuvés par défaut, car les autorités de certification approuvées par le serveur se trouvent exposées à des observateurs passifs et la quantité de données échangées au cours de l’établissement de la liaison TLS s’en trouve également augmentée. Si vous définissez cette valeur sur 1, les serveurs basés sur SChannel envoient leurs listes d’émetteurs approuvés.
Ne pas envoyer une liste d’émetteurs approuvés peut avoir un impact sur ce que le client envoie lorsqu’il reçoit une demande de certificat client. Par exemple, lorsqu’Internet Explorer reçoit une demande d’authentification du client, il affiche uniquement les certificats du client qui sont liés à l’une des autorités de certification qui est envoyée par le serveur. Si le serveur n’a pas envoyé de liste, Internet Explorer affiche tous les certificats client installés sur le client.
Ce comportement peut être souhaitable. Par exemple, quand des environnements PKI incluent des certificats croisés, les certificats client et serveur n’ont pas la même autorité de certification racine. Par conséquent, Internet Explorer ne peut pas choisir un certificat qui est lié à l’une des autorités de certification du serveur. Quand un serveur n’envoie pas la liste des émetteurs approuvés, les clients TLS peuvent offrir n’importe quel certificat client disponible. Par défaut, cette entrée n’existe pas dans le Registre.
Comportement d’envoi de la liste par défaut des émetteurs approuvés
| Version de Windows | Comportement par défaut |
|---|---|
| Windows Server 2012, Windows 8 et versions ultérieures | FALSE |
| Windows Server 2008 R2, Windows 7 et versions antérieures | TRUE |
Versions applicables : toutes les versions à compter de Windows Server 2008 et Windows Vista.
Chemin de Registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
ServerCacheTime
Cette entrée spécifie la durée de vie de l’élément de cache de session TLS du serveur en millisecondes. La valeur par défaut est 10 heures. La valeur 0 désactive la mise en cache de session TLS sur le serveur et empêche la reprise de session. Lorsque la valeur de cette entrée est supérieure aux valeurs par défaut, Lsass.exe consomme plus de mémoire. Chaque élément de cache de session nécessite en général entre 2 et 4 Ko de mémoire. Par défaut, cette entrée n’existe pas dans le Registre.
Versions applicables : toutes les versions à compter de Windows Server 2008 et Windows Vista.
Chemin de Registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Durée du cache du serveur par défaut : 10 heures
Paramètres de version des protocoles TLS, DTLS et SSL
Le fournisseur SSP SChannel implémente différentes versions des protocoles TLS, DTLS et SSL. Les versions des protocoles prises en charge varient selon les versions de Windows. L’ensemble des versions des protocoles (D)TLS et SSL disponibles à l’échelle du système peut être restreint (mais pas étendu) par les appelants SSPI qui spécifient la structure SCH_CREDENTIALS dans l’appel AcquireCredentialsHandle. Il est recommandé aux appelants SSPI d’utiliser les valeurs par défaut du système, plutôt que d’imposer des restrictions sur la version des protocoles.
Une version prise en charge des protocoles (D)TLS et SSL peut se trouver dans les états suivants :
- Activé : À moins que l’appelant SSPI désactive explicitement cette version de protocole à l’aide de la structure SCH_CREDENTIALS, le fournisseur SSP SChannel peut négocier cette version de protocole avec un pair qui la prend en charge.
- Désactivé : Le fournisseur SSP SChannel ne négocie pas cette version de protocole, quels que soient les paramètres spécifiés par l’appelant SSPI.
Ces valeurs de Registre sont configurées séparément pour les rôles client et serveur de protocole sous les sous-clés de Registre nommées au format suivant :
<SSL/TLS/DTLS><numéro de version majeure>.<numéro de version mineure><Client\Serveur>
Ces sous-clés propres à la version peuvent être créées sous le chemin de Registre suivant :
HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Par exemple, voici quelques chemins de Registre valides avec des sous-clés propres à la version :
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
Pour remplacer une valeur système par défaut et définir une version prise en charge des protocoles (D)TLS et SSL à l’état Activé, sous la sous-clé propre à la version correspondante, créez une valeur de Registre DWORD nommée « Enabled » avec la valeur « 1 ».
L’exemple suivant montre un client TLS 1.0 défini sur l’état Activé :
Pour remplacer une valeur système par défaut et définir une version prise en charge des protocoles (D)TLS et SSL à l’état Désactivé, sous la sous-clé propre à la version correspondante, remplacez la valeur de Registre DWORD « Enabled » par « 0 ».
L’exemple suivant montre le protocole DTLS 1.2 désactivé dans le Registre :
Le basculement d’une version des protocoles (D)TLS et SSL vers l’état Désactivé peut entraîner l’échec des appels AcquireCredentialsHandle en raison de l’absence de versions qui sont à la fois activées à l’échelle du système et autorisées par des appelants SSPI particuliers. En outre, le fait de réduire l’ensemble des versions Activées des protocoles (D)TLS et SSL risque de rompre l’interopérabilité avec les pairs distants.
Une fois modifiés, les paramètres de version des protocoles (D)TLS et SSL prennent effet sur les connexions établies à l’aide de handles d’informations d’identification ouverts par les appels AcquireCredentialsHandle suivants. Les applications et services client et serveur (D)TLS et SSL ont tendance, pour des raisons de performances, à réutiliser les handles d’informations d’identification sur plusieurs connexions. Un redémarrage de ces applications et services peut être nécessaire pour qu’ils acquièrent à nouveau leurs handles d’informations d’identification.
Ces paramètres de Registre s’appliquent uniquement au fournisseur SSP SChannel. Ils n’affectent pas les implémentations tierces des protocoles (D)TLS et SSL qui peuvent être installées sur le système.