Condividi tramite

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

  • Articolo

Si applica a: SQL Server

Note

Prima di iniziare la risoluzione dei problemi, è consigliabile controllare i prerequisiti e verificare l'elenco di controllo.

Questo articolo illustra in dettaglio vari scenari e offre soluzioni per gli errori 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.

Quando viene visualizzato l'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). Questo protocollo è uno standard di settore progettato per proteggere la privacy delle informazioni comunicate tramite Internet.

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

Gli scenari seguenti illustrano in dettaglio gli errori che si verificano quando non è possibile completare l'handshake:

Scenario 1: non esistono protocolli TLS corrispondenti tra il client e il server

Secure Socket Layer (SSL) e versioni di TLS precedenti a TLS 1.2 presentano diverse vulnerabilità note. È consigliabile eseguire l'aggiornamento a TLS 1.2 e disabilitare le versioni precedenti laddove possibile. Di conseguenza, gli amministratori di sistema potrebbero eseguire il push degli aggiornamenti tramite criteri di gruppo o altri meccanismi per disabilitare queste versioni TLS non sicure in vari computer all'interno dell'ambiente.

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

Risoluzione

Per risolvere questo problema, scegliere una delle alternative seguenti:

  • Aggiornare SQL Server o i provider client a una versione che supporta TLS 1.2. Per altre informazioni, vedere Supporto di TLS 1.2 per Microsoft SQL Server.
  • Chiedere agli amministratori di sistema di abilitare temporaneamente TLS 1.0 o TLS 1.1 sia nel client che nei computer server eseguendo una delle azioni seguenti:

Scenario 2: corrispondenza di protocolli TLS nel client e nel server, ma non pacchetti di crittografia TLS corrispondenti

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

Le versioni TLS client e server, i pacchetti di crittografia possono essere facilmente esaminati nei pacchetti Hello client e Server Hello in una traccia di rete. Il pacchetto Client Hello annuncia tutti i pacchetti di crittografia client, mentre il pacchetto Server Hello specifica uno di essi. Se non sono presenti pacchetti corrispondenti, il server chiude la connessione anziché rispondere al pacchetto Server Hello .

Risoluzione

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

  1. Se una traccia di rete non è disponibile, controllare il valore delle funzioni in questa chiave del Registro di sistema: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

    Usare il comando di PowerShell seguente per trovare le funzioni TLS.

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

  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 and Transport Layer Security (TLS) connections might fail or timeout when connecting or attempting a resumption.

Scenario 3: Le crittografie TLS_DHE potrebbero essere abilitate

Questo problema si verifica quando il client o il server è ospitato in Windows 2012, 2016 e versioni successive. Nonostante entrambe le versioni del sistema operativo dispongano della stessa crittografia (TLS_DHE*), Windows 2012 e 2016+ gestiscono le chiavi di crittografia all'interno di TLS in modo diverso. Ciò può causare errori di comunicazione.

Risoluzione

Per risolvere questo problema, rimuovere tutte le crittografie a partire da "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.

Scenario 4: SQL Server usa un certificato firmato da un algoritmo hash debole, ad esempio MD5, SHA224 o SHA512

SQL Server crittografa sempre i pacchetti di rete correlati all'accesso. A questo scopo, usa un certificato con provisioning manuale o un certificato autofirmato. Se SQL Server trova un certificato che supporta la funzione di autenticazione server nell'archivio certificati, usa il certificato. SQL Server usa questo certificato anche se non è stato effettuato il provisioning manuale. Se questi certificati usano un algoritmo weak-hash (algoritmo di identificazione personale), ad esempio MD5, SHA224 o SHA512, non funzioneranno con TLS 1.2 e causeranno l'errore indicato in precedenza.

Note

I certificati autofirmati non sono interessati da questo problema.

Risoluzione

Per ovviare a questo problema, esegui la procedura seguente:

  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 seguire il passaggio pertinente:
    • Se viene visualizzato un certificato, selezionare Visualizza per esaminare l'algoritmo identificazione personale per verificare se usa un algoritmo hash debole. Selezionare quindi Cancella e andare al passaggio 4.
    • Se non viene visualizzato un certificato, esaminare il log degli errori di SQL Server per una voce simile alla seguente e annotare il valore hash o identificazione personale:
      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption
  4. Per rimuovere l'autenticazione server, seguire questa procedura:
    1. Selezionare Avvia>Esegui e digitare MMC. MMC noto anche come Microsoft Management Console.
    2. In MMC aprire i certificati e selezionare Account computer nella schermata di snap-in Certificati .
    3. Espandere Personale>Certificati.
    4. Individuare il certificato usato da SQL Server in base al nome o esaminando il valore identificazione personale di certificati diversi nell'archivio certificati e aprire il relativo riquadro Proprietà .
    5. Nella scheda Generale selezionare Abilita solo i seguenti scopi e deselezionare Autenticazione server.
  5. Riavviare il servizio SQL Server.

Scenario 5: il client e il server usano TLS_DHE suite di crittografia per l'handshake TLS, ma uno dei sistemi non dispone di correzioni zero iniziali per il TLS_DHE installato

Per altre informazioni su questo scenario, vedere Si verificano errori di connessione TLS chiusa forzatamente nelle applicazioni durante la connessione a SQL Server in Windows.

Note

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

Scenario 6: Timeout handshake TCP a tre vie (errore SYN, rifiuto TCP) a causa della carenza di ruoli di lavoro IOCP

Nei sistemi con carichi di lavoro elevati in SQL Server 2017 e versioni precedenti, è possibile osservare un errore intermittente 10054 causato da errori di handshake TCP a tre vie, causando rifiuti TCP. La causa radice di questo problema potrebbe essere il ritardo nell'elaborazione TCPAcceptEx delle richieste. Questo ritardo può essere dovuto a una carenza di ruoli di lavoro listener IOCP (Input/Output Completion Port) responsabili della gestione dell'accettazione delle connessioni in ingresso. Il numero insufficiente di ruoli di lavoro IOCP e la manutenzione di altre richieste comporta un ritardo nell'elaborazione delle richieste di connessione, causando in definitiva errori di handshake e rifiuti TCP. È anche possibile osservare i timeout di accesso durante l'handshake SSL di avvio (se presente) o l'elaborazione delle richieste di accesso, che comportano controlli di autenticazione.

Risoluzione

Una carenza di ruoli di lavoro IOCP e risorse di lavoro SOS allocati per la gestione delle operazioni di autenticazione e crittografia è la causa principale dei timeout dell'handshake TCP a tre vie e dei timeout di accesso aggiuntivi. SQL Server 2019 include diversi miglioramenti delle prestazioni in questo settore. Un notevole miglioramento è l'implementazione di un pool di dispatcher di accesso dedicato. In questo modo viene ottimizzata l'allocazione delle risorse per le attività correlate all'accesso, riducendo così l'occorrenza di timeout e migliorando le prestazioni complessive del sistema.

Altri scenari in cui le connessioni TLS hanno esito negativo

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

Vedi anche

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