Errore Schannel 36887 (TLS Alert 48) nella migrazione DC 2012 R2 → 2022: come verificarlo, quando ignorarlo e come risolvere su Windows Server 2022

Durante la migrazione di un DC 2012 R2 a 2022 può comparire ripetutamente l’evento Schannel 36887 (TLS Alert 48). In questa guida spiego cosa significa “unknown_ca”, le verifiche minime da effettuare, quando puoi ignorarlo e come risolvere definitivamente sul nuovo Domain Controller 2022.

Indice

Scenario

Un Domain Controller con Windows Server 2012 R2 sta per essere sostituito/affiancato da un nuovo DC con Windows Server 2022. Durante la finestra di migrazione, il vecchio server genera l’evento Schannel 36887 circa quattro volte al minuto, con testo analogo a “The TLS protocol defined fatal alert code 48”. L’amministratore si chiede se intervenire subito oppure procedere con la migrazione e gestire l’errore in un secondo momento.

Cos’è Schannel 36887 e cosa indica il TLS Alert 48

Schannel è il provider TLS/SSL di Windows. L’evento 36887 viene registrato quando il sistema riceve un “alert” dal peer remoto e la sessione TLS fallisce. Il valore “48” corrisponde all’alert unknown_ca: il peer remoto ritiene sconosciuta l’Autorità di Certificazione (CA) che ha emesso il certificato presentato nella negoziazione TLS.

Elemento	Significato
Event ID	36887 (Schannel)
TLS Alert	48 (`unknown_ca`)
Origine problema	Il peer remoto non si fida della CA che ha firmato il certificato usato nella sessione (ad es. LDAPS).
Impatto tipico	Sessione TLS interrotta; l’applicazione che tenta la connessione potrebbe ritentare, causando più eventi al minuto.

Perché si manifesta proprio durante la migrazione DC 2012 R2 → 2022

Certificati LDAPS non allineati: il vecchio DC 2012 R2 espone un certificato emesso da una CA (interna o esterna) che su alcuni client o sistemi non è presente nelle radici attendibili. Quei client scartano la connessione e inviano unknown_ca.
Catene di fiducia spezzate: certificati intermedi mancanti o scaduti in almeno uno dei lati della connessione (client ↔ server).
Mix di protocolli e criteri di sicurezza: in ambienti misti è frequente avere applicazioni legacy con store di trust incompleti o policy TLS restrittive sul lato nuovo/vecchio.
Transizione di ruoli: se si introduce un DC 2022 con certificati aggiornati e si lasciano in servizio agent e applicazioni che continuano a collegarsi al 2012 R2, possono emergere incongruenze nel trust anche solo temporanee.

Linea guida di base: intervenire o proseguire?

Soluzione indicata nel thread

Non toccare il vecchio ambiente a metà migrazione. Evita cambiamenti strutturali finché il nuovo DC 2022 non è operativo; gestisci gli eventuali errori Schannel direttamente lì.

Controlla la validità dei certificati in AD. Se la catena di fiducia è integra, l’alert può essere ignorato.

In altre parole: se non vi sono applicazioni che falliscono e la catena di fiducia dei certificati è in ordine, l’evento 36887/48 sul vecchio 2012 R2 è per lo più cosmetico e non blocca la migrazione. Porta a termine il passaggio al DC 2022 e, solo in caso di ricorrenza dell’errore nel nuovo ambiente, investi tempo nella risoluzione definitiva.

Approccio pratico (integrazione)

Comprendere l’alert 48 – unknown_ca. Il peer remoto non riconosce l’autorità che ha firmato il certificato presentato.
Verifiche rapide prima di ignorare:
- certlm.msc ► Trusted Root e Intermediate CA: assicurati che la CA interna/esterna sia presente.
- certutil –verify o pkiview.msc: controlla scadenza e revoca dei certificati LDAPS.
Se la catena è a posto e il server sarà dismesso: prosegui con la migrazione; l’errore è cosmetico.
Se l’errore riappare sul DC 2022:
- Importa le CA mancanti.
- Assicurati che LDAPS usi un certificato valido (Subject = FQDN del DC, EKU Server Authentication).
- Valuta l’abilitazione forzata di TLS 1.2/1.3 e la disattivazione dei protocolli deprecati via registro HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols.

Checklist di verifica rapida (5–10 minuti)

Controlla l’origine degli eventi
Event Viewer ► Applications and Services Logs > Microsoft > Windows > Schannel.
Conferma che l’ID sia 36887 e che l’alert sia 48.
Verifica lo store di fiducia
Avvia certlm.msc sul DC e verifica:
- Trusted Root Certification Authorities > Certificates: è presente la CA radice che ha emesso il certificato LDAPS?
- Intermediate Certification Authorities: sono presenti gli intermedi necessari?
Controlla il certificato LDAPS in uso
Personal > Certificates: identifica il certificato con Enhanced Key Usage “Server Authentication”, Subject (o SAN) uguale al FQDN del DC, non scaduto.
Valida la catena
Esporta il certificato e verifica con: certutil -verify "C:\Temp\dc-ldaps.cer" oppure usa pkiview.msc per lo stato di CA e CRL.
Testa LDAPS dal lato client
ldp.exe Connection > Connect... Server: <FQDN-DC> Port: 636 SSL: ✓ Se la connessione ha esito positivo e la catena risulta valida, puoi procedere con la migrazione.

Quando non ignorare l’alert 48

Applicazioni o servizi (es. IDM, SIEM, MDM, reverse proxy) registrano errori di connessione TLS verso il DC.
Gli eventi Schannel sono accompagnati da malfunzionamenti evidenti (autenticazioni fallite, query LDAP interrotte, errori ADFS o NPS).
Il certificato LDAPS è scaduto, privo dell’EKU richiesto o non mappa il FQDN corretto.

Requisiti minimi del certificato LDAPS sul Domain Controller

Requisito	Dettagli consigliati
Subject / SAN	FQDN del DC (es. `dc01.contoso.local`) nel Subject o nel Subject Alternative Name (SAN).
EKU	Server Authentication (OID `1.3.6.1.5.5.7.3.1`). In molti scenari è usata la template “Domain Controller Authentication”.
Key Usage	Tipicamente Digital Signature e Key Encipherment.
Lunghezza chiave	≥ 2048 bit.
Validità	Coerente con la policy interna; evita durate eccessive. Assicurati che CRL/OCSP siano raggiungibili.

Risoluzione definitiva se l’errore compare sul nuovo DC 2022

Importa le CA mancanti
Su certlm.msc importa la CA radice in Trusted Root e gli eventuali intermedi in Intermediate Certification Authorities. Valuta una GPO per distribuire le radici attendibili a tutti i server.
Rilascia un certificato LDAPS corretto
Usa la template adeguata (es. “Domain Controller Authentication” o “Kerberos Authentication”) assicurando EKU “Server Authentication”. Dopo l’emissione: # PowerShell: verifica certificato LDAPS attivo Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $.EnhancedKeyUsageList | Where-Object { $.FriendlyName -match 'Server Authentication' } } | Format-Table Subject, NotAfter, Thumbprint
Allinea i protocolli TLS
Windows Server 2022 supporta TLS 1.3 (oltre a 1.2). Valuta di disabilitare TLS 1.0/1.1 (previo inventario compatibilità) e di forzare 1.2/1.3. Esempio di chiavi di registro: 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 reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG\_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v DisabledByDefault /t REG\_DWORD /d 1 /f Nota: pianifica sempre la dismissione di TLS 1.0/1.1 dopo un assessment di compatibilità applicativa. Su Windows Server 2012 R2 TLS 1.3 non è disponibile; 1.2 deve essere attivato e preferito.
Ordina le cipher suite
In Local Group Policy Editor ► Computer Configuration > Administrative Templates > Network > SSL Configuration Settings definisci un ordine moderno di cipher suite. Evita suite con 3DES o RC4.
Verifica LDAPS e monitora
Ripeti i test con ldp.exe (porta 636) e con strumenti esterni. Controlla il registro eventi per eventuali 36887 ricorrenti dopo la messa in produzione del DC 2022.

Flusso decisionale: procedere o intervenire?

Condizione	Azione consigliata
Catena CA valida su DC 2012 R2; nessun errore applicativo	Procedi con la migrazione. Considera l’evento 36887/48 cosmetico sul server destinato alla dismissione.
Certificato LDAPS scaduto/errato su DC 2012 R2	Se possibile, rinnova rapidamente oppure sposta i carichi sul nuovo DC 2022 con certificato corretto.
Errore persiste sul DC 2022	Importa CA mancanti, riallinea TLS/cipher suite, rilascia certificato LDAPS conforme e ritesta.
Applicazioni business critiche falliscono	Intervieni subito: ripristina la fiducia della CA sul lato client che rifiuta il certificato (causa di `unknown_ca`).

Analisi degli eventi: cosa cercare nei log

Event ID 36887 (Schannel): ricevuto alert dal peer. Codice 48 = unknown_ca.
Event ID 36888: dettagli addizionali su eccezioni TLS lato Schannel.
Event ID 36874: mancata corrispondenza di cipher/protocolli (utile per distinguere problemi di suite da problemi di trust).

Correlare gli orari con i log dell’applicazione che tenta l’accesso (es. appliance che interroga LDAP) aiuta a identificare chi sta rifiutando il certificato.

Esempi di comandi utili

# Elencare i certificati server usati da Schannel (store LocalMachine\My)
Get-ChildItem Cert:\LocalMachine\My | Format-Table Subject, FriendlyName, NotAfter, EnhancedKeyUsageList

Verificare catena e CRL/OCSP

certutil -verify "C:\Temp\dc-ldaps.cer"

Test LDAPS da PowerShell (usa .NET SslStream)

\$client = New-Object System.Net.Sockets.TcpClient("dc01.contoso.local", 636)
\$ssl = New-Object System.Net.Security.SslStream(\$client.GetStream(), \$false, ({\$true}))
\$ssl.AuthenticateAsClient("dc01.contoso.local")

Abilitare TLS 1.2 lato server (2012 R2 e 2022)

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

Disabilitare TLS 1.0 lato server (testato e pianificato!)

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG\_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v DisabledByDefault /t REG\_DWORD /d 1 /f

Buone pratiche durante la migrazione dei Domain Controller

Niente modifiche invasive sul DC legacy: evita di cambiare template certificati, ordine cipher, protocolli o GPO critiche finché non hai un DC 2022 operativo e testato.
Distribuire le radici attendibili via GPO: garantisce uniformità su server e client, riducendo errori unknown_ca.
Inventario dei consumatori LDAPS: elenca chi si collega a 636/StartTLS 389 (applicazioni, apparati, integrazioni) e verifica il loro store di trust.
Preferire TLS 1.2/1.3: dove possibile, prepara la dismissione dei protocolli deprecati.
Monitoraggio proattivo: after cutover, tieni d’occhio il registro Schannel sul DC 2022 e gli errori applicativi correlati.

Esempio di piano operativo

Prima del cutover: verifica catene CA, rinnova il certificato LDAPS sul DC 2022, abilita TLS 1.2, prepara GPO per radici/intermedi.
Cutover: trasferisci i ruoli FSMO (se previsto), aggiorna i puntamenti LDAP/LDAPS dei servizi verso il nuovo DC.
Dopo il cutover: monitora Schannel, esegui test LDP.exe, esamina gli applicativi. Se 36887/48 scompare sul 2022, puoi ignorare gli eventi residui sul 2012 R2 fino alla sua rimozione.

Appendice: differenze di protocollo tra 2012 R2 e 2022

Windows Server 2012 R2: supporta nativamente TLS 1.2 (non TLS 1.3). Puoi disabilitare 1.0/1.1 solo dopo aver verificato la compatibilità di tutti i client/app.
Windows Server 2022: supporta TLS 1.3 (abilitato di default) e TLS 1.2. È la piattaforma ideale per consolidare policy moderne di cifratura e trust.

Appendice: come validare rapidamente la catena

Esporta il certificato server (Personal > Certificates).
Esegui: certutil -verify "C:\Temp\dc-ldaps.cer"
Controlla che ogni elemento della catena mostri “Verified” e che CRL/OCSP siano raggiungibili. Se mancano gli intermedi, importa i relativi certificati in Intermediate Certification Authorities.

FAQ

L’evento 36887/48 danneggia Active Directory?
No, non direttamente: indica solo il fallimento di alcune sessioni TLS. Diventa critico solo se incide su servizi che devono usare TLS (es. LDAPS per applicazioni esterne).

Posso disattivare i log Schannel per “ripulire” l’Event Viewer?
Sconsigliato durante la migrazione: perderesti segnali diagnostici utili. Eventuali ottimizzazioni del logging vanno fatte dopo la stabilizzazione.

È sempre necessario rigenerare i certificati?
No. Se il certificato è valido e la catena è corretta ma il client non possiede la radice/intermedio, l’azione corretta è distribuire le CA mancanti sul client che rifiuta la connessione.

Conclusioni

Il TLS Alert 48 (unknown_ca) all’interno dell’evento Schannel 36887 indica un problema di fiducia della CA, non necessariamente un difetto del DC. In piena migrazione, non alterare il vecchio ambiente: verifica rapidamente la catena, conferma che i servizi funzionano e prosegui verso Windows Server 2022. Se l’errore riappare sul nuovo DC, implementa in modo strutturato le azioni correttive: import delle CA mancanti, certificato LDAPS conforme, protocolli/cipher moderni. Così eviti interventi rischiosi sul 2012 R2 e consolidi la sicurezza nel nuovo dominio.

In sintesi
Finché i certificati risultano corretti e non vi sono applicazioni che falliscono le connessioni TLS, l’evento 36887/48 sul vecchio Server 2012 R2 non blocca la migrazione. Completa prima il passaggio a Windows Server 2022, poi valuta eventuali interventi se gli stessi errori compaiono sul nuovo ambiente.