Una connessione esistente è stata chiusa forzatamente dall'host remoto (errore del sistema operativo 10054)

Si applica a: SQL Server

Sommario

Questo articolo descrive gli scenari in cui si verifica l'errore di connettività SQL Server "Una connessione esistente è stata chiusa forzatamente dall'host remoto" e fornisce soluzioni. L'errore è associato a un handshake TLS non riuscito tra il client e SQL Server, spesso perché il client e il server non possono accettare una versione del protocollo TLS (ad esempio TLS 1.2 o TLS 1.3) o una suite di crittografia.

L'articolo illustra i messaggi di errore seguenti:

È stata stabilita una connessione con il server, ma si è verificato un errore durante il processo di accesso. (provider: provider SSL, errore: 0 - Una connessione esistente è stata chiusa forzatamente dall'host remoto.

La connessione con il server è stata stabilita correttamente, ma poi si è verificato un errore durante l'handshake pre-login. (provider: provider TCP, errore: 0 - Una connessione esistente è stata chiusa forzatamente dall'host remoto.

L'errore del sistema operativo 10054 viene generato nel livello socket di Windows. Per altre informazioni, vedere Codici di errore di Windows Sockets: WSAECONNRESET 10054.

Prima di iniziare la risoluzione dei problemi, controllare i prerequisiti ed esaminare l'elenco di controllo.

Quando si verifica questo errore

Secure Channel, noto anche come Schannel, è un provider di supporto per la sicurezza (SSP). Contiene un set di protocolli di sicurezza che forniscono l'autenticazione delle identità e la comunicazione privata sicura tramite la crittografia. Una funzione di SSP Schannel consiste nell'implementare versioni diverse del protocollo TLS (Transport Layer Security). TLS è uno standard di settore progettato per proteggere la privacy delle informazioni comunicate tramite Internet.

Il protocollo handshake TLS è responsabile dello scambio di chiavi necessario per stabilire o riprendere sessioni sicure tra due applicazioni che comunicano tramite TCP. Durante la fase di pre-accesso del processo di connessione, SQL Server e le applicazioni client usano il protocollo TLS per configurare un canale sicuro per la trasmissione delle credenziali.

Versioni di TLS a colpo d'occhio

La tabella seguente confronta le versioni di TLS che possono verificarsi durante la risoluzione di questo errore:

Versione Stato corrente in Windows Raccomandazione per SQL Server
TLS 1.0 / 1.1 Disabilitato per impostazione predefinita in Windows 11, Windows Server 2022 e versioni successive. Considerato non sicuro. Non usare. Aggiornare client e server a TLS 1.2 o versione successiva.
TLS 1.2 Abilitato per impostazione predefinita in tutte le versioni di Windows supportate. Ampiamente supportato da SQL Server e dai moderni driver client. Configurazione di base consigliata.
TLS 1.3 Supportato in Windows 11 e Windows Server 2022 e versioni successive. Supportato da SQL Server 2022 e versioni successive con i driver client correnti (ad esempio, Microsoft DRIVER ODBC 18 e Microsoft. Data.SqlClient 5.x). Usare dove sia il client che il server lo supportano.

Per lo stato di supporto corrente dei protocolli TLS in Windows, vedere Protocols in TLS/SSL (SSP Schannel).

Identificare quale scenario si applica nell'ambiente

Le sezioni seguenti descrivono diversi scenari che possono causare l'esito negativo dell'handshake. Se non si è certi di quale corrisponda all'ambiente, usare questi punti di partenza per restringerlo:

  • Acquisire una traccia di rete nel client e nel server durante una connessione non riuscita. Esaminare quindi i pacchetti Hello client e Server Hello per confermare la versione e la suite di crittografia TLS negoziata.
  • Controllare il log degli errori SQL Server per la voce successfully loaded for encryption per verificare quale certificato è in uso. Verificare l'algoritmo della relativa impronta digitale.
  • Confrontare le versioni e i pacchetti di crittografia TLS abilitati nel client e nel server usando Get-TlsCipherSuite e le chiavi del Registro di sistema in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
  • Verificare che il driver client supporti TLS 1.2 o versione successiva. I driver meno recenti, ad esempio SQL Server Native Client, sono deprecati e non sono consigliati.

Nessun protocollo TLS corrispondente tra client e server

Secure Sockets Layer (SSL) e versioni di TLS precedenti a TLS 1.2 presentano diverse vulnerabilità note. Nelle versioni Windows moderne (Windows 11, Windows Server 2022 e versioni successive), TLS 1.0 e TLS 1.1 sono disabilitati per impostazione predefinita. Gli amministratori spesso distribuiscono anche impostazioni dei Criteri di gruppo o del Registro per disabilitare questi protocolli più datati negli ambienti più datati.

Gli errori di connettività si verificano quando l'applicazione usa un driver ODBC (Open Database Connectivity) precedente, un provider OLE DB, .NET Framework o SQL Server versione che non supporta TLS 1.2 o versione successiva. Il problema si verifica perché il server e il client non riescono a trovare un protocollo corrispondente. Per completare l'handshake TLS è necessario un protocollo corrispondente.

Correzione della mancata corrispondenza del protocollo tra client e server

Per risolvere questo problema, usare uno dei metodi seguenti:

  • Aggiornare SQL Server o i provider client a una versione che supporta TLS 1.2 (e, ove possibile, TLS 1.3). Per altre informazioni, vedere Supporto di TLS 1.2 per Microsoft SQL Server.
  • Come soluzione alternativa a breve termine, chiedere agli amministratori di sistema di abilitare temporaneamente TLS 1.0 o TLS 1.1 sia nel client che nel server. Eseguire questa operazione solo fino a quando non è possibile aggiornare i componenti. Usare una delle azioni seguenti:

Esempio: versioni minime dei driver client per TLS 1.2

Usare i componenti client che supportano in modo nativo TLS 1.2 o versione successiva. I componenti seguenti sono baseline sicure comuni:

  • Microsoft ODBC Driver 17 o 18 per SQL Server.
  • Microsoft OLE DB Driver 18 o 19 per SQL Server.
  • .NET Framework 4.6.2 o versione successiva o qualsiasi versione supportata di .NET (.NET 6 e versioni successive).
  • Microsoft JDBC Driver 9.4 o versione successiva.

Il precedente SQL Server Native Client (SNAC) e il provider OLE DB per SQL Server incluso in Windows (SQLOLEDB) sono deprecati. Sostituirli con i componenti nell'elenco precedente.

Corrispondenza di protocolli TLS ma senza pacchetti di crittografia corrispondenti

Questo scenario si verifica quando l'utente o un amministratore limita determinati algoritmi nel client o nel server per una maggiore sicurezza.

È possibile esaminare le versioni tls client e server e i pacchetti di crittografia nei pacchetti Hello client e Server Hello in una traccia di rete. Il pacchetto Client Hello annuncia tutte le suite di crittografia client e il pacchetto Server Hello restituisce quello selezionato dal server. Se non sono presenti pacchetti corrispondenti, il server chiude la connessione anziché inviare un pacchetto Server Hello .

Correggi l'incompatibilità della suite di cifratura

Per controllare se si verifica il problema, seguire questa procedura:

  1. Se una traccia di rete non è disponibile, verificare il valore Functions sotto la chiave del Registro di sistema seguente: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002.

    Usare il comando di PowerShell seguente per elencare le suite di crittografia TLS configurate:

    Get-ItemPropertyValue -Path 'HKLM:\System\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\' -Name Functions

    In Windows 10, Windows 11, Windows Server 2016 e versioni successive, è anche possibile eseguire Get-TlsCipherSuite per elencare le suite abilitate in un formato più leggibile.

  2. Usare la scheda Pacchetti di crittografia nello strumento di crittografia IIS per verificare se sono presenti algoritmi corrispondenti. Se non vengono trovati algoritmi corrispondenti, contattare supporto tecnico Microsoft.

Per altre informazioni, vedere TLS 1.2 Upgrade Workflow e Transport Layer Security (TLS) connections might fail or timeout when connecting or attempting a resumption.

TLS_DHE pacchetti di crittografia abilitati in versioni Windows diverse

Questo problema può verificarsi quando il client e il server vengono eseguiti in versioni di Windows diverse (ad esempio, Windows Server 2012 e Windows Server 2016 o versioni successive) ed entrambi annunciano TLS_DHE_* suite di crittografia. Queste versioni di Windows gestiscono lo scambio di chiavi Diffie-Hellman all'interno di TLS in modo diverso, il che può causare il fallimento dell'handshake.

Rimuovere TLS_DHE suite di crittografia

Per risolvere questo problema, rimuovere tutte le suite di crittografia che iniziano con TLS_DHE_ dai criteri locali. Per altre informazioni sugli errori che si verificano quando le applicazioni tentano di connettersi a SQL Server in Windows, vedere Errori di connessione TLS chiusi forzatamente durante la connessione di SQL Server in Windows.

Il certificato di SQL Server usa un algoritmo hash debole

SQL Server crittografa sempre i pacchetti di rete correlati all'accesso. A questo scopo, utilizza un certificato sottoposto a provisioning manuale o un certificato autofirmato. Se SQL Server trova un certificato che supporta la funzione di autenticazione server nell'archivio certificati, usa tale certificato anche se non è stato effettuato manualmente il provisioning. Se il certificato usa un algoritmo hash debole (identificazione personale) come MD5, SHA224 o SHA512, non funziona con TLS 1.2 e genera l'errore.

Nota

I certificati autofirmati non sono interessati da questo problema.

Sostituire o riconfigurare i certificati con algoritmi hash deboli

Per risolvere il problema, seguire questa procedura:

  1. In Gestione configurazione SQL Server, espandere Configurazione di rete di SQL Server nel riquadro Console.

  2. Selezionare Protocolli per <il nome> dell'istanza.

  3. Selezionare la scheda Certificato e quindi eseguire una delle azioni seguenti:

    • Se viene visualizzato un certificato, selezionare Visualizza per controllare l'algoritmo di identificazione personale e verificare se usa un algoritmo hash debole. Selezionare quindi Cancella e andare al passaggio 4.

    • Se non viene visualizzato alcun certificato, esaminare il log degli errori di SQL Server per una voce simile alla seguente e prendere nota del valore hash o dell'impronta digitale:

      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"] was successfully loaded for encryption

  4. Rimuovere l'autenticazione server dal certificato:

    1. Selezionare Start>Run e immettere MMC (Microsoft Management Console).
    2. In MMC aggiungere lo snap-in Certificati e selezionare Account computer.
    3. Espandi Personale>Certificati.
    4. Individuare il certificato utilizzato da SQL Server per nome o per impronta digitale e aprirne il riquadro Proprietà.
    5. Nella scheda Generale selezionare Abilita solo gli scopi seguenti e deselezionare Autenticazione server.

  5. Riavviare il servizio SQL Server.

TLS_DHE correzione zero iniziale non installata

Questo scenario si verifica quando il client e il server negoziano una suite di crittografia TLS_DHE_* per l'handshake TLS, ma un lato non dispone dell'aggiornamento Windows che aggiunge la correzione iniziale zero per lo scambio di chiavi Diffie-Hellman. Per ulteriori informazioni su questo scenario, vedere Le applicazioni riscontrano errori relativi alla chiusura forzata della connessione TLS durante la connessione a SQL Server in Windows.

Nota

Se questo articolo non risolve il problema, verificare se gli articoli comuni relativi ai problemi di connettività possono essere utili.

Timeout dell'handshake a tre vie TCP dalla carenza di lavoratori IOCP

Nei sistemi con carichi di lavoro elevati in cui è in esecuzione SQL Server 2017 o versioni precedenti, si potrebbero verificare errori 10054 intermittenti causati da errori del three-way handshake TCP, che portano al rifiuto delle connessioni TCP. La causa radice è spesso un ritardo nell'elaborazione TCPAcceptEx delle richieste. Il ritardo può essere causato da una carenza di thread di lavoro del listener Input/Output Completion Port (IOCP), che si occupano di accettare le connessioni in ingresso. Quando i thread di lavoro IOCP sono in numero insufficiente o sono impegnati a gestire altre richieste, le richieste di connessione vengono elaborate in ritardo, causando errori durante l'handshake e rifiuti TCP. È anche possibile che vengano visualizzati timeout di accesso durante l'handshake SSL o durante l'elaborazione delle richieste di accesso, che comportano controlli di autenticazione.

Attenuare la carenza di lavoratori IOCP e i timeout di handshake

La causa principale di questi timeout dell'handshake TCP a tre vie e dei timeout di accesso è una carenza di worker IOCP e di risorse SOS Worker assegnate alle operazioni di autenticazione e crittografia. SQL Server 2019 e versioni successive includono diversi miglioramenti delle prestazioni in questo settore. Un miglioramento significativo è un pool dedicato di gestori del login, che ottimizza l'allocazione delle risorse per le operazioni di accesso. Questa modifica riduce i timeout e migliora le prestazioni complessive del sistema. Se si è interessati da questo problema, pianificare un aggiornamento a una versione di SQL Server attualmente supportata.

Altri scenari di errore di connessione TLS

Se il messaggio di errore riscontrato non corrisponde ad alcuno degli scenari precedenti, fare riferimento agli scenari aggiuntivi seguenti:

Contenuti correlati

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

  • Last updated on