Compartir a través de

El host remoto cerró por la fuerza una conexión existente (error del sistema operativo 10054)

  • Artículo

Se aplica a: SQL Server

Nota:

Antes de empezar a solucionar problemas, se recomienda comprobar los requisitos previos y seguir la lista de comprobación.

En este artículo se detallan varios escenarios y se proporcionan soluciones para los errores siguientes:

  • La conexión con el servidor se ha establecido correctamente, pero se ha producido un error durante el proceso de inicio de sesión. (proveedor: Proveedor SSL, error: 0 - El host remoto cerró forzadamente una conexión existente).

  • Se estableció correctamente una conexión con el servidor, pero luego se produjo un error durante el protocolo de enlace anterior al inicio de sesión. (proveedor: Proveedor TCP, error: 0 - El host remoto cerró forzadamente una conexión existente).

El error 10054 del sistema operativo se genera en la capa de sockets de Windows. Para obtener más información, vea Códigos de error de Windows Sockets: WSAECONNRESET 10054.

¿Cuándo ve el error?

El canal seguro, también conocido como Schannel, es un proveedor de soporte técnico de seguridad (SSP). Contiene un conjunto de protocolos de seguridad que proporcionan autenticación de identidad y comunicación privada segura a través del cifrado. Una función de Schannel SSP es implementar diferentes versiones del protocolo seguridad de la capa de transporte (TLS). Este protocolo es un estándar del sector diseñado para proteger la privacidad de la información que se comunica a través de Internet.

El Protocolo de protocolo de enlace TLS es responsable del intercambio de claves necesario para establecer o reanudar sesiones seguras entre dos aplicaciones que se comunican a través de TCP. Durante la fase previa al inicio de sesión del proceso de conexión, SQL Server y las aplicaciones cliente usan el protocolo TLS para establecer un canal seguro para transmitir credenciales.

En los escenarios siguientes se detallan los errores que se producen cuando no se puede completar el protocolo de enlace:

Escenario 1: No existen protocolos TLS coincidentes entre el cliente y el servidor

La capa de socket seguro (SSL) y las versiones de TLS anteriores a TLS 1.2 tienen varias vulnerabilidades conocidas. Se recomienda actualizar a TLS 1.2 y deshabilitar las versiones anteriores siempre que sea posible. En consecuencia, los administradores del sistema podrían insertar actualizaciones a través de la directiva de grupo u otros mecanismos para deshabilitar estas versiones tls no seguras en varios equipos del entorno.

Los errores de conectividad se producen cuando la aplicación usa una versión anterior del controlador open database connectivity (ODBC), el proveedor OLE DB, los componentes de .NET Framework o una versión de SQL Server que no admite TLS 1.2. El problema se produce porque el servidor y el cliente no pueden encontrar un protocolo coincidente (como TLS 1.0 o TLS 1.1). Se necesita un protocolo de coincidencia para completar el protocolo de enlace TLS necesario para continuar con la conexión.

Solución

Para solucionar este problema, use uno de los métodos siguientes:

  • Actualice el SQL Server o los proveedores de cliente a una versión que admita TLS 1.2. Para obtener más información, consulte Compatibilidad con TLS 1.2 para Microsoft SQL Server.
  • Pida a los administradores del sistema que habiliten temporalmente TLS 1.0 o TLS 1.1 en los equipos cliente y servidor mediante una de las siguientes acciones:

Escenario 2: Coincidencia de protocolos TLS en el cliente y el servidor, pero sin conjuntos de cifrado TLS coincidentes

Este escenario se produce cuando usted o el administrador restringen ciertos algoritmos en el cliente o el servidor para obtener seguridad adicional.

Las versiones tls de cliente y servidor, los conjuntos de cifrado se pueden examinar fácilmente en los paquetes Hello cliente y Server Hello en un seguimiento de red. El paquete Hello cliente anuncia todos los conjuntos de cifrado de cliente, mientras que el paquete server Hello especifica uno de ellos. Si no hay conjuntos coincidentes, el servidor cierra la conexión en lugar de responder al paquete server Hello.

Solución

Para comprobar el problema, siga estos pasos:

  1. Si un seguimiento de red no está disponible, compruebe el valor de functions en esta clave del Registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

    Use el siguiente comando de PowerShell para buscar las funciones TLS.

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

  2. Use la pestaña Conjuntos de cifrado de la herramienta Cifrado de IIS para comprobar si hay algún algoritmo coincidente. Si no se encuentra ningún algoritmo coincidente, póngase en contacto con Soporte técnico de Microsoft.

Para obtener más información, consulte Tls 1.2 Upgrade Workflow and Transport Layer Security (TLS) connections might fail or timeout when connecting or attempting a resumption.

Escenario 3: Es posible que se habiliten los cifrados de TLS_DHE

Este problema se produce cuando el cliente o servidor se hospeda en Windows 2012, 2016 y versiones posteriores. A pesar de que ambas versiones del sistema operativo poseen el mismo cifrado (TLS_DHE*), Windows 2012 y 2016+ controlan las claves criptográficas dentro de TLS de forma diferente. Esto puede dar lugar a errores de comunicación.

Solución

Para resolver este problema, quite todos los cifrados a partir de "TLS_DHE*" de la directiva local. Para obtener más información sobre los errores que se producen cuando las aplicaciones intentan conectarse a SQL Server en Windows, consulte Experiencia de aplicaciones que cierran por la fuerza los errores de conexión TLS al conectar servidores SQL Server en Windows.

Escenario 4: SQL Server usa un certificado firmado por un algoritmo hash débil, como MD5, SHA224 o SHA512

SQL Server siempre cifra los paquetes de red relacionados con el inicio de sesión. Para ello, usa un certificado aprovisionado manualmente o un certificado autofirmado. Si SQL Server encuentra un certificado que admita la función de autenticación del servidor en el almacén de certificados, usa el certificado. SQL Server usa este certificado aunque no se haya aprovisionado manualmente. Si estos certificados usan un algoritmo hash débil (algoritmo de huella digital) como MD5, SHA224 o SHA512, no funcionarán con TLS 1.2 y provocarán el error mencionado anteriormente.

Nota:

Este problema no afecta a los certificados autofirmados.

Solución

Para solucionar este problema, siga estos pasos:

  1. En Administrador de configuración de SQL Server, expanda SQL Server Configuración de red en el panel Consola.
  2. Seleccione Protocolos como nombre> de <instancia.
  3. Seleccione la pestaña Certificado y siga el paso correspondiente:
    • Si se muestra un certificado, seleccione Ver para examinar el algoritmo de huella digital para confirmar si usa un algoritmo hash débil. A continuación, seleccione Borrar y vaya al paso 4.
    • Si no se muestra un certificado, revise el registro de errores de SQL Server para obtener una entrada similar a la siguiente y anote el valor de hash o huella digital:
      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption
  4. Siga estos pasos para quitar la autenticación del servidor:
    1. Seleccione Iniciar>ejecución y escriba MMC. (MMC también conocido como Microsoft Management Console).
    2. En MMC, abra los certificados y seleccione Cuenta de equipo en la pantalla del complemento Certificados .
    3. ExpandaCertificadospersonales>.
    4. Busque el certificado que SQL Server está usando por su nombre o examinando el valor de huella digital de distintos certificados en el almacén de certificados y abra su panel Propiedades.
    5. En la pestaña General , seleccione Habilitar solo los siguientes propósitos y anule la selección de Autenticación del servidor.
  5. Reinicie el servicio SQL Server.

Escenario 5: El cliente y el servidor usan TLS_DHE conjunto de cifrado para el protocolo de enlace TLS, pero uno de los sistemas no tiene correcciones de cero iniciales para el TLS_DHE instalado

Para obtener más información sobre este escenario, vea La experiencia de aplicaciones ha cerrado forzmente los errores de conexión TLS al conectar servidores SQL Server en Windows.

Nota:

Si este artículo no ha resuelto el problema, puede comprobar si los artículos de problemas de conectividad comunes pueden ayudar.

Escenario 6: Tiempo de espera del protocolo de enlace tcp Three-Way (error de SYN, rechazo de TCP) debido a la escasez de trabajadores de IOCP

En sistemas con cargas de trabajo elevadas en SQL Server 2017 y versiones anteriores, es posible que observe un error intermitente de 10054 causado por errores de protocolo de enlace de tres vías TCP, lo que conduce a rechazos tcp. La causa principal de este problema podría estar en el retraso en el procesamiento TCPAcceptEx de solicitudes. Este retraso puede deberse a una escasez de agentes de escucha de IOCP (puerto de finalización de entrada/salida) responsables de administrar la aceptación de las conexiones entrantes. El número insuficiente de trabajadores de IOCP y el mantenimiento ocupado de otras solicitudes conduce al procesamiento retrasado de las solicitudes de conexión, lo que, en última instancia, da lugar a errores de protocolo de enlace y rechazos tcp. También puede observar los tiempos de espera de inicio de sesión durante el protocolo de enlace SSL de inicio (si existe) o el procesamiento de solicitudes de inicio de sesión, que implican comprobaciones de autenticación.

Solución

La escasez de trabajadores de IOCP y recursos de SOS Worker asignados para controlar las operaciones de autenticación y cifrado es la causa principal de los tiempos de espera del protocolo de enlace de tres vías TCP y tiempos de espera de inicio de sesión adicionales. SQL Server 2019 incluye varias mejoras de rendimiento en esta área. Una mejora notable es la implementación de un grupo de distribuidores de inicio de sesión dedicado. Esto optimiza la asignación de recursos para tareas relacionadas con el inicio de sesión, lo que reduce la aparición de tiempos de espera y mejora el rendimiento general del sistema.

Otros escenarios en los que se produce un error en las conexiones TLS

Si el mensaje de error que encuentra no se corresponde con ninguno de los escenarios anteriores, consulte los siguientes escenarios adicionales:

Vea también

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.