Su Server recenti capita di vedere a raffica gli eventi Schannel 36871 (errore interno 10013/10010 nella creazione delle credenziali TLS lato client) e 36874 (handshake TLS rifiutato per assenza di una cipher suite comune). Qui trovi una guida pratica per diagnosticarli e risolverli in modo stabile.
Panoramica del problema
Gli eventi Schannel 36871 e 36874 compaiono spesso dopo hardening della sicurezza (disabilitazione di protocolli e cipher obsoleti) o subito dopo l’installazione di aggiornamenti cumulativi su Windows Server (in particolare edizioni datacenter/standard di Server recenti). Il risultato visibile è un flusso di errori nel registro System e, all’atto pratico, handshake TLS falliti da parte di alcune applicazioni o dispositivi legacy. La causa, nella stragrande maggioranza dei casi, è un mismatch tra ciò che il client propone e ciò che il server accetta (protocollo, cipher suite, curve ECC) oppure un certificato non valido o non utilizzabile dal servizio.
Cosa significano gli eventi Schannel
Evento 36871 – “A fatal error occurred while creating a TLS client credential. The internal error state is 10013/10010.” Indica che il provider crittografico di Windows (Schannel) non è riuscito a creare il contesto TLS lato client per il processo indicato (il PID è riportato nell’evento). Le cause tipiche: protocollo disabilitato, algoritmi non più disponibili, certificato client mancante/illeggibile, chiavi di registro incoerenti.
Evento 36874 – “An TLS connection request was received from a remote client application, but none of the cipher suites supported by the client are supported by the server.” Segnala che l’handshake arriva al server, ma non esiste una cipher suite in comune: per esempio il client propone solo RSA statico o 3DES/RC4, mentre il server accetta solo ECDHE con AES‑GCM. Il rifiuto avviene prima della negoziazione del certificato, quindi il servizio risulta “irraggiungibile” dal punto di vista di quel client.
Cause frequenti a colpo d’occhio
| Categoria | Descrizione | Segnali tipici |
|---|---|---|
| Cipher suite incompatibili | Il client propone algoritmi disabilitati sul server (p.es. solo RSA key exchange o AES‑CBC). | 36874 ripetuto su porte TLS pubbliche; test con openssl mostra no shared cipher. |
| Applicazioni legacy | App .NET, Java o agent di terze parti non forzano TLS moderno e tentano protocolli deboli. | 36871 con PID di servizi applicativi; handshake riuscito solo riabilitando TLS datati. |
| Certificato non valido o mancante | Cert scaduto, senza EKU adeguato o senza chiave privata; store errato; binding HTTP/LDAPS assente. | 36871 su processi che terminano TLS; errori di trust chain; fallback a self‑signed. |
| Registro o GPO incompleti | Protocolli abilitati solo “a metà” (chiavi Client/Server incoerenti, mancanza di reboot). | Comportamento aleatorio, differenze tra nodi, valori DisabledByDefault non allineati. |
Playbook operativo rapido
- Allinea le cipher suite
Verifica la lista lato server e assicurati che includa almeno una suite moderna accettata dai client (p.es. ECDHE con AES‑GCM e SHA‑256/384). Per ambienti HTTP.SYS/IIS usa la GPO SSL Configuration Settings o strumenti di hardening dedicati. Evita RC4, 3DES, MD5, cipher CBC quando possibile. - Abilita i protocolli moderni
Su tutte le macchine interessate (server, reverse proxy, client applicativi) conferma l’abilitazione di TLS 1.2 e, quando supportato dalla piattaforma, TLS 1.3. Ricorda che Windows Server più datati non implementano TLS 1.3; non forzarlo dove non esiste. - Forza la strong crypto nelle app .NET
Per processi che usano il CLR, abilita l’uso del default di sistema e di algoritmi robusti tramite le chiavi di Registro riportate in questo articolo. - Verifica i certificati
Controlla validità, catena di fiducia, EKU e presenza della chiave privata nello store corretto. Per servizi HTTP.SYS/LDAPS/WinRM verifica anche i binding. - Aggiorna componenti
Applica gli aggiornamenti cumulativi di Windows e aggiorna software/driver/agent che negoziano TLS in modo legacy. - Individua chi fallisce
Dagli eventi recupera il PID e mappa il processo. Se necessario, sniffer e strumenti a riga di comando ti diranno quali cipher/protocolli vengono proposti e rifiutati.
Verifica e gestione delle cipher suite
Windows espone l’elenco delle cipher suite disponibili e l’ordine di preferenza. Su edizioni recenti puoi ispezionarle da PowerShell:
Get-TlsCipherSuite |
Sort-Object -Property Name |
Format-Table Name, Exchange, Cipher, Hash, Protocols
Consiglio: assicurati di includere almeno queste famiglie (nomi in stile Windows) per compatibilità diffusa:
TLSECDHERSAWITHAES256GCM_SHA384TLSECDHERSAWITHAES128GCM_SHA256TLSECDHEECDSAWITHAES256GCM_SHA384(se usi certificati ECDSA)TLSECDHEECDSAWITHAES128GCM_SHA256(se usi certificati ECDSA)
Per ambienti con carichi misti RSA/ECDSA, mantieni entrambe le famiglie. Evita RSA statico (TLSRSA*) e AES‑CBC se non strettamente necessario per legacy.
Impostazione tramite Criteri di gruppo
Apri l’Editor criteri locali o un GPO di dominio e vai in Computer Configuration → Administrative Templates → Network → SSL Configuration Settings. Imposta SSL Cipher Suite Order in Enabled e specifica una lista di suite ordinate e separate da virgole. Dopo l’applicazione, riavvia i servizi che usano Schannel (talvolta è richiesto il reboot del server).
Confronto nomi Windows e IANA
Non farti ingannare dai nomi: Windows usa un formato leggermente diverso rispetto a IANA/OpenSSL. Questa tabella aiuta a riconoscere le suite più comuni:
| Nome Windows | Nome IANA/OpenSSL | Uso suggerito |
|---|---|---|
| TLSECDHERSAWITHAES128GCM_SHA256 | TLSECDHERSAAES128GCMSHA256 | Compatibilità ampia con buona sicurezza |
| TLSECDHERSAWITHAES256GCM_SHA384 | TLSECDHERSAAES256GCMSHA384 | Ottimo compromesso per server pubblici |
| TLSECDHEECDSAWITHAES128GCM_SHA256 | TLSECDHEECDSAAES128GCMSHA256 | Se usi certificati ECDSA |
| TLSECDHEECDSAWITHAES256GCM_SHA384 | TLSECDHEECDSAAES256GCMSHA384 | Se usi certificati ECDSA |
Abilitazione di TLS moderno con Registro
Perché le modifiche ai protocolli siano riconosciute da Schannel, Client e Server devono avere valori coerenti. Dopo le modifiche è necessario un riavvio.
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\TLS 1.2\Client Enabled=1 DisabledByDefault=0 (DWORD)
\TLS 1.2\Server Enabled=1 DisabledByDefault=0 (DWORD)
Se vuoi disabilitare vecchi protocolli (attenzione alla compatibilità):
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\TLS 1.0\Server Enabled=0 DisabledByDefault=1 (DWORD)
\TLS 1.1\Server Enabled=0 DisabledByDefault=1 (DWORD)
Nota di piattaforma: edizioni recenti supportano TLS 1.3; versioni più datate no. Non tentare di “forzare” TLS 1.3 su piattaforme prive del supporto nativo: non funzionerà e potresti introdurre inconsistenze.
Forzare la strong crypto per applicazioni .NET
Molte applicazioni .NET più vecchie si appoggiano alle versioni TLS impostate in fase di compilazione. Per allinearle allo stato dell’arte senza modificare il codice, imposta queste chiavi:
HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
SystemDefaultTlsVersions = 1 (DWORD)
SchUseStrongCrypto = 1 (DWORD)
Se hai applicazioni x86 o basate su CLR 2.0, replica i valori anche in v2.0.50727. Dopo l’impostazione, riavvia il servizio applicativo (o il server in caso di dubbi) e verifica con i test esterni descritti sotto.
Controllo dei certificati e dei binding
Un certificato non adeguato o privo di chiave privata scatena immancabilmente errori Schannel in fase di handshake. Ecco la check‑list essenziale:
- Store corretto: usa certlm.msc → Personal → Certificates (archivio macchina). Evita lo store utente per servizi che girano come Local System/Network Service.
- Chiave privata presente: il certificato deve mostrare “You have a private key that corresponds to this certificate”.
- EKU: include Server Authentication (OID 1.3.6.1.5.5.7.3.1) per i servizi server; Client Authentication quando richiesto.
- Catena di fiducia: CA intermedie e radice note al sistema. Importa eventuali CA interne nello store Intermediate/Trusted Root.
- Binding: per HTTP.SYS (IIS, WinRM, WCF) verifica i binding su hostname/porta/SNI.
Comandi utili:
# Elenco dei cert nello store macchina
Get-ChildItem Cert:\LocalMachine\My | Format-Table Subject, NotAfter, EnhancedKeyUsageList
Binding HTTP.SYS
netsh http show sslcert Aggiornamenti e compatibilità applicativa
Molti agent legacy (monitoring, backup, stampanti di rete, bilanciatori datati) parlano solo TLS deboli o cipher CBC. Se hai disabilitato TLS 1.0/1.1 per policy, assicurati che tutti i peer supportino almeno TLS 1.2. In caso contrario, l’handshake fallirà sempre. Aggiorna firmware, driver e versioni client (per esempio, Java 8 aggiornato, .NET Framework aggiornato, driver database recenti) per ottenere il supporto pieno a TLS 1.2 e cipher GCM.
Individuare rapidamente chi sta fallendo
Gli eventi Schannel includono il PID del processo. Mappalo a un servizio:
tasklist /svc | findstr <PID>
Oppure da PowerShell:
Get-Process -Id <PID> | Select-Object Id, ProcessName, Path
Per estrarre gli eventi utili:
# Ultimi eventi Schannel nel registro System
Get-WinEvent -FilterHashtable @{LogName='System'; Id=36871,36874} -MaxEvents 200 |
Select-Object TimeCreated, Id, Message |
Sort-Object TimeCreated -Descending
Test di handshake e negoziazione
Verifica sempre dall’esterno con strumenti di test. Alcuni esempi:
# Forza TLS 1.2 e prova una GCM moderna
openssl sclient -connect server.dominio:443 -servername server.dominio -tls12 -cipher 'ECDHE+AESGCM'
Mostra le cipher accettate da un server (elenco sintetico)
openssl ciphers -v 'ECDHE+AESGCM' | sort Con Wireshark, filtra i pacchetti con tls.handshake e guarda ClientHello/ServerHello. Se vedi Handshake Failure subito dopo il ClientHello, sei nel caso tipico del 36874.
Ruoli e servizi più comuni
Servizi web su HTTP.SYS/IIS
- Controlla SSL Cipher Suite Order su GPO.
- Verifica binding e SNI per ogni sito: certificato corretto, hostname giusto, porte coerenti.
- Se usi un reverse proxy o un WAF, allinea anche la terminazione TLS sul dispositivo.
WinRM e PowerShell remoting
- Verifica certificati di WinRM HTTPS e protocolli TLS abilitati.
- Test:
Test-NetConnection -ComputerName host -Port 5986.
RDP
- RDP può usare TLS per proteggere la sessione. Se hai una policy che impone solo TLS moderni, client antichi verranno rifiutati.
- Sostituisci il certificato RDP predefinito con uno valido emesso dalla tua CA.
LDAPS
- Controlla che i DC espongano certificati con EKU adatto e catena completa.
- Client legacy LDAP potrebbero richiedere aggiornamenti per parlare TLS 1.2.
SQL Server
- Versioni più datate e provider client antichi potrebbero non supportare TLS 1.2 senza aggiornamenti. Aggiorna Native Client/driver ODBC/ADO.
Casi particolari e insidie
- Policy FIPS: abilitarla senza necessità può rompere compatibilità con alcune implementazioni che non supportano tutte le modalità FIPS. Attivala solo se richiesto da compliance.
- Curve ECC: alcune appliance pretendono curve diverse da quelle di default. Su sistemi recenti puoi regolare l’ordine delle curve via policy dedicate; in pratica P‑256 e P‑384 coprono la maggior parte dei casi.
- Ordine delle suite: se imposti un elenco troppo restrittivo, alcuni client selezionano fallback infelici o falliscono. Mantieni almeno due‑tre opzioni GCM per famiglia.
- Bilanciatori/sonde: health check di load balancer mal configurati possono generare una valanga di 36874 se testano con cipher non più presenti.
- Requisiti ECDSA: se passi a certificati ECDSA per performance, fornisci anche variante RSA per i client che non supportano ECDSA; altrimenti vedrai 36874 dai client più vecchi.
Abilitare il logging utile
Per investigazioni complesse, puoi attivare un logging più verboso di Schannel:
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
EventLogging = 7 (DWORD)
In parallelo abilita CAPI2 in Applications and Services Logs → Microsoft → Windows → CAPI2 → Operational per tracciare problemi di catene di certificati. Ricordati di riportare il valore a default dopo la diagnosi per evitare log eccessivi.
Procedura completa passo‑passo
- Raccogli informazioni: estrai eventi 36871/36874, segna PID, porte e orari. Mappa i processi e identifica se l’errore viene generato in ingresso (server) o in uscita (client).
- Controlla protocolli: verifica Registro/GPO per TLS 1.2 abilitato (sia Client sia Server). Riavvia se hai cambiato valori.
- Esamina le cipher: Get‑TlsCipherSuite e GPO SSL Cipher Suite Order. Assicurati di avere ECDHE con AES‑GCM disponibili.
- Valida i certificati: store, EKU, catena, chiave privata, binding su porte/host. Sostituisci i certificati scaduti o non conformi.
- Hardening lato app: abilita SchUseStrongCrypto e SystemDefaultTlsVersions per .NET; aggiorna JRE/driver/agent per ottenere TLS 1.2 nativo.
- Test end‑to‑end: usa
openssl s_clientforzando TLS 1.2 e GCM; analizza con Wireshark se necessario. Conferma che almeno una suite venga negoziata. - Stabilizza la configurazione: distribuisci la policy tramite GPO, documenta l’ordine delle suite e pianifica un controllo periodico dopo gli aggiornamenti.
FAQ operative
Gli eventi compaiono ancora sporadicamente, è un problema?
Non sempre. Un 36874 occasionale di solito segnala tentativi da client obsoleti o scanner Internet che non trovano una suite comune. Se i tuoi servizi critici funzionano e i test esterni sono ok, è solo rumore di fondo.
Serve riavviare dopo ogni modifica?
Per i protocolli sì: Schannel legge le chiavi all’avvio del sistema. Per l’ordine delle cipher e i binding spesso basta riavviare il servizio interessato, ma un reboot garantisce la piena applicazione.
Posso “riaccendere” TLS obsoleti per compatibilità?
Meglio aggiornare i client. Se sei costretto, fallo in modo temporaneo, limitato e monitorato, e pianifica la migrazione. Mantieni separazione tra servizi esposti pubblicamente e interni.
Conviene passare a certificati ECDSA?
Sì per performance, ma tieni una variante RSA per massimizzare la compatibilità o usa dual‑stack certificati/binding.
Riepilogo pragmatico
Gli eventi 36871/36874 segnalano, nella quasi totalità dei casi, un problema di negoziazione: protocollo o cipher non allineati, oppure certificati non idonei. La soluzione pratica è:
- Abilitare e mantenere TLS moderno con impostazioni coerenti su client e server.
- Allineare le cipher suite a famiglie ECDHE con AES‑GCM, evitando algoritmi deboli.
- Forzare strong crypto nelle app legacy e aggiornare i componenti che parlano TLS.
- Verificare certificati e binding con attenzione a EKU e catena di fiducia.
- Diagnosticare con metodo usando PID dagli eventi, test
openssle, se serve, tracciamento con Wireshark e log Schannel/CAPI2.
Seguendo il playbook qui sopra, la maggior parte degli amministratori riesce a eliminare o ridurre drasticamente la comparsa degli errori Schannel su Windows Server, mantenendo un profilo di sicurezza moderno senza sacrificare la compatibilità dove davvero serve.
Appendice di riferimento
Registro per protocolli TLS
| Percorso | Valori | Note |
|---|---|---|
| HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client | Enabled=1, DisabledByDefault=0 | Riavvio richiesto |
| HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server | Enabled=1, DisabledByDefault=0 | Riavvio richiesto |
| HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server | Enabled=0, DisabledByDefault=1 | Disabilitazione consigliata se possibile |
| HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server | Enabled=0, DisabledByDefault=1 | Disabilitazione consigliata se possibile |
Registro per .NET strong crypto
| Percorso | Valori | Scopo |
|---|---|---|
| HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 | SystemDefaultTlsVersions=1; SchUseStrongCrypto=1 | Allinea l’app alle versioni TLS del sistema e alle cipher forti |
| HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319 | SystemDefaultTlsVersions=1; SchUseStrongCrypto=1 | Stesso per app x86 |
| HKLM\SOFTWARE\Microsoft\.NETFramework\v2.0.50727 | SystemDefaultTlsVersions=1; SchUseStrongCrypto=1 | Solo se presenti app CLR 2.0 |
Comandi rapidi di diagnosi
# Eventi Schannel
Get-WinEvent -FilterHashtable @{LogName='System'; Id=36871,36874} -MaxEvents 100 |
Select-Object TimeCreated, Id, Message
Processi e porte in ascolto
Get-NetTCPConnection -State Listen | Sort-Object LocalPort |
Format-Table LocalAddress, LocalPort, OwningProcess
Mappa PID <–> servizio
tasklist /svc | more Checklist finale prima di chiudere il ticket
- Almeno due cipher suite ECDHE con AES‑GCM abilitate e in cima all’ordine.
- TLS 1.2 abilitato a livello di sistema; TLS 1.3 usato dove supportato.
- .NET strong crypto forzata per i servizi applicativi legacy.
- Certificati validi, con chiave privata e binding corretti su tutte le porte TLS.
- Client e appliance aggiornati, test
opensslsuperati, nessun 36874 ripetuto dai peer legittimi. - Log Schannel riportato a livelli normali dopo la diagnosi.
Sintesi finale
Gli eventi 36871/36874 segnalano un mismatch di protocollo/cipher o un problema di certificato. Per risolvere: allinea le cipher suite richieste (o aggiorna i client), forza TLS moderno e la strong crypto nelle app legacy e verifica con cura i certificati. Questa procedura, nella pratica, elimina o riduce drasticamente gli errori Schannel in ambienti Windows Server.
Backup prima di ogni modifica al Registro, preferisci GPO per la distribuzione centralizzata, e documenta le variazioni. La sicurezza efficace è quella ripetibile.