Erreur TLS 10013 sous Windows 10/11 : SChannel/SSPI, causes, diagnostics et correctifs

Vous voyez l’erreur « A fatal error occurred while creating a TLS client credential. The internal error status is 10013 » sous Windows 10/11 ? Voici un guide complet, concret et vérifié pour diagnostiquer, corriger durablement et sécuriser votre configuration TLS (SChannel/SSPI).

Sommaire

Contexte et symptômes

Sur des postes Windows 10/11, le journal SChannel signale l’échec de création des informations d’identification client TLS (client credential) pour le processus SystemSettings.exe (l’application Paramètres). À la clé : certaines fonctions système ou apps qui utilisent TLS ne parviennent plus à établir de connexions HTTPS fiables (mise à jour, authentification, Microsoft Store, synchronisation de comptes, etc.).

Dans l’Observateur d’événements, vous verrez des entrées SChannel indiquant l’internal error status 10013. Cette valeur reflète un défaut lors de l’initialisation SSPI/SChannel : protocole TLS inactif, suites de chiffrement indisponibles, stratégie trop restrictive, inspection SSL ou composants endommagés.

Résumé des actions recommandées

Appliquez la séquence suivante : activer temporairement TLS 1.0/1.1 pour contourner le blocage initial, forcer l’activation de TLS 1.2 par le Registre, mettre à jour Windows, éliminer les blocages tiers, vérifier l’intégrité du système, puis contrôler vos stratégies et suites de chiffrement. Chaque étape est détaillée plus bas.

<div class="table-wrap">
  <table>
    <thead>
      <tr>
        <th>Étape</th>
        <th>Action</th>
        <th>Détails</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td><strong>1. Activer temporairement TLS 1.0/1.1</strong></td>
        <td><em>Options Internet → Avancé</em></td>
        <td>Cochez <strong>TLS 1.0</strong> et <strong>TLS 1.1</strong> → <strong>OK</strong> → redémarrez. À usage <strong>temporaire</strong> uniquement : ces protocoles sont obsolètes et moins sûrs.</td>
      </tr>
      <tr>
        <td><strong>2. Forcer TLS 1.2 via le Registre</strong></td>
        <td><code>HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols</code></td>
        <td>Créez <code>TLS 1.2\Client</code> → ajoutez <code>DisabledByDefault</code> (DWORD 32) = 0 et <code>Enabled</code> (DWORD 32) = 1 → redémarrez. Garantit l’usage de TLS 1.2 même si des stratégies désactivent d’autres versions.</td>
      </tr>
      <tr>
        <td><strong>3. Mettre à jour Windows et les pilotes</strong></td>
        <td>Windows Update</td>
        <td>Installez les dernières mises à jour cumulatives (SChannel/WinHTTP, liste de chiffrements) et les pilotes réseau. </td>
      </tr>
      <tr>
        <td><strong>4. Rechercher des blocages tiers</strong></td>
        <td>Antivirus, pare‑feu, VPN, proxy</td>
        <td>Désactivez temporairement l’inspection HTTPS, le filtrage TLS ou ajoutez une exclusion pour <code>SystemSettings.exe</code>. Testez sans VPN/proxy.</td>
      </tr>
      <tr>
        <td><strong>5. Contrôler l’intégrité système</strong></td>
        <td>Console administrateur</td>
        <td>Exécutez <code>sfc /scannow</code> puis <code>DISM /Online /Cleanup-Image /RestoreHealth</code> pour réparer SChannel/WinHTTP.</td>
      </tr>
      <tr>
        <td><strong>6. Vérifier Stratégie de groupe &amp; GPO</strong></td>
        <td><em>gpedit.msc</em></td>
        <td><em>Configuration ordinateur → Modèles d’administration → Réseau → Paramètres de configuration SSL</em> : assurez-vous que TLS 1.2 n’est pas bloqué et que l’ordre des suites de chiffrement n’exclut pas les suites modernes.</td>
      </tr>
    </tbody>
  </table>
</div>

Pourquoi cette erreur survient

Lorsqu’une application (ici SystemSettings.exe) veut se connecter en HTTPS, elle demande à SSPI/SChannel un contexte de sécurité client TLS. Si les protocoles autorisés ne recouvrent pas ceux requis par le serveur, si aucune cipher suite compatible n’est disponible, si une stratégie GPO interdit l’algorithme nécessaire, ou si un composant TLS est corrompu, SChannel échoue à produire le credential client et journalise l’error status 10013. Dans des environnements d’entreprise, un proxy d’inspection TLS peut également rompre la négociation.

Prérequis et bonnes pratiques

  • Ouvrez une session avec un compte administrateur local.
  • Créez un point de restauration système ou une sauvegarde du Registre.
  • Notez l’état initial des cases TLS dans Options Internet et des paramètres GPO éventuels.
  • Après chaque modification, redémarrez puis contrôlez Observateur d’événements → Journaux Windows → Système → SChannel pour confirmer la disparition des erreurs.

Démarche détaillée pas à pas

<h3>Activer temporairement TLS 1.0/1.1 pour rétablir l’accès</h3>
<ol>
  <li>Appuyez sur <kbd>Win</kbd> + <kbd>R</kbd>, saisissez <code>inetcpl.cpl</code> et validez.</li>
  <li>Onglet <strong>Avancé</strong> → section <strong>Sécurité</strong>.</li>
  <li>Cochez <strong>Utiliser TLS 1.0</strong> et <strong>Utiliser TLS 1.1</strong>. Conservez <strong>Utiliser TLS 1.2</strong> et, si présent sur Windows 11, <strong>Utiliser TLS 1.3</strong>.</li>
  <li><strong>OK</strong> puis redémarrez Windows.</li>
</ol>
<p><strong>Important</strong> : ne laissez pas TLS 1.0/1.1 actifs définitivement. Ils servent à rétablir temporairement une négociation compatible, le temps d’activer correctement TLS 1.2 (voire TLS 1.3) et de mettre à jour le poste.</p>

<h3>Forcer l’activation de TLS 1.2 côté client (Registre)</h3>
<p>Créez les clés et valeurs SChannel suivantes :</p>
<pre><code>Chemin : HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client

Valeur : DisabledByDefault (DWORD 32 bits) = 0 Valeur : Enabled (DWORD 32 bits) = 1

Vous pouvez automatiser via PowerShell (exécuter en tant qu’administrateur) :

New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' -Name 'TLS 1.2' -Force | Out-Null
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2' -Name 'Client' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'DisabledByDefault' -PropertyType DWord -Value 0 -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'Enabled' -PropertyType DWord -Value 1 -Force | Out-Null
Restart-Computer 

Après redémarrage, vérifiez si l’erreur 10013 a disparu. Si oui, repassez Options Internet en configuration durcie (désactivation de TLS 1.0/1.1, voir plus bas).

<h3>Mettre à jour Windows et les pilotes réseau</h3>
<ul>
  <li>Ouvrez <strong>Paramètres → Windows Update</strong> et installez toutes les mises à jour <em>qualité</em> et <em>sécurité</em>.</li>
  <li>Dans <em>Options avancées → Mises à jour facultatives</em>, installez les pilotes réseau proposés.</li>
  <li>Redémarrez et testez à nouveau l’ouverture des rubriques Paramètres (Comptes, Windows Update, Microsoft Store).</li>
</ul>

<h3>Écarter les blocages par antivirus, pare‑feu, VPN ou proxy</h3>
<p>De nombreux agents de sécurité proposent une inspection HTTPS (<em>SSL/TLS inspection</em>) ou un « web shield » qui intercepte le chiffrement. Pour diagnostiquer :</p>
<ul>
  <li>Désactivez temporairement l’inspection HTTPS (ou la fonction de filtrage web) de l’antivirus/pare‑feu.</li>
  <li>Si vous utilisez un VPN, déconnectez‑le et retestez.</li>
  <li>Retirez la configuration proxy système : invite administrateur → <code>netsh winhttp show proxy</code> puis <code>netsh winhttp reset proxy</code>.</li>
  <li>Ajoutez une exclusion pour <code>C:\Windows\ImmersiveControlPanel\SystemSettings.exe</code> si votre solution le permet.</li>
</ul>
<p>Si l’erreur disparaît aussitôt, ajustez la politique de l’outil en cause (désactivation durable de l’inspection sur les domaines Microsoft, certificats racine approuvés, etc.).</p>

<h3>Réparer les composants système liés à SChannel/WinHTTP</h3>
<p>Exécutez ces commandes dans une console <strong>Administrateur</strong> :</p>
<pre><code>sfc /scannow

DISM /Online /Cleanup-Image /RestoreHealth netsh winsock reset shutdown /r /t 0

sfc et DISM réparent les fichiers système et l’image Windows. winsock reset remet à zéro le catalogue Winsock (utile si un LSP défectueux intercepte TLS).

<h3>Contrôler les stratégies de groupe et l’ordre des suites de chiffrement</h3>
<ol>
  <li>Lancez <code>gpedit.msc</code>.</li>
  <li>Allez dans <em>Configuration ordinateur → Modèles d’administration → Réseau → Paramètres de configuration SSL</em>.</li>
  <li>Ouvrez <strong>Ordre des suites de chiffrement SSL</strong> :
    <ul>
      <li>Si paramètre <em>Non configuré</em> : Windows applique sa liste par défaut (recommandé).</li>
      <li>Si paramètre <em>Activé</em> : assurez‑vous que des suites TLS 1.2 modernes sont listées (par ex. ECDHE + AES‑GCM). Une liste trop restrictive peut déclencher 10013.</li>
    </ul>
  </li>
  <li>Appliquez les GPO : <code>gpupdate /force</code> puis redémarrez.</li>
</ol>
<p>Dans des domaines, exécutez <code>gpresult /h C:\gpresult.html</code> et ouvrez le rapport pour repérer les stratégies chiffrage/TLS imposées par l’AD.</p>

Vérifications complémentaires utiles

<h3>Valider la présence de suites de chiffrement modernes</h3>
<p>Sur Windows 10 1903+ et Windows 11, listez les suites disponibles :</p>
<pre><code>PowerShell

Get-TlsCipherSuite | Sort-Object Name | Select-Object Name

Si la commande échoue ou renvoie une liste anormalement courte, suspectez une GPO ou un durcissement local trop agressif.

<h3>Contrôler les versions TLS exposées par SChannel</h3>
<p>Outre TLS 1.2, Windows 11 prend en charge TLS 1.3. Vous n’avez pas besoin de modifier TLS 1.3 pour résoudre 10013, mais vérifiez que TLS 1.2 n’est pas neutralisé par une valeur résiduelle :</p>
Reg Query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client"


<h3>Vérifier le mode FIPS et autres restrictions</h3>
<p>Si la stratégie <em>« Système cryptographique : Utiliser des algorithmes conformes à FIPS »</em> est activée (<em>secpol.msc → Stratégies locales → Options de sécurité</em>), certaines applis échouent. Désactivez‑la à titre de test si elle n’est pas requise par votre conformité.</p>

<h3>Tester une négociation TLS depuis PowerShell</h3>
<p>Un test simple permet d’isoler un problème global (SChannel) d’un problème ciblé :</p>
<pre><code>PowerShell

# Remplacez l’URL par un service Microsoft (ex. page de compte) try { $r = Invoke-WebRequest -Uri « [https://www.microsoft.com](https://www.microsoft.com) » -UseBasicParsing -TimeoutSec 15 « HTTP status: $($r.StatusCode) » } catch { « Échec TLS/HTTP: $($_.Exception.Message) » }

<h3>Actualiser les certificats racine</h3>
<p>Le service <em>Services de chiffrement</em> doit être en démarrage automatique et en cours d’exécution. En cas de doute, vous pouvez purger le cache d’URL de certificats puis redémarrer :</p>
<pre><code>certutil -urlcache * delete

net stop cryptsvc & net start cryptsvc shutdown /r /t 0

Scénarios types et résolutions ciblées

Symptôme observéCause probableAction prioritaire
Paramètres → Comptes ne s’ouvre pas ou boucleProtocole TLS requis non disponibleActiver temporairement TLS 1.0/1.1 puis forcer TLS 1.2 (Registre). Mettre à jour Windows.
Microsoft Store/Windows Update renvoient des erreurs réseauInspection HTTPS du proxy/antivirusDésactiver l’inspection, exclure SystemSettings.exe, tester sans proxy/VPN.
Événements SChannel 10013 persistants malgré TLS 1.2Ordre de suites GPO trop restreintRemettre l’ordre des suites sur Non configuré ou y inclure ECDHE + AES‑GCM.
Échec avec plusieurs apps .NET mais pas avec Edge.NET ne cible pas les versions TLS systèmeActiver SystemDefaultTlsVersions et SchUseStrongCrypto (voir ci‑dessous).
Retour à la normale après winsock reset, puis rechuteComposant réseau tiers injecté (LSP)Désinstaller/réparer le logiciel qui réinstalle le LSP. Tenir les pilotes à jour.

Cas des applications .NET et paramètres supplémentaires

Si des applications .NET échouent en TLS (mais pas les composants Windows natifs), forcez l’usage des versions TLS par défaut du système et les chiffrements forts :

reg add "HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\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
reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f
    

Redémarrez les applications concernées et vérifiez l’absence de nouvelles erreurs SChannel.

Journalisation et validation après correctifs

  1. Ouvrez l’Observateur d’événements et filtrez le journal Système sur la source SChannel.
  2. Confirmez l’absence de nouveaux événements avec internal error status 10013 après vos changements.
  3. Exportez un lot de tests pour archivage : wevtutil epl System C:\Logs\system-evtx-export.evtx /q:"*[System[Provider[@Name='Schannel']]]"
  4. Testez les usages typiques : ouverture des pages Paramètres (Comptes, Windows Update, Confidentialité), ouverture de session Microsoft, recherche de mises à jour.

Durcissement final et remise au propre

Une fois le système stabilisé, revenez à une posture sécurisée :

  • Désactivez TLS 1.0/1.1 (sans toucher à TLS 1.2/1.3) :
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 1 /f
shutdown /r /t 0
    
  • Laissez l’ordre des suites de chiffrement à sa valeur par défaut (Non configuré) sauf exigence contraire ; Windows choisit automatiquement les suites les plus sûres disponibles.
  • Réactivez votre antivirus/pare‑feu mais sans inspection TLS sur les services Microsoft indispensables.

FAQ rapide

Pourquoi l’erreur ne concerne‑t‑elle que SystemSettings ?

SystemSettings.exe est l’application Paramètres et utilise WinHTTP/WinRT. Des politiques TLS trop strictes, un proxy interceptant ou des suites de chiffrement mal configurées affectent ces composants en premier, alors que les navigateurs modernes gèrent parfois autrement la négociation. Dois‑je activer TLS 1.3 pour régler 10013 ?

Non. La clé est d’avoir TLS 1.2 fonctionnel avec des suites de chiffrement modernes. TLS 1.3 peut coexister mais n’est pas requis pour supprimer 10013. Est‑il dangereux de modifier le Registre ?

Manipulez‑le avec précaution et créez un point de restauration. Les clés proposées ici sont limitées aux paramètres TLS du client SChannel. Que faire si 10013 persiste après toutes les étapes ?

Exportez/comparez les GPO, désinstallez tout logiciel d’inspection HTTPS, testez en mode sans échec avec prise en charge du réseau, et essayez un compte utilisateur neuf pour écarter un profil corrompu. Si le poste est joint à un domaine, vérifiez aussi les contrôleurs de domaine (stratégies TLS applicables à l’unité d’organisation).

Notes pratiques et retours du terrain

  • Chez certains, l’étape 2 seule (activation de TLS 1.2 via le Registre) ne suffit pas : combinez avec l’activation temporaire de TLS 1.0/1.1 (étape 1) et faites les mises à jour Windows (étape 3).
  • Sur des postes gérés, vérifiez que les GPO ne réappliquent pas une configuration TLS trop restrictive ou un ordre de suites incomplet.
  • Après chaque changement, consultez Observateur d’événements → SChannel pour vérifier la disparition des erreurs 10013.

Script d’automatisation « tout‑en‑un »

Ce script PowerShell applique les bonnes pratiques : active TLS 1.2 client, désactive TLS 1.0/1.1 après correctif, remet le proxy WinHTTP à zéro et lance une réparation système. Exécutez‑le en Administrateur ; commentez les lignes que vous ne souhaitez pas appliquer.

PowerShell
# 1) Activer TLS 1.2 côté client
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' -Name 'TLS 1.2' -Force | Out-Null
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2' -Name 'Client' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'DisabledByDefault' -PropertyType DWord -Value 0 -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'Enabled' -PropertyType DWord -Value 1 -Force | Out-Null

# 2) (Optionnel) Désactiver TLS 1.0/1.1 une fois la situation rétablie

foreach ($v in @('TLS 1.0','TLS 1.1')) {
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols$v" -Force | Out-Null
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols$v" -Name 'Client' -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols$v\Client" -Name 'Enabled' -PropertyType DWord -Value 0 -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols$v\Client" -Name 'DisabledByDefault' -PropertyType DWord -Value 1 -Force | Out-Null
}

# 3) Remettre le proxy WinHTTP à zéro

netsh winhttp reset proxy | Out-Null

# 4) Réparer composants système

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

Write-Host "Redémarrez la machine puis testez Paramètres et Windows Update." 

Conclusion

En procédant par étapes — contournement temporaire (TLS 1.0/1.1), activation explicite de TLS 1.2 via SChannel, mises à jour, élimination des intercepteurs TLS, réparation de l’image système puis contrôle des GPO — la majorité des cas d’erreur 10013 disparaissent. Finalisez par un durcissement : désactivez à nouveau TLS 1.0/1.1 et laissez Windows gérer automatiquement des suites modernes (ECDHE + AES‑GCM) pour une posture sécurisée et compatible.

Sommaire