Erreur Schannel 36887 (TLS 48 unknown_ca) sur DC 2012 R2 en migration vers 2022 : diagnostic & corrections

Pendant une migration vers Windows Server 2022, votre contrôleur de domaine 2012 R2 spamme l’événement Schannel 36887 (TLS alert 48). Voici comment comprendre ce signal, décider s’il faut agir avant la bascule, et corriger proprement sans casser la production.

Sommaire

Vue d’ensemble de la question

Sur un domaine en migration, il n’est pas rare de voir un ancien DC Windows Server 2012 R2 consigner des événements Schannel 36887 “A fatal alert was received from the remote endpoint” avec code d’alerte TLS 48. Ce code se traduit par unknown_ca : le poste distant coupe la poignée de main TLS, car il ne reconnaît pas l’autorité qui a signé le certificat présenté (le certificat serveur du DC pour LDAPS/RDP/ADWS/WinRM dans la plupart des cas, ou un certificat client si une authentification mutuelle est exigée).

La question clé en contexte de migration est double : faut‑il corriger maintenant ou peut‑on ignorer jusqu’au décommissionnement du 2012 R2 ? Et si l’on doit intervenir, quelle démarche minimale et sûre adopter pour éliminer l’erreur au bon endroit ?

Ce que signifie « TLS alert 48 – unknown_ca »

unknown_ca signifie que la chaîne de certification que présente votre DC (certificat serveur + intermédiaires + racine) n’est pas approuvée par le client qui s’y connecte. Le protocole TLS arrête immédiatement la négociation, avant toute authentification applicative : aucune requête LDAP, aucun échange RDP chiffré ne démarre.

Les déclencheurs typiques :

LDAPS sur TCP 636 depuis des scanners, outils de conformité, équipements réseau, scripts d’inventaire ou appliances qui ne font pas confiance à votre AC d’entreprise ;
RDP (TCP 3389) quand le serveur présente un certificat autogénéré non reconnu par les clients non joint au domaine ;
WinRM HTTPS (TCP 5986) ou AD Web Services (TCP 9389) mal provisionnés côté certificats ;
Cas plus rares : services qui exigent un certificat client et rejettent un client dont la chaîne n’est pas approuvée (mTLS).

Faut‑il corriger avant la migration ?

Stratégie pragmatique pour un environnement en route vers 2022 :

Si vous n’observez aucun impact fonctionnel (pas d’échec LDAPS, pas de plainte RDP, pas d’alerte applicative) et que la fréquence “quelques fois par minute” rappelle un scanner/sonde : poursuivez la migration, surveillez sur les nouveaux DC, tolérez les alertes sur l’ancien jusqu’à sa mise hors service.
Si impact avéré (connexions LDAPS échouées, avertissements NLA côté RDP, supervision rouge) : corrigez dès maintenant la confiance de la chaîne et/ou le certificat présenté.
Après l’introduction des DC 2022, si l’événement n’apparaît plus sur eux, décommissionnez le 2012 R2 sans intervention supplémentaire. S’il persiste sur 2022, traitez‑le sur la nouvelle plateforme.

Arbre de décision express

Pas d’impact ? Continuez la migration → surveillez sur 2022 → si RAS, décommissionnez 2012 R2.
Impact présent ? Identifiez l’IP/source → validez le certificat du DC → corrigez la chaîne/nom/EKU → retestez.

Indicateurs pour trancher

Symptôme	Lecture probable	Action recommandée
Événements 36887 réguliers, aucune plainte utilisateur	Sonde, scanner, appliance hors domaine	Tolérer pendant la migration, filtrer ou ajouter la racine AC côté sonde
Échecs de liaison LDAP/LDAPS d’applis	Chaîne incomplète ou nom du certificat non concordant	Réémettre le certificat DC, corriger SAN/CN, publier les intermédiaires
Avertissement NLA/“identité non vérifiée” en RDP	Certificat RDP non approuvé (autogénéré)	Déployer un certificat RDP d’entreprise via GPO
Une seule IP spamme en continu	Outil unique (SIEM/IDS/Load balancer)	Ajouter la racine AC sur l’équipement ou filtrer ses checks

Checklist d’investigation ciblée

1) Identifier la source et le service concernés

Votre priorité est de connaître l’IP distante et le port visé.

Journal Sécurité (Event ID 5156) : Activez l’audit des connexions de la Plateforme de filtrage :

auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable

Puis filtrez sur le DC : Process Name (par ex. lsass.exe pour LDAPS, svchost.exe pour ADWS/WinRM, TermService pour RDP), Destination Port (636, 3389, 5986, 9389), et récupérez l’adresse source.

Journalisation du pare‑feu : dans “Pare‑feu Windows avec fonctions avancées” → Propriétés du pare‑feu → Profil(s) actif(s) → Journalisation, activez “Connexions autorisées” et “Connexions refusées”.
Sysmon (si déployé) : Event ID 3 (NetworkConnect) donne l’IP/port/process.
Capture ETW rapide :

netsh trace start scenario=NetConnection capture=yes report=yes
REM Reproduisez l'alerte pendant ~1 minute
netsh trace stop

Ouvrez l’ETL dans Wireshark et filtrez tls.alert_message ou localisez les tentatives sur les ports concernés pour l’IP source.

2) Cartographier les services du DC susceptibles d’émettre Schannel

Service/protocole	Port	Certificat attendu	Test rapide
LDAPS (LDAP sur TLS)	636/TCP	Template “Domain Controller / Kerberos Authentication”, EKU “Server Authentication”, SAN = FQDN du DC	`ldp.exe` → Connexion SSL sur le FQDN ; ou `openssl s_client -connect dc01:636 -showcerts`
RDP (NLA/TLS)	3389/TCP	Certificat serveur approuvé avec EKU “Server Authentication” et SAN = FQDN	Client RDP : vérifier l’identité proposée ; `Test-NetConnection -ComputerName dc01 -Port 3389`
WinRM HTTPS	5986/TCP	Certificat avec EKU “Server Authentication”, Hostname = FQDN lié à WinRM	`Test-WSMan dc01 -UseSSL`
AD Web Services	9389/TCP	Certificat serveur valide (choisi par le service)	`Test-NetConnection -ComputerName dc01 -Port 9389` puis inspection TLS en capture

3) Vérifier le certificat présenté par le DC

Sur le DC : MMC “Certificats (ordinateur local)” → Personnel > Certificats. Contrôlez :

Présence de la clé privée ;
Date de validité ;
EKU : “Server Authentication” au minimum (et “Client Authentication”/“KDC Authentication” pour les templates DC modernes) ;
SAN : dNSName = FQDN du DC (ex. dc01.contoso.local). Évitez d’utiliser un alias/CNAME non listé.

Liste rapide en PowerShell :

Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.EnhancedKeyUsageList -match 'Server Authentication' } |
  Select-Object Subject, NotAfter, Thumbprint, @{n='DNS';e={$_.DnsNameList}} |
  Format-List

Vérifiez également la Chaîne : le certificat intermédiaire doit être envoyé par le DC pendant la poignée de main TLS. Si ce n’est pas le cas, réémettez avec le bon AIA/intermédiaire ou installez l’intermédiaire dans “Intermediate Certification Authorities”.

4) Cas particuliers à connaître

Clients externes/non joints au domaine : ils n’ont pas la racine de votre AC d’entreprise. Solution : ajouter votre racine à leur magasin de confiance ou exclure ces checks.
Alias DNS (CNAME) : si des applis se connectent à ldap.contoso.local mais le certificat ne contient que dc01.contoso.local, les clients rigoureux échoueront. Ajoutez l’alias au SAN ou faites‑les pointer sur le FQDN du DC.
Certificat RDP autogénéré : tolérable pour du dépannage, mais déployez un certificat fiable via GPO pour éliminer les alertes et l’avertissement NLA.
mTLS : si un service exige un certificat client, une alerte 48 peut venir d’un client dont la chaîne client est inconnue du DC. Ajoutez sa racine dans “Trusted Root Certification Authorities” (magasin machine) ou assouplissez la policy du service.

Correction sûre pendant la migration

Valider la pile TLS sans durcissement agressif

Laissez TLS 1.2 activé sur 2012 R2. N’introduisez pas de changements profonds de suites cryptographiques avant d’avoir basculé la charge sur 2022.
Si vous aviez durci 2012 R2 (désactivation de TLS 1.0/1.1, ciphers), documentez et alignez ces paramètres sur 2022 avant de décommissionner pour éviter les surprises côté clients anciens.

Réparer LDAPS de façon standard

Réémettre un certificat DC depuis votre AC : utilisez un template Domain Controller / Kerberos Authentication incluant “Server Authentication”.
Assurez l’inclusion du SAN = FQDN et, si nécessaire, des alias réellement utilisés.
Auto‑enrôlement via GPO : Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies de clé publique > Certificate Services Client – Auto‑Enrollment = Activé.
Forcez l’enrôlement : gpupdate /force puis certutil -pulse ou MMC > Personnel > Toutes les tâches > Demander un nouveau certificat.
Test : ldp.exe → FQDN → SSL (636). Contrôlez l’émetteur, le sujet et la chaîne présentée.

Déployer un certificat RDP approuvé

Créez/Publiez un template dédié (ex. “RDP Authentication”) dérivé d’un modèle ordinateur, EKU = “Server Authentication”, sujet ≙ nom du DNS de l’ordinateur.
GPO : Configuration ordinateur > Modèles d’administration > Composants Windows > Services Bureau à distance > Hôte de session > Sécurité → “Modèle de certificat d’authentification du serveur” = nom du template. Activez l’auto‑enrôlement.
Redémarrez le service TermService ou la machine. Le certificat sera automatiquement choisi et présenté aux clients RDP.

Remettre WinRM/ADWS d’équerre

Pour WinRM HTTPS :

# Créer un écouteur HTTPS en liant le certificat au FQDN
$thumb = 'VOTRE_THUMBPRINT_SANS_ESPACES'
winrm delete winrm/config/Listener?Address=*+Transport=HTTPS
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname='dc01.contoso.local'; CertificateThumbprint='$thumb'}
Test-WSMan dc01.contoso.local -UseSSL

Pour ADWS, vérifiez que le certificat serveur valide est bien disponible dans le magasin LocalMachine\My et que la chaîne est complète ; redémarrez le service si nécessaire.

Assurer la confiance côté clients et outils

Déployez la racine AC (et les intermédiaires) dans “Trusted Root Certification Authorities” des machines qui se connectent (GPO, MDM, configuration de l’appliance). C’est la cause n°1 des unknown_ca sur des scanners/IDS.
Vérifiez la publication AIA/CRL (chemins HTTP/LDAP atteignables). Même si l’alerte 48 vise la confiance et non la révocation, une chaîne bancale perturbe des piles TLS qui valident les intermédiaires.

Comment trouver et faire taire les “fausses alertes”

Il est fréquent que l’origine soit un scanner interne ou un load balancer qui teste 3389/636 à cadence fixe. Deux voies :

Ajouter la racine AC de l’entreprise dans l’équipement : corrige à la source, sans toucher aux DC.
Filtrer ces tentatives vers les DC (pare‑feu, règles IPS) si la confiance ne peut pas être changée, et documenter l’exclusion dans la politique de scans.

Surveillance et vérifications post‑migration

Avant bascule : établissez une ligne de base (comptage des 36887 par heure).

# Exemple de comptage journalier sur 7 jours
$since = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'; Id=36887; StartTime=$since} |
  Group-Object { $_.TimeCreated.ToString('yyyy-MM-dd HH') } |
  Sort-Object Name |
  Select-Object Name, Count

Après introduction d’un DC 2022 : répétez la mesure sur le nouveau DC. Si la courbe retombe à zéro ou à un bruit résiduel inoffensif, poursuivez le décommissionnement du 2012 R2.
Si l’erreur persiste sur 2022 : reprenez la checklist (source → certificat → chaîne → confiance).

FAQ pratique

Est‑ce une vulnérabilité ? Non, c’est un refus de communication TLS par un client non confiant. Cela n’expose pas le DC ; c’est bruyant, pas dangereux en soi.

Puis‑je “désactiver” Schannel 36887 ? Vous pouvez réduire la verbosité (HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging), mais c’est déconseillé : vous perdriez un signal utile en cas de vrai incident de confiance.

Un mauvais jeu de suites TLS peut‑il causer 48 ? Les incompatibilités de suites/protocoles mènent plutôt à des échecs de négociation différents. L’alerte 48 cible la confiance de la chaîne.

Un certificat expiré donne‑t‑il 48 ? Certains clients répondent par d’autres alertes (ex. certificate_expired), mais d’autres piles renverront 48 si la chaîne est jugée invalide. Quoi qu’il arrive, répétez : date ok, nom ok, EKU ok, chaîne ok.

Runbook express (copier‑coller)

Décider : pas d’impact ? → ignorer pendant la migration ; impact ? → corriger.
Trouver l’IP source : activez 5156,/ou Sysmon,/ou netsh trace ; notez IP/port/service.
Contrôler le certificat du DC : EKU “Server Authentication”, SAN = FQDN, dates OK, chaîne complète.
LDAPS : réémettre le certificat template DC, auto‑enrôlement GPO, test ldp.exe.
RDP : déployer un certificat via GPO “Modèle de certificat d’authentification du serveur”.
WinRM/ADWS : lier explicitement le certificat au FQDN, test Test-WSMan -UseSSL.
Côté client/équipement : pousser la racine AC ; sinon, filtrer les checks vers 3389/636/9389/5986.
Surveiller : compter les 36887 avant/après ; documenter et clôturer.

Bonnes pratiques pour la phase 2022

Modèles de certificats homogènes (DC, RDP) et auto‑enrôlement appliqués aux OU des nouveaux DC.
Contrôle des noms : standardisez l’usage du FQDN des DC dans les applis ; évitez les alias non inscrits dans le SAN.
Hygiène de chaîne : vérifiez la disponibilité AIA/CRL et la présence des intermédiaires sur tous les DC.
Compabilité TLS : ciblez TLS 1.2 partout ; planifiez l’élimination des clients hérités avant de durcir plus loin.

Exemples de vérifications et commandes utiles

Inspecter les événements Schannel récents

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'; Id=36887; StartTime=(Get-Date).AddHours(-6)} |
  Select-Object TimeCreated, Message |
  Format-List

Voir les connexions autorisées (Event 5156) vers 636/3389

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5156; StartTime=(Get-Date).AddHours(-2)} |
  Where-Object { $_.Message -match 'Destination Port:\s+(636|3389|5986|9389)' } |
  Select-Object TimeCreated, Id, Message

Tester LDAPS avec OpenSSL depuis un poste d’admin

openssl s_client -connect dc01.contoso.local:636 -servername dc01.contoso.local -showcerts

Afficher les EKU/SAN d’un certificat précis

$t = 'THUMBPRINT_SANS_ESPACES'
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object Thumbprint -eq $t
$cert | Format-List Subject, Issuer, NotAfter, EnhancedKeyUsageList, DnsNameList

Conclusion

L’alerte Schannel 36887 / TLS 48 (unknown_ca) signale un manque de confiance côté client, pas un défaut intrinsèque du DC. En période de migration, la meilleure approche est opérationnelle : ne modifiez pas l’ancien 2012 R2 s’il n’y a pas d’impact, concentrez‑vous sur des DC 2022 propres (certificats conformes, chaîne publiée, confiance déployée). Si un impact est constaté, appliquez la checklist : identifiez la source, validez le certificat et la chaîne, corrigez le nom/EKU, ou ajoutez la racine côté client. Une fois la bascule effectuée, ne traitez que les alertes persistantes sur 2022 ; laissez l’ancien DC partir en silence.

Résumé opérationnel : Pas d’impact => continuez la migration ; Impact => corrigez la confiance du certificat (chaîne, EKU, RDP/LDAPS), identifiez la source et ajustez ou filtrez ; Après migration : n’agissez que sur 2022 si l’erreur persiste.