Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article explique les informations de paramètre de Registre prises en charge pour l’implémentation Windows du protocole TLS (Transport Layer Security) et le protocole SSL (Secure Sockets Layer) via le fournisseur de support de sécurité (SSP) Schannel. Les sous-clés et entrées de Registre décrites dans cet article vous aident à administrer et à dépanner le SSP Schannel, en particulier les protocoles TLS et SSL.
Attention
Ces informations sont fournies en tant que référence à utiliser lorsque vous résolvez ou vérifiez que les paramètres requis sont appliqués. Nous vous recommandons de ne pas modifier directement le Registre, sauf s’il n’existe aucune autre alternative. Les modifications apportées au Registre ne sont pas validées par l’Éditeur du Registre ou par le système d’exploitation Windows avant qu’elles ne soient 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é 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 |
Remarque
Vous devez redémarrer votre appareil après avoir modifié le niveau de journalisation.
Méthodes de mappage des certificats
Lorsqu’une application serveur nécessite une authentification cliente, 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 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 du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
| Nom de l’entrée | DWORD | Activée par défaut |
|---|---|---|
| Sujet/Émetteur | 0x000000001 | Non |
| Émetteur | 0x000000002 | Non |
| UPN | 0x000000004 | Non |
| S4U2Self | 0x000000008 | Oui |
| S4U2Self Explicit | 0x000000010 | Oui |
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 commandes de suite de chiffrement par défaut utilisées par le 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 de la stratégie de groupe, mdm ou PowerShell, consultez Configuration de l’ordre de suite de chiffrement TLS pour plus d’informations.
Pour plus d’informations sur les commandes de suite de chiffrement par défaut utilisées par le SSP Schannel, consultez Suites de chiffrement dans TLS/SSL (SSP Schannel).
TempsDeCacheDuClient
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 SSP Schannel, une liaison TLS/SSL complète est effectuée. 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 du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
EnableOcspStaplingForSni
Le stapling OCSP (Online Certificate Status Protocol) permet à un serveur web, tel que Internet Information Services (IIS), de fournir l’état de révocation actuel d’un certificat de serveur lorsqu’il envoie ce certificat à un client pendant la poignée de main 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 OCSP Stapling de Windows s’adapte à des centaines de certificats de serveur. Toutefois, l’indication de nom de serveur (SNI) et le magasin de certificats central (CCS) permettent à IIS de s’adapter à des milliers de sites web qui ont potentiellement des milliers de certificats de serveur, ce qui fait qu'activer l'OCSP stapling pour les liaisons CCS peut causer des problèmes de performance.
Chemin du 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
Remarque
L’activation de cette clé de Registre peut avoir un impact sur les performances.
Hachages
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 la commande de 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 SSP Schannel tente de mapper tous les émetteurs de la chaîne de certificats du client, pas seulement l’émetteur direct du certificat 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 cela, le serveur a un cache négatif. Par conséquent, si un nom d’émetteur n’est pas mappé à un compte, il est ajouté au cache et le SSP Schannel ne tente pas de mapper à nouveau le nom de l’émetteur tant que l’entrée du cache n’expire pas. 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.
Chemin du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Durée de mise en cache de l'émetteur
Cette entrée contrôle la durée d’expiration du cache en millisecondes. Le SSP Schannel tente de mapper tous les émetteurs de la chaîne de certificats du client, pas seulement l’émetteur direct du certificat 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 cela, le serveur a un cache négatif. Par conséquent, si un nom d’émetteur n’est pas mappé à un compte, il est ajouté au cache et le SSP Schannel ne tente pas de mapper à nouveau le nom de l’émetteur tant que l’entrée du cache n’expire pas. 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.
Chemin du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Tailles de clés KeyExchangeAlgorithm
Ces entrées suivantes peuvent ne pas exister dans le Registre par défaut et 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. Pour en savoir plus sur les algorithmes de chiffrement de la suite de chiffrement TLS/SSL, consultez Les suites de chiffrement dans TLS/SSL (SSP Schannel).
Ajouté 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 bits de clé Diffie-Hellman pour le client TLS, créez une ClientMinKeyBitLength entrée. Après avoir créé l’entrée, remplacez la valeur DWORD par la longueur de bits souhaitée. S’il n’est pas configuré, 1024 bits est la valeur minimale.
Remarque
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).
MaximumCacheSize
Cette entrée contrôle le nombre maximal de sessions TLS à mettre en cache. Définir MaximumCacheSize sur 0 désactive le cache de session côté serveur afin d'empêcher la reprise de session. L’augmentation de MaximumCacheSize au-dessus des valeurs par défaut entraîne Lsass.exe consommer de la mémoire supplémentaire. 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.
Chemin du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Messagerie : analyse de fragments
Cette entrée contrôle la taille maximale autorisée d'un message de liaison TLS qui est accepté. Les messages supérieurs à la taille autorisée ne sont pas acceptés et l’établissement d’une liaison TLS échoue. Par défaut, ces entrées n’existent pas dans le Registre.
Lorsque vous définissez la valeur sur 0x0, les messages fragmentés ne sont pas traités et provoquent l’échec de la poignée de main 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. Autoriser un client ou un serveur à lire et stocker de grandes quantités de données non vérifiées à partir du réseau n’est pas une bonne idée et consomme de la mémoire supplémentaire 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 du registre : HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging
Pour spécifier une taille maximale autorisée de messages de négociation TLS fragmentés acceptés par le client TLS, créez une MessageLimitClient entrée. Après avoir créé l’entrée, remplacez la valeur DWORD par la longueur de bits souhaitée. S’il n’est pas configuré, la valeur par défaut est 0x8000 octets.
Pour spécifier une taille maximale autorisée de messages de négociation TLS fragmentés que le serveur TLS accepte lorsqu’il n’y a pas d’authentification client, créez une MessageLimitServer entrée. Après avoir créé l’entrée, remplacez la valeur DWORD par la longueur de bits souhaitée. Si elle n’est pas configurée, la valeur par défaut est de 0x4000 octets.
Pour spécifier une taille maximale autorisée de messages de négociation TLS fragmentés que le serveur TLS accepte lorsqu’il existe une authentification cliente, créez une MessageLimitServerClientAuth entrée. Après avoir créé l’entrée, remplacez la valeur DWORD par la longueur de bits souhaitée. 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 des 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é. Par défaut, les serveurs TLS basés sur Schannel n’envoient pas cette liste d’émetteurs approuvés, car elles exposent les autorités de certification approuvées par le serveur aux observateurs passifs et augmentent également la quantité de données échangées au cours de la négociation TLS. Si vous définissez cette valeur sur 1 , les serveurs Schannel envoient leurs listes d’émetteurs approuvés.
Ne pas envoyer une liste d'émetteurs approuvés pourrait affecter ce que le client envoie lorsqu'on lui demande un certificat client. Par exemple, lorsque Microsoft Edge reçoit une requête d'authentification du client, il n'affiche que les certificats du client qui s'enchaînent à l'une des autorités de certification envoyées par le serveur. Si le serveur n'a pas envoyé de liste, Microsoft Edge affiche tous les certificats clients installés sur le client.
Ce comportement peut être souhaitable. Par exemple, lorsque les 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, Microsoft Edge ne peut pas choisir un certificat qui s'enchaîne à l'une des autorités de certification du serveur. Les clients TLS peuvent proposer n’importe quel certificat client disponible lorsqu’un serveur n’envoie pas la liste des émetteurs approuvés. Par défaut, cette entrée n’existe pas dans le Registre.
Comportement par défaut d’envoi de la liste des émetteurs approuvés
| Version de Windows | Comportement par défaut |
|---|---|
| Windows Server 2012, Windows 8 et versions ultérieures | FAUX |
Chemin du registre : HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
TempsDeCacheDuServeur
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. Augmenter ServerCacheTime au-dessus des valeurs par défaut entraîne une consommation supplémentaire de mémoire par Lsass.exe. 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.
Chemin du 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é : sauf si l'appelant SSPI désactive explicitement cette version de protocole à l'aide de la structure SCH_CREDENTIALS, Schannel SSP peut négocier cette version de protocole avec un homologue compatible.
- Désactivé : Schannel SSP ne négocie pas cette version de protocole, quels que soient les paramètres que l’appelant SSPI peut spécifier.
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> <major version number>.<minor version number><Client\Server>
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\ClientHKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\ServerHKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\DTLS 1.2\Client
Pour remplacer une valeur système par défaut et définir une version de protocole TLS ou SSL prise en charge sur l’état Enabled , créez une valeur de Registre DWORD nommée Enabled avec une valeur d’entrée de « 1 » sous la sous-clé spécifique à la version correspondante.
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 Disabled, 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 :
Changer une version de protocole (D)TLS ou SSL vers l’état Disabled pourrait entraîner l’échec des appels AcquireCredentialsHandle en raison de l’absence de versions de protocole activées à l’échelle du système et autorisées simultanément par des appelants SSPI particuliers. En outre, la réduction de l’ensemble de versions ( Enabled D)TLS et SSL peut interrompre l’interopérabilité avec les homologues distants.
Une fois que les paramètres de la version du protocole (D)TLS ou SSL sont modifiés, ils prennent effet sur les connexions établies à l'aide de gestionnaires d'informations d'identification ouverts par des appels AcquireCredentialsHandle ultérieurs. 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. Pour permettre à ces applications de réactiver leurs gestionnaires d'identifiants, il peut s'avérer nécessaire de redémarrer une application ou le service.
Ces paramètres de Registre s’appliquent uniquement au fournisseur SSP Schannel et n’affectent pas les implémentations TLS et SSL tierces qui peuvent être installées sur le système.
Avertissement
La tentative de création ou d’ajustement de paramètres de Registre Schannel qui ne sont pas explicitement détaillés dans cet article n’est pas recommandée en raison de risques potentiels et de conséquences inattendues qui peuvent survenir à partir de configurations non prises en charge.
Pour en savoir plus sur la gestion de la suite de chiffrement TLS à l'aide de PowerShell, consultez la référence de la commande TLS. Si vous souhaitez gérer les paramètres TLS via une stratégie de groupe, consultez Configurer l’ordre de suite de chiffrement TLS à l’aide de la stratégie de groupe.