Uma conexão existente foi fechada à força pelo host remoto (erro do sistema operacional 10054)

Aplica-se a: SQL Server

Resumo

Este artigo descreve cenários em que ocorre o erro de conectividade SQL Server "Uma conexão existente foi fechada à força pelo host remoto" e fornece resoluções. O erro está vinculado a um handshake TLS com falha entre o cliente e o SQL Server, geralmente porque o cliente e o servidor não podem concordar com uma versão de protocolo TLS (por exemplo, TLS 1.2 ou TLS 1.3) ou um conjunto de criptografia.

O artigo aborda as seguintes mensagens de erro:

Uma conexão com o servidor foi estabelecida com êxito, mas ocorreu um erro durante o processo de logon. (provedor: Provedor SSL, erro: 0 - Uma conexão existente foi fechada à força pelo host remoto.)

Uma conexão com o servidor foi estabelecida com êxito, mas ocorreu um erro durante o handshake de pré-logon. (provedor: Provedor TCP, erro: 0 - Uma conexão existente foi fechada à força pelo host remoto.)

O erro do sistema operacional 10054 é gerado na camada de soquetes do Windows. Para obter mais informações, consulte Códigos de erro do Windows Sockets: WSAECONNRESET 10054.

Antes de iniciar a solução de problemas, verifique os pré-requisitos e percorra a lista de verificação.

Quando esse erro ocorre

O Canal Seguro, também conhecido como Schannel, é um SSP (Provedor de Suporte de Segurança). Ele contém um conjunto de protocolos de segurança que fornecem autenticação de identidade e comunicação privada segura por meio de criptografia. Uma função do Schannel SSP é implementar diferentes versões do protocolo Transport Layer Security (TLS). O TLS é um padrão do setor projetado para proteger a privacidade das informações comunicadas pela Internet.

O protocolo de handshake TLS é responsável pela troca de chaves necessária para estabelecer ou retomar sessões seguras entre dois aplicativos que se comunicam por TCP. Durante a fase de pré-logon do processo de conexão, SQL Server e aplicativos cliente usam o protocolo TLS para configurar um canal seguro para transmitir credenciais.

Versões do TLS em um relance

A tabela a seguir compara as versões do TLS que você pode encontrar ao solucionar esse erro:

Versão	Status atual no Windows	Recomendação para SQL Server
TLS 1.0 / 1.1	Desabilitado por padrão em Windows 11, Windows Server 2022 e posterior. Considerado inseguro.	Não use. Atualize clientes e servidores para o TLS 1.2 ou posterior.
TLS 1.2	Habilitado por padrão em todas as versões de Windows com suporte. Amplamente compatível com SQL Server e drivers de cliente modernos.	Linha de base recomendada.
TLS 1.3	Com suporte em Windows 11 e Windows Server 2022 e posteriores. Compatível com o SQL Server 2022 e versões posteriores com drivers de cliente atuais (por exemplo, Microsoft ODBC Driver 18 e Microsoft.Data.SqlClient 5.x).	Use onde o cliente e o servidor dão suporte a ele.

Para obter o estado de suporte atual dos protocolos TLS em Windows, consulte Protocolos no TLS/SSL (SSP Schannel).

Identificar qual cenário se aplica em seu ambiente

As seções a seguir descrevem cenários diferentes que podem fazer com que o handshake falhe. Se você não tiver certeza de qual deles corresponde ao seu ambiente, use estes pontos iniciais para reduzi-lo:

Capture um rastreamento de rede no cliente e no servidor durante uma conexão com falha. Em seguida, inspecione os pacotes Client Hello e Server Hello para confirmar a versão do TLS e a suíte de cifras negociadas.
Verifique o SQL Server log de erros da successfully loaded for encryption entrada para confirmar qual certificado está em uso. Verifique seu algoritmo de impressão digital.
Compare as versões do TLS habilitadas e os conjuntos de criptografia no cliente e no servidor usando Get-TlsCipherSuite e as chaves do Registro em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
Confirme se o driver cliente dá suporte ao TLS 1.2 ou posterior. Drivers mais antigos, como SQL Server Native Client, são preteridos e não são recomendados.

Nenhum protocolo TLS correspondente entre o cliente e o servidor

A SSL (Secure Sockets Layer) e as versões do TLS anteriores ao TLS 1.2 têm várias vulnerabilidades conhecidas. Em versões de Windows modernas (Windows 11, Windows Server 2022 e posterior), o TLS 1.0 e o TLS 1.1 são desabilitados por padrão. Os administradores frequentemente também implantam configurações de Política de Grupo ou de Registro para desativar esses protocolos mais antigos em ambientes antigos.

Erros de conectividade ocorrem quando seu aplicativo usa um driver ODBC (Open Database Connectivity) mais antigo, um provedor OLE DB, um componente do .NET Framework ou SQL Server versão que não dá suporte ao TLS 1.2 ou posterior. O problema ocorre porque o servidor e o cliente não conseguem encontrar um protocolo correspondente. Um protocolo correspondente é necessário para concluir o handshake do TLS.

Corrigir incompatibilidade de protocolo entre cliente e servidor

Para corrigir esse problema, use um dos seguintes métodos:

Atualize SQL Server ou seus provedores cliente para uma versão que dê suporte ao TLS 1.2 (e, sempre que possível, ao TLS 1.3). Para obter mais informações, consulte Suporte do TLS 1.2 para Microsoft SQL Server.
Como uma solução alternativa de curto prazo, peça aos administradores do sistema que habilitem temporariamente o TLS 1.0 ou o TLS 1.1 no cliente e no servidor. Faça isso somente até que os componentes possam ser atualizados. Use uma das seguintes ações:
- Use a guia Suítes de Criptografia da ferramenta IIS Crypto para verificar e alterar as configurações atuais de TLS.
- Inicie o Editor do Registro e vá para as chaves do Registro específicas do Schannel em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. Para obter mais informações, consulte erros de SSL e fluxo de trabalho de atualização do TLS 1.2 após a atualização para o TLS 1.2.

Exemplo: versões mínimas do driver do cliente para TLS 1.2

Use componentes do cliente que dão suporte nativo ao TLS 1.2 ou posterior. Os seguintes componentes são linhas de base seguras comuns:

Microsoft Driver ODBC 17 ou 18 para SQL Server.
Microsoft driver OLE DB 18 ou 19 para SQL Server.
.NET Framework 4.6.2 ou posterior ou qualquer versão com suporte do .NET (.NET 6 e posterior).
Microsoft JDBC Driver 9.4 ou posterior.

O SNAC (SQL Server Native Client) herdado e o provedor SQL Server OLE DB que foi enviado com Windows (SQLOLEDB) foram preteridos. Substitua-os pelos componentes da lista anterior.

Protocolos TLS correspondentes, mas sem conjuntos de criptografia correspondentes

Esse cenário ocorre quando você ou um administrador restringe determinados algoritmos no cliente ou no servidor para segurança extra.

Você pode examinar as versões de TLS do cliente e do servidor e as suítes de criptografia nos pacotes Client Hello e Server Hello de um rastreamento de rede. O pacote Olá do Cliente anuncia todos os pacotes de criptografia do cliente e o pacote Server Hello retorna aquele que o servidor escolheu. Se não houver suites compatíveis, o servidor fecha a conexão em vez de enviar um pacote Server Hello.

Corrigir incompatibilidade do conjunto de criptografias

Para verificar o problema, siga estas etapas:

Se um rastreamento de rede não estiver disponível, verifique o valor Functions na seguinte chave do Registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002.

Use o seguinte comando do PowerShell para listar os conjuntos de criptografia TLS configurados:
```
Get-ItemPropertyValue -Path 'HKLM:\System\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\' -Name Functions
```
Em Windows 10, Windows 11, Windows Server 2016 e posterior, você também pode executar Get-TlsCipherSuite para listar os pacotes habilitados em uma forma mais legível.
Use a aba Suítes de Cifras na ferramenta IIS Crypto para verificar se há algoritmos correspondentes. Se nenhum algoritmo correspondente for encontrado, entre em contato com o Suporte da Microsoft.

Para obter mais informações, consulte Fluxo de trabalho de atualização do TLS 1.2 e As conexões de TLS (Transport Layer Security) podem falhar ou expirar ao se conectar ou ao tentar retomar uma conexão.

TLS_DHE conjuntos de criptografia habilitados em diferentes versões de Windows

Esse problema pode ocorrer quando o cliente e o servidor são executados em diferentes versões de Windows (por exemplo, Windows Server 2012 e Windows Server 2016 ou posterior) e ambos anunciam TLS_DHE_* pacotes de criptografia. Essas versões Windows manipulam Diffie-Hellman troca de chaves dentro do TLS de forma diferente, o que pode fazer com que o handshake falhe.

Remover conjuntos de criptografia TLS_DHE

Para corrigir esse problema, remova da política local todos os conjuntos de cifras que começam com TLS_DHE_. Para obter mais informações sobre erros que ocorrem quando os aplicativos tentam se conectar ao SQL Server no Windows, consulte Os aplicativos apresentam erros de conexão TLS encerrada à força ao se conectar ao SQL Server no Windows.

O certificado do SQL Server usa um algoritmo de hash fraco

O SQL Server sempre criptografa os pacotes de rede relacionados à entrada. Para essa finalidade, ele usa um certificado provisionado manualmente ou um certificado autoassinado. Se SQL Server encontrar um certificado que dê suporte à função de autenticação de servidor no repositório de certificados, ele usará esse certificado mesmo que não tenha sido provisionado manualmente. Se o certificado usar um algoritmo de hash fraco (impressão digital), como MD5, SHA224 ou SHA512, ele não funcionará com o TLS 1.2 e causará o erro.

Observação

Os certificados autoassinados não são afetados por esse problema.

Substituir ou reconfigurar certificados por algoritmos de hash fracos

Para corrigir o problema, siga estas etapas:

No SQL Server Configuration Manager, expanda Configuração de Rede do SQL Server no painel Console .
Selecione Protocolos para o <nome> da instância.
Selecione a guia Certificado e execute uma das seguintes ações:
- Se um certificado for exibido, selecione Exibição para verificar o algoritmo de impressão digital e confirmar se ele usa um algoritmo de hash fraco. Em seguida, selecione Limpar e vá para a etapa 4.
- Se nenhum certificado for exibido, examine o log de erros SQL Server para obter uma entrada como a seguinte e observe o valor de hash ou impressão digital:
  
  2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"] was successfully loaded for encryption
Remova a autenticação do servidor do certificado:
1. Selecione Iniciar>Execução e insira MMC (Console de Gerenciamento Microsoft).
2. No MMC, adicione o snap-in Certificados e selecione Conta de computador.
3. Expanda Pessoal>Certificados.
4. Localize o certificado que SQL Server usa por nome ou por impressão digital e abra seu painel Propriedades.
5. Na guia Geral , selecione Habilitar apenas as seguintes finalidades e limpar a Autenticação de Servidor.
Reinicie o serviço SQL Server.

Correção de zero à esquerda do TLS_DHE não instalada

Esse cenário ocorre quando o cliente e o servidor negociam um TLS_DHE_* conjunto de cifras para o handshake TLS, mas um dos lados não tem a atualização do Windows que adiciona a correção para zero à esquerda inicial na troca de chaves Diffie-Hellman. Para saber mais sobre esse cenário, confira Os aplicativos experimentam erros de conexão TLS fechados à força ao conectar servidores SQL no Windows.

Observação

Se este artigo não corrigir o problema, verifique se os artigos comuns de problemas de conectividade podem ajudar.

Tempo limite de handshake de três vias TCP da escassez de trabalhadores do IOCP

Em sistemas com cargas de trabalho elevadas que executam o SQL Server 2017 ou versões anteriores, é possível observar erros 10054 intermitentes causados por falhas no handshake de três vias do TCP, que levam a rejeições de TCP. A causa raiz geralmente é um atraso no processamento de TCPAcceptEx solicitações. O atraso pode ser causado por uma escassez de trabalhos de ouvintes do IOCP (Porta de Conclusão de Entrada/Saída), que gerenciam a aceitação de conexões de entrada. Quando os trabalhadores do IOCP são muito poucos ou estão ocupados atendendo a outras solicitações, as solicitações de conexão são processadas com atraso, o que resulta em falhas de handshake e rejeições TCP. Você também poderá observar tempos limite de login durante o handshake SSL ou durante o processamento de solicitações de login, que envolvem verificações de autenticação.

Reduzir a escassez de trabalhadores do IOCP e os tempos limite de handshake

A escassez de trabalhadores IOCP e de recursos do SOS Worker alocados para operações de autenticação e criptografia é a principal causa desses tempos limite de handshake de três vias TCP e tempos limite de entrada. SQL Server 2019 e posterior incluem várias melhorias de desempenho nessa área. Um aprimoramento notável é a criação de um pool dedicado de despachantes de login, que otimiza a alocação de recursos para tarefas de login. Essa alteração reduz os tempos limite e melhora o desempenho geral do sistema. Se você for afetado por esse problema, planeje uma atualização para uma versão de SQL Server com suporte no momento.

Outros cenários de falha de conexão do TLS

Se a mensagem de erro encontrada não corresponder a nenhum dos cenários anteriores, consulte os seguintes cenários adicionais:

Aviso de isenção de responsabilidade para informações de terceiros

Os produtos de terceiros mencionados neste artigo são produzidos por empresas independentes da Microsoft. A Microsoft não oferece nenhuma garantia, implícita ou não, do desempenho ou da confiabilidade desses produtos.

Comentários

Esta página foi útil?

Last updated on 2026-06-23