Solucionar el error de cifrado de SQL Server: solución con un solo clic

Lea el error: es un problema de confianza, no un problema de red

Su red está bien y el servidor está funcionando. La conexión llegó a SQL Server, el servidor ofreció un canal cifrado para iniciar sesión y su PC lo rechazó porque el certificado que prueba la identidad del servidor no está firmado por nadie en quien su PC confíe. El error completo que muestra SSMS es:

De forma predeterminada, SQL Server protege el inicio de sesión con un certificado autofirmado que crea él mismo. Un certificado autofirmado cifra el tráfico, pero no puede probar que el servidor sea realmente el suyo, por lo que los clientes que exigen cifrado verificado lo rechazan. Cada solución honesta es una de dos cosas: hacer que el cliente acepte este servidor en particular con conocimiento (Pasos 2 y 3), o darle al servidor un certificado en el que los clientes confíen por sí mismos (Paso 4).

La solución rápida del cliente en SSMS: certificado de servidor de confianza

Esta es la ruta rápida que se muestra en el vídeo. No cambia nada en el servidor; le dice a esta conexión que acepte el certificado del servidor sin verificar quién lo firmó. En la ventana SSMS Conectar al servidor, haga clic en Opciones para abrir las pestañas adicionales, vaya a la pestaña Propiedades de conexión, establezca el cifrado en Obligatorio (o déjelo como se ofrece), marque Certificado de servidor de confianza y haga clic en Conectar. El inicio de sesión se realiza de inmediato.

La misma solución dentro de la cadena de conexión de una aplicación

Si falla una aplicación en lugar de SSMS, el mismo conmutador reside en su cadena de conexión. Agregue las dos configuraciones explícitamente: Encrypt=True activa el canal protegido y TrustServerCertificate=True es la ortografía de la cadena de conexión de la casilla de verificación SSMS:

Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;

Utilice su propio nombre de servidor, base de datos e inicio de sesión en lugar de los valores de ejemplo. La compensación es exactamente la misma que la casilla de verificación en el Paso 2, con un peligro adicional: incorporada en la configuración de una aplicación enviada, la verificación omitida se aplica a todos los usuarios, de manera invisible y permanente. Manténgalo en las configuraciones de desarrollo y ensayo, y en producción trátelo como tiempo prestado hasta que el certificado de servidor del Paso 4 esté implementado.

La solución adecuada: proporcione al servidor un certificado real

La reparación permanente ocurre una vez, en el servidor, y luego cada cliente se conecta estrictamente sin casillas de verificación ni advertencias. Primero obtenga un certificado para el nombre DNS completo del servidor (por ejemplo, sql01.company.local) de su autoridad certificadora interna o de una CA pública, con uso de Autenticación del servidor. Impórtelo, con su clave privada, al almacén de certificados del Equipo local en la máquina de SQL Server. Luego haga clic derecho en el certificado, elija Todas las tareas → Administrar claves privadas y otorgue a la cuenta de servicio de SQL Server permiso de Lectura sobre la clave privada. Abra el Administrador de configuración de SQL Server, expanda Configuración de red de SQL Server, haga clic con el botón derecho en Protocolos para MSSQLSERVER, elija Propiedades y seleccione el certificado en la pestaña Certificado. En la pestaña Flags también puede configurar ForceEncryption en Sí para que cada cliente deba cifrar. Reinicie el servicio SQL Server; el cambio no hace nada hasta que usted lo haga.

Verifique la solución de forma estricta

Un inicio de sesión exitoso resulta ser menos de lo que la gente piensa, porque algunas combinaciones de configuraciones se conectan sin una protección real. Demuestre ambas mitades. Primero, vuelva a conectarse desde un cliente de manera estricta: conéctese usando el nombre DNS del servidor (el nombre dentro del certificado), configure el cifrado en Obligatorio y deje Certificado de servidor de confianza sin marcar. El inicio de sesión debería realizarse correctamente sin previo aviso. Luego, en esa misma sesión, pregunte al servidor si la conexión está realmente cifrada ejecutando esta consulta en SSMS:

SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

encrypt_option que muestra TRUE es la calificación aprobatoria. FALSO con un inicio de sesión funcional significa que la conexión se realizó correctamente al eliminar la protección y el trabajo no se realizó. Esa prueba de aprobación es la verdadera meta: cualquier cliente configurado correctamente, incluidas las versiones futuras de SSMS, ahora se conecta con una validación completa y sin configuraciones especiales.