Una conexión existente fue cerrada por la fuerza por el host remoto

  • Artículo
  • Tiempo de lectura: 6 minutos

Se aplica a:   SQL Server

Nota

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

En este artículo se detallan varias causas y se proporcionan resoluciones para los siguientes errores:

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

  • Se estableció correctamente una conexión con el servidor, pero se produjo un error durante el protocolo de enlace previo al inicio de sesión. (proveedor: proveedor TCP, error: 0: una conexión existente fue cerrada por la fuerza por el host remoto).

¿Cuándo ve el error?

El canal seguro, también conocido como Schannel, es un proveedor de soporte 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 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.

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

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

SSL y 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 enviar actualizaciones a través de la directiva de grupo u otros mecanismos para deshabilitar estas versiones de TLS inseguras en varios equipos del entorno.

Los errores de conectividad se producen cuando la aplicación usa una versión anterior del controlador de conectividad a bases de datos abiertas (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 de coincidencia (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 su SQL Server o los proveedores de cliente a una versión compatible con 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 realizando una de las siguientes acciones:

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

Este escenario se produce cuando usted o el administrador restringen ciertos 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 De saludo de cliente y Saludo del servidor en un seguimiento de red. El paquete De saludo de cliente anuncia todos los conjuntos de cifrado de cliente, mientras que el paquete Saludo del servidor especifica uno de ellos. Si no hay conjuntos de servidores que coincidan, el servidor cerrará la conexión en lugar de responder al paquete Saludo 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 este comando de PowerShell para buscar las funciones TLS

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

  2. Use una herramienta como IIS Crypto (sección Conjuntos de cifrados) para comprobar si hay algoritmos que coincidan. Si no se encuentran algoritmos que coincidan, póngase en contacto con el soporte técnico de Microsoft.

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

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

SQL Server cifra siempre 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 de servidor en el almacén de certificados, usará el certificado. SQL Server este certificado incluso si no se ha 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 resolver el 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 para <instance name>.
  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 hash/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 de servidor:
    1. Seleccione StartRun > 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 Complemento Certificados.
    3. Expanda PersonalCertificates > .
    4. Busque el certificado que SQL Server está usando por su nombre o examinando el valor 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 4: el cliente y el servidor usan un conjunto de cifrado TLS_DHE para el protocolo de enlace TLS, pero uno de los sistemas no tiene ninguna corrección de cero para el TLS_DHE instalado

Para obtener más información acerca de este escenario, vea Applications experience forcibly closed TLS connection errors when connecting SQL Servers in Windows.

Nota

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

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.