Compartir a través de

El host remoto cerró forzadamente 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:

  • Se estableció correctamente una conexión con el servidor, pero luego se produjo un error durante el proceso de inicio de sesión. (proveedor: proveedor SSL, error: 0: la conexión existente se cerró forzadamente por el host remoto).

  • Se ha establecido correctamente la conexión con el servidor, pero se ha producido un error durante el protocolo de enlace previo al inicio de sesión. (proveedor: proveedor TCP, error: 0: la conexión existente se cerró forzadamente por el host remoto).

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

¿Cuándo ve el error?

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 de 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 las 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 coincidente 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:

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

Este escenario se produce cuando usted o el administrador restringen determinados algoritmos en el cliente o el servidor para mayor seguridad.

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

Solución

Para comprobar el problema, siga estos pasos:

  1. Si un seguimiento de red no está disponible, compruebe el valor de las funciones 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 crypto de IIS para comprobar si hay algoritmos coincidentes. 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 El flujo de trabajo de actualización de TLS 1.2 y las conexiones de seguridad de la capa de transporte (TLS) pueden producir un error o un tiempo de espera al conectarse o intentar una reanudación.

Escenario 3: Los cifrados de TLS_DHE podrían estar habilitados

Este problema se produce cuando el cliente o servidor se hospeda en Windows 2012, 2016 y versiones posteriores. A pesar de ambas versiones del sistema operativo que poseen el mismo cifrado (TLS_DHE*), Windows 2012 y 2016+ controlan las claves de criptografía 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 con errores de conexión TLS cerrados forzadamente 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 admite 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:

Los certificados autofirmados no se ven afectados por este problema.

Solución

Para resolver el problema, siga estos pasos:

  1. En Administrador de configuración de SQL Server, expanda Configuración de red de SQL Server en el panel Consola.
  2. Seleccione Protocolos para el <nombre> de instancia.
  3. Seleccione la pestaña Certificado y siga el paso pertinente:
    • 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 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 Inicio>Ejecutar 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. Expanda Personal>Certificados.
    4. Busque el certificado que USA SQL Server por su nombre o examinando el valor de huella digital de diferentes 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 de 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 iniciales para el TLS_DHE instalado

Para más información acerca de este escenario, consulte Las aplicaciones experimentan errores de cierre forzado de la 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 triple TCP (error de SYN, rechazo 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 bidireccionales tcp, lo que provoca 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 trabajadores de escucha del agente de escucha ioCP (puerto de finalización de entrada/salida) responsable de administrar la aceptación de las conexiones entrantes. El número insuficiente de trabajos 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 en las comprobaciones de autenticación.

Solución

Una escasez de trabajadores de IOCP y recursos de trabajo de SOS asignados para controlar las operaciones de autenticación y cifrado es la principal causa de los tiempos de espera de protocolo de enlace tcp triple 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 las 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 corresponde a ninguno de los escenarios anteriores, consulte los siguientes escenarios adicionales:

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