Compartilhar via

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

  • Artigo

Aplica-se a: SQL Server

Observação

Antes de começar a solucionar problemas, recomendamos que você verifique os pré-requisitos e acesse a lista de verificação.

Este artigo detalha vários cenários e fornece resoluções para os seguintes erros:

  • 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.

Quando você vê o erro?

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). Esse protocolo é 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é-login do processo de conexão, o SQL Server e aplicativos cliente usam o protocolo TLS para estabelecer um canal seguro para transmissão de credenciais.

Os cenários a seguir detalham os erros que ocorrem quando o handshake não pode ser concluído:

Cenário 1: Não existem protocolos TLS correspondentes entre o cliente e o servidor

O Secure Socket Layer (SSL) e as versões do TLS anteriores ao TLS 1.2 têm várias vulnerabilidades conhecidas. Você é incentivado a atualizar para o TLS 1.2 e desabilitar versões anteriores sempre que possível. Da mesma forma, os administradores do sistema podem enviar atualizações por meio da política de grupo ou de outros mecanismos para desabilitar essas versões inseguras do TLS em vários computadores em seu ambiente.

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

Resolução

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

Cenário 2: Protocolos TLS correspondentes no cliente e no servidor, mas nenhum conjunto de criptografia TLS correspondente

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

As versões TLS do cliente e do servidor, os conjuntos de criptografia podem ser facilmente examinados nos pacotes Client Hello e Server Hello em um rastreamento de rede. O pacote Client Hello anuncia todos os conjuntos de criptografia do cliente, enquanto o pacote Server Hello especifica um deles. Se não houver suítes correspondentes, o servidor fechará a conexão em vez de responder ao pacote Server Hello .

Resolução

Para verificar o problema, siga estas etapas:

  1. Se um rastreamento de rede não estiver disponível, verifique o valor das funções nesta chave do Registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

    Use o comando do PowerShell a seguir para localizar as funções TLS.

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

  2. Use a guia Ciphers Suites 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 TLS 1.2 Atualizar o fluxo de trabalho e as conexões TLS (Transport Layer Security) podem falhar ou atingir o tempo limite ao se conectar ou tentar uma retomada.

Cenário 3: As criptografias TLS_DHE podem estar habilitadas

Esse problema ocorre quando o cliente ou servidor está hospedado no Windows 2012, 2016 e versões posteriores. Apesar de ambas as versões do sistema operacional possuírem a mesma cifra (TLS_DHE*), Windows 2012 e 2016+ lidam com chaves de criptografia dentro do TLS de maneira diferente. Isso pode resultar em erros de comunicação.

Resolução

Para resolver esse problema, remova todas as criptografias que começam com "TLS_DHE*" da política local. Para obter mais informações sobre erros que ocorrem quando os aplicativos tentam se conectar ao SQL Server no Windows, consulte Aplicativos experimentam erros de conexão TLS fechados à força ao conectar SQL Servers no Windows.

Cenário 4: SQL Server usa um certificado assinado por um algoritmo de hash fraco, como MD5, SHA224 ou SHA512

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 o SQL Server encontrar um certificado que ofereça suporte à função de autenticação de servidor no repositório de certificados, ele usará o certificado. O SQL Server usa esse certificado mesmo que ele não tenha sido provisionado manualmente. Se esses certificados usarem um algoritmo de hash fraco (algoritmo de impressão digital), como MD5, SHA224 ou SHA512, eles não funcionarão com o TLS 1.2 e causarão o erro mencionado anteriormente.

Observação

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

Resolução

Para resolver o problema, siga estas etapas:

  1. No SQL Server Configuration Manager, expanda Configuração de Rede do SQL Server no painel Console .
  2. Selecione Protocolos para o <nome da> instância.
  3. Selecione a guia Certificado e siga a etapa relevante:
    • Se um certificado for exibido, selecione Exibir para examinar o algoritmo de impressão digital para confirmar se ele está usando um algoritmo de hash fraco. Em seguida, selecione Limpar e vá para a etapa 4.
    • Se um certificado não for exibido, examine o log de erros do SQL Server em busca de uma entrada semelhante à seguinte e anote o valor de hash ou impressão digital:
      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption
  4. Use as seguintes etapas para remover a autenticação do servidor:
    1. Selecione Iniciar>Executar e digite MMC. (MMC também conhecido como Console de Gerenciamento Microsoft.)
    2. No MMC, abra os certificados e selecione Conta de Computador na tela do snap-in Certificados .
    3. Expanda Pessoal>Certificados.
    4. Localize o certificado que o SQL Server está usando por seu nome ou examinando o valor de impressão digital de diferentes certificados no repositório de certificados e abra seu painel Propriedades .
    5. Na guia Geral, selecione Habilitar apenas as seguintes finalidades e cancele a seleção de Autenticação do servidor.
  5. Reinicie o serviço SQL Server.

Cenário 5: o cliente e o servidor estão usando TLS_DHE pacote de criptografia para handshake TLS, mas um dos sistemas não tem correções zero à esquerda para o TLS_DHE instalado

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 resolveu seu problema, você pode verificar se os artigos de problemas comuns de conectividade podem ajudar.

Cenário 6: Tempo limite de handshake de três vias do TCP (falha de SYN, rejeição de TCP) devido à escassez de trabalhadores IOCP

Em sistemas com altas cargas de trabalho no SQL Server 2017 e versões anteriores, você pode observar o erro 10054 intermitente causado por falhas de handshake de três vias do TCP, levando a rejeições de TCP. A causa raiz desse problema pode estar no atraso no processamento de TCPAcceptEx solicitações. Esse atraso pode ser devido à falta de trabalhadores ouvintes IOCP (Input/Output Completion Port) responsáveis por gerenciar a aceitação de conexões de entrada. O número insuficiente de trabalhos IOCP e ocupados atendendo a outras solicitações leva ao atraso no processamento de solicitações de conexão, resultando em falhas de handshake e rejeições de TCP. Você também pode observar tempos limite de login durante o handshake SSL inicial (se houver) ou o processamento de solicitações de login, que envolvem verificações de autenticação.

Resolução

A escassez de trabalhadores IOCP e recursos do SOS Worker alocados para lidar com operações de autenticação e criptografia é a principal causa dos tempos limite de handshake de três vias do TCP e tempos limite de login adicionais. O SQL Server 2019 inclui várias melhorias de desempenho nessa área. Um aprimoramento notável é a implementação de um pool de dispatcher de logon dedicado. Isso otimiza a alocação de recursos para tarefas relacionadas ao login, o que reduz a ocorrência de tempos limite e melhora o desempenho geral do sistema.

Outros cenários em que as conexões TLS falham

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

Confira também

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.