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.
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
opkiview.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
Avviacertlm.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 usapkiview.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
Sucertlm.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 conldp.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.