Erreurs Schannel 36871/36874 TLS sur Windows Server 2022/2019 : diagnostic, causes et correctifs rapides

Résolvez les erreurs Schannel Event ID 36871 et 36874 liées à TLS sur Windows Server 2022/2019 : identifiez si le serveur agit en client ou en serveur, remettez les suites au défaut OS, forcez .NET à TLS modernes, contrôlez certificats et clés privées, puis validez la négociation avec des tests concrets.

Sommaire

Contexte et symptômes observés

Sur plusieurs hôtes Windows Server 2022 (et parfois 2019), le journal System enregistre en boucle :

Event ID 36871 : « A fatal error occurred while creating a TLS client credential. Internal error state 10013 » ou, sur certains cumulatifs 2019 au printemps 2024, état 10010.
Event ID 36874 : « TLS 1.2 connection request… none of the cipher suites supported by the client are supported by the server. »

Les clés Registre SCHANNEL (activation de TLS 1.2) sont déjà en place (Enabled=1, DisabledByDefault=0) côté Client et Server, mais les erreurs persistent. Côté client, TLS 1.2 est annoncé actif. Vous retrouvez aussi le même scénario sur des hôtes 2019 après des correctifs d’avril–juin 2024.

Comprendre les événements Schannel

Avant d’agir, il faut séparer clairement deux mécanismes.

Événement	Rôle du serveur	Signal fort	Cause typique	Action immédiate
36874	Serveur	Aucune suite de chiffrement commune trouvée pour TLS 1.2	Ordre de suites personnalisé trop restrictif, certificat/ECDSA↔RSA incohérents, TLS 1.2 involontairement désactivé	Revenir aux suites par défaut OS ou inclure ECDHE_RSA/ECDHE_ECDSA en AES‑GCM
36871	Client	Échec à la création des identifiants client lors d’une connexion sortante	Version/suite bloquée par stratégie, application .NET n’autorisant pas TLS modernes, certificat client manquant, accès à la clé privée, mode FIPS	Activer TLS modernes côté .NET, vérifier certificats/ACL, lever les blocages stratégiques

Plan d’action prioritaire

Voici une séquence courte qui résout la majorité des boucles 36871/36874 sans tâtonner.

Remettre l’ordre des suites au défaut système : dans la stratégie Configuration ordinateur → Modèles d’administration → Réseau → SSL Configuration Settings → SSL Cipher Suite Order, passez le paramètre sur Non configuré. Si une personnalisation est imposée, incluez au minimum :
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (si certificat ECDSA)
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (si certificat ECDSA)
Valider SCHANNEL pour TLS 1.2 : contrôlez côté Client et Server les clés suivantes (DWORD : Enabled=1, DisabledByDefault=0) puis redémarrez : HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
Forcer les applications .NET à TLS modernes : ajoutez sur x64 et Wow6432Node : HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319 Valeurs DWORD : SystemDefaultTlsVersions=1, SchUseStrongCrypto=1. Pour les applis .NET 2.0–3.5, dupliquez sous v2.0.50727 si nécessaire.
Vérifier le certificat serveur : dans certlm.msc → Ordinateur local → Personnel → Certificats, contrôlez validité, chaîne, présence de la clé privée et cohérence des suites avec le type de certificat (RSA ou ECDSA).
Traiter spécifiquement l’événement côté client : si un certificat client est requis (mTLS, LDAPS, proxy), vérifiez son existence côté Ordinateur local\Personnel, sa non‑expiration et l’accès à la clé privée par le compte SYSTEM ou le compte de service. Désactivez un éventuel mode FIPS si non requis ou adaptez les suites.

Procédure détaillée et explications

Remise à zéro des suites de chiffrement

La cause la plus fréquente de 36874 est une liste de suites trop étroite, souvent héritée d’un durcissement ancien. Commencez par revenir au défaut OS puis réappliquez le durcissement par paliers mesurés.

# Voir les suites exposées par l'OS
Get-TlsCipherSuite | Select-Object Name, Exchange, Cipher, Hash, Protocols

# Vérifier la provenance d'une personnalisation

gpresult /h C:\gp.html & start C:\gp.html

# Supprimer une surcouche locale héritée d'un test (à utiliser avec prudence)

reg delete "HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002" /v Functions /f

# Rafraîchir la stratégie

gpupdate /force

Type de certificat serveur	Suites minimales à inclure	Remarque
RSA	`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`, `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`	Évitez les suites CBC/RC4/3DES. Laissez l’OS gérer l’ordre.
ECDSA	`TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`, `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`	Nécessite une chaîne ECDSA complète côté client.

Activation de TLS moderne côté système

Windows Server récents supportent TLS 1.2 nativement. Vérifiez les clés Client et Server sous SCHANNEL ; évitez toute désactivation involontaire via GPO. Sur 2022, TLS 1.3 peut être activé, mais la majorité des traces 36874 observées concernent une négociation en 1.2 ; assurez‑vous qu’il reste actif tant que tous les clients ne savent pas parler 1.3.

# Contrôler d'un coup d'œil TLS 1.2 côté client et serveur
'Client','Server' | ForEach-Object {
  $p = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\$_"
  [pscustomobject]@{
    Path = $p
    Enabled = (Get-ItemProperty -Path $p -Name Enabled -ErrorAction SilentlyContinue).Enabled
    DisabledByDefault = (Get-ItemProperty -Path $p -Name DisabledByDefault -ErrorAction SilentlyContinue).DisabledByDefault
  }
}

# Forcer les bonnes valeurs (création si absent)

\$paths = @(
"HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client",
"HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server"
)
foreach(\$p in \$paths){
if(-not (Test-Path \$p)){ New-Item -Path \$p -Force | Out-Null }
New-ItemProperty -Path \$p -Name Enabled -PropertyType DWord -Value 1 -Force | Out-Null
New-ItemProperty -Path \$p -Name DisabledByDefault -PropertyType DWord -Value 0 -Force | Out-Null
}

Important : un redémarrage est requis pour que les modifications SCHANNEL soient pleinement prises en compte.

Paramètres .NET pour utiliser TLS modernes

Beaucoup d’applications .NET historiques restent figées sur des versions obsolètes du protocole si on ne leur autorise pas explicitement l’usage des versions gérées par l’OS. Deux clés suffisent le plus souvent.

# Appliquer Strong Crypto & System Default TLS
$roots = @(
 "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319",
 "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319"
)
foreach($r in $roots){
  New-Item -Path $r -Force | Out-Null
  New-ItemProperty -Path $r -Name SchUseStrongCrypto -PropertyType DWord -Value 1 -Force | Out-Null
  New-ItemProperty -Path $r -Name SystemDefaultTlsVersions -PropertyType DWord -Value 1 -Force | Out-Null
}

# Optionnel pour des applis 2.0–3.5

\$legacy = @(
"HKLM:\SOFTWARE\Microsoft.NETFramework\v2.0.50727",
"HKLM:\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v2.0.50727"
)
foreach(\$r in \$legacy){
if(-not (Test-Path \$r)){ continue }
New-ItemProperty -Path \$r -Name SchUseStrongCrypto -PropertyType DWord -Value 1 -Force | Out-Null
}

Pour un test direct d’une appli PowerShell héritée, forcez provisoirement l’usage de TLS moderne et tentez une requête vers la cible (IIS, proxy, API interne) :

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest https://monserveur.exemple.tld/ -UseBasicParsing

Certificats serveur, type et accès à la clé privée

Schannel côté serveur compose les suites en fonction du type de certificat lié au service : un certificat RSA exige des suites ECDHE_RSA, un certificat ECDSA, des suites ECDHE_ECDSA. Un mélange incohérent conduit à 36874. Vérifiez aussi la clé privée : absence, corruption ou ACL erronée produisent souvent 36871 côté client si un certificat client est requis.

Emplacement	Chemin clé privée	Composant	Qui doit avoir accès
Ordinateur local\Personnel	`C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys`	Clés CAPI RSA	SYSTEM, compte de service du rôle (IIS, AD LDS, proxy)
Ordinateur local\Personnel	`C:\ProgramData\Microsoft\Crypto\Keys`	Clés CNG (RSA/ECDSA)	SYSTEM, compte de service du rôle

# Localiser le fichier de clé privée associé à un certificat donné (thumbprint connu)
$thumb="‎<THUMBPRINT_SANS_ESPACES>"
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object Thumbprint -eq $thumb
if($cert -and $cert.HasPrivateKey){
  try{
    $prov = $cert.PrivateKey.CspKeyContainerInfo # CAPI
    if($prov){
      $path = Join-Path $env:ProgramData "Microsoft\Crypto\RSA\MachineKeys\$($prov.UniqueKeyContainerName)"
    }
  } catch {
    # CNG
    $kp = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($cert)
    if(-not $kp){
      $kp = [System.Security.Cryptography.X509Certificates.ECDsaCertificateExtensions]::GetECDsaPrivateKey($cert)
    }
    $path = "$env:ProgramData\Microsoft\Crypto\Keys\*" # à inspecter manuellement
  }
  $path | ForEach-Object { if(Test-Path $_){ Get-Acl $_ | Format-List } }
}

:: Accorder l'accès à SYSTEM (exemple CAPI)
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\<NomFichierKey>" /grant "NT AUTHORITY\SYSTEM":F

\:: Accorder l'accès à un compte de service (IIS AppPool\SiteXYZ)
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\<NomFichierKey>" /grant "IIS AppPool\SiteXYZ"\:R

Assurez‑vous également que le certificat serveur lie bien l’usage de la clé attendu (Signature serveur, Échange de clé) et que sa chaîne intermédiaire est présente dans le magasin Intermediate Certification Authorities.

Spécificités de l’événement côté client

Quand le système agit en client TLS (Windows Update, proxy sortant, LDAPS vers un DC, collecte de journaux, agents divers), 36871 peut apparaître même sur un « serveur pur ». Les causes les plus fréquentes :

Application .NET ancienne qui n’active pas d’elle‑même TLS modernes : appliquer Strong Crypto et SystemDefaultTlsVersions.
Exigence d’un certificat client (mTLS) non présent ou dont la clé privée est inaccessible au compte exécutant le service.
Mode FIPS activé (Options de sécurité → Utiliser des algorithmes conformes FIPS) restreignant les suites disponibles pour l’application concernée.
Désactivation involontaire de suites nécessaires par GPO locale ou domaine.

Journalisation et tests ciblés

Activez temporairement la journalisation détaillée puis testez la négociation depuis l’extérieur et depuis l’hôte.

Windows Registry Editor Version 5.00

\[HKEY\_LOCAL\_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000007

Pensez à revenir à la valeur par défaut une fois l’analyse terminée pour éviter du bruit inutile.

# Depuis un poste client : vérifier la négociation réelle
openssl s_client -connect monserveur.exemple.tld:443 -tls1_2 -servername monserveur.exemple.tld

# Sur l'hôte cible : lister les suites actives et vérifier le binding IIS/RDP/LDAPS

powershell -c "Get-TlsCipherSuite | Select Name"

Pour RDP, confirmez que le mode sécurité exigeant TLS ne se heurte pas à un jeu de suites trop réduit. Pour LDAPS, un test avec ldp.exe sur le port 636 révèle rapidement une chaîne incomplète ou une clé privée absente.

Cas particulier sur des hôtes mis à jour au printemps

Des environnements Windows Server 2019 ont signalé des 36871 état 10010 après des cycles de patchs du printemps 2024. Dans la plupart des cas, le problème ne vient pas du correctif lui‑même mais d’un durcissement préexistant devenu incompatible avec la pile cryptographique courante. Procédez comme suit :

Réinitialisez l’ordre des suites à la valeur par défaut OS (ou appliquez un modèle « bonnes pratiques » si vous utilisez déjà un outil de durcissement, en évitant les suites CBC/RC4).
Vérifiez/ajoutez les clés .NET Strong Crypto et SystemDefaultTlsVersions sur les ruches 64/32 bits.
Contrôlez les GPO déployées pendant la fenêtre de maintenance ; la désinstallation d’un patch ne supprime pas les changements de stratégie.
Effectuez un redémarrage après chaque modification structurante sur SCHANNEL et refaites un test de négociation.

Arbre de décision rapide

Le journal indique 36874 : problème d’intersection de suites. Revenez au défaut OS, gardez ECDHE + AES‑GCM, vérifiez la cohérence RSA/ECDSA. Testez avec openssl s_client -tls1_2.
Le journal indique 36871 : le système agit en client. Cherchez une connexion sortante (proxy, LDAPS, agent). Appliquez Strong Crypto .NET, vérifiez la présence d’un certificat client et l’accès à sa clé privée.
Le doute persiste : activez EventLogging=7, reproduisez le souci, corrélez le Process ID si possible (IIS/LSASS/SYSTEM) pour trouver le composant fautif.

Exemples de commandes prêtes à l’emploi

Remise au défaut OS des suites via stratégie locale

:: Ouvrir l'éditeur des stratégies locales
gpedit.msc
:: Chemin : Configuration ordinateur > Modèles d'administration > Réseau > SSL Configuration Settings
:: Paramètre : SSL Cipher Suite Order > Non configuré

Personnalisation minimale sûre des suites

$min = @(
 "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
 "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
)
# Si certificat ECDSA, ajoutez :
$ecdsa = @(
 "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
 "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
)

Vérifier un binding IIS

Import-Module WebAdministration
Get-WebBinding -Protocol https | Select bindingInformation, certificateHash, certificateStoreName

Tester LDAPS

ldp.exe
:: Connexion > Connect > NomDuServeur, Port 636, case SSL cochée

FAQ et pièges fréquents

« TLS 1.2 est activé, pourtant 36874 apparaît » : 36874 ne dit pas que le protocole est désactivé, mais qu’aucune suite commune n’a été trouvée. Le plus souvent, la liste de suites a été trop durcie.
« Le serveur n’héberge aucun site, pourquoi 36871 ? » : l’événement est généré par le processus SYSTEM quand la machine agit en client TLS (Windows Update, proxy, LDAPS…).
« Nous avons supprimé toutes les suites CBC et TLS 1.0/1.1 » : c’est souhaitable, mais gardez ECRHE/ECDHE avec AES‑GCM et vérifiez la cohérence avec votre certificat.
« Mode FIPS activé » : cela peut bloquer certaines suites/implémentations côté application. Assurez‑vous que l’app cible les suites autorisées par FIPS ou désactivez l’option si non obligatoire.
« Tout marchait avant les derniers patchs » : une mise à jour peut resserrer les défauts OS et révéler un durcissement antérieur trop strict. Revenir au défaut, tester, puis durcir progressivement.

Checklist de validation après correction

Le paramètre SSL Cipher Suite Order est Non configuré (ou inclut les suites ECDHE + AES‑GCM nécessaires).
Les clés SCHANNEL Client et Server affichent Enabled=1 et DisabledByDefault=0 pour TLS 1.2.
Les clés .NET Strong Crypto et SystemDefaultTlsVersions sont positionnées sur 64/32 bits.
Le certificat serveur est valide, avec clé privée accessible, et le type (RSA/ECDSA) correspond aux suites autorisées.
Les tests openssl s_client -tls1_2 montrent une suite commune négociée (idéalement en AES‑GCM).
La journalisation Schannel est revenue à son niveau normal après diagnostic.

Diagnostic pas à pas reproductible

Désactivez toute personnalisation de suites, redémarrez, retestez.
Activez Strong Crypto .NET, redémarrez le service applicatif, retestez.
Vérifiez le certificat serveur (chaîne et clé privée), corrigez les ACL si besoin.
Si 36871 persiste, recherchez les connexions sortantes qui utilisent TLS et vérifiez l’existence d’un certificat client et ses permissions.
Activez temporairement EventLogging=7 pour capturer le détail, puis restaurez.

Points clés à retenir

L’événement de serveur qui mentionne « aucune suite supportée » ne signifie pas que TLS 1.2 est coupé : c’est une intersection vide de suites.
L’événement de client naît souvent d’une application imposant de vieilles versions TLS ou d’un certificat client absent/inexploitable.
Revenir au défaut OS, puis durcir par paliers, est la méthode la plus rapide pour isoler la cause réelle.

Modèle de communication d’incident

Pour votre ticket interne :

Impact : erreurs Schannel 36871/36874 récurrentes, connexions TLS échouées vers/depuis des services ciblés.
Cause : absence de suites communes ou échec de création d’identifiants client (durcissement excessif, paramètres .NET, certificats/ACL, FIPS).
Action : remise au défaut OS des suites, activation TLS 1.2 sous SCHANNEL, forçage TLS modernes pour .NET, correctifs certificats/ACL, tests OpenSSL, journalisation temporaire Schannel.
Statut : erreurs disparues après redémarrage et validation de la négociation en AES‑GCM.

Annexe commandes à copier

:: TLS 1.2 côté client et serveur
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

\:: .NET Strong Crypto
reg add "HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG\_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319" /v SystemDefaultTlsVersions /t REG\_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG\_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319" /v SystemDefaultTlsVersions /t REG\_DWORD /d 1 /f

\:: Journalisation Schannel (temporaire)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" /v EventLogging /t REG\_DWORD /d 7 /f

Conclusion pratique

Traitez séparément rôle serveur (36874) et rôle client (36871). Revenez d’abord aux valeurs par défaut Windows pour les suites, confirmez TLS 1.2 dans SCHANNEL, débloquez .NET vers TLS modernes, puis vérifiez certificats et ACL. Redémarrez proprement, testez avec openssl s_client et, si besoin, journalisez Schannel le temps d’identifier l’élément fautif. Cette démarche résout la majorité des incidents constatés sur Windows Server 2022/2019 et supprime les boucles d’erreurs 36871/36874.

Erreurs Schannel 36871/36874 TLS sur Windows Server 2022/2019 : diagnostic, causes et correctifs rapides