La situación es la siguiente: vas a conectarte a SQL Server desde un equipo remoto usando exactamente las mismas credenciales que usabas para conectarte en local y, al hacerlo, recibes un error como este:

Error mostrado por SQL Server al conectarse

que dice en español algo así como:

Se ha establecido con éxito una conexión con el servidor, pero ha ocurrido un error durante el proceso de autenticación. El certificado recibido del servidor remoto fue emitido por una entidad en la que no se confía.

Nada, que no hay manera de conectarse. El mensaje habla de un certificado y menciona al proveedor de SSL de SQL Server... Pero tú no has instalado ningún certificado en el servidor... ¿De qué va todo esto?

Cuando SQL Server se instala, salvo que al hacerlo le indiquemos explícitamente que vamos a utilizar un determinado certificado digital para securizar las comunicaciones, el servidor instala un certificado auto-firmado para ello. Este certificado está creado por el propio SQL Server y no se sustenta en una infraestructura de clave pública real. Lo que quiere decir que el certificado sirve para cifrar las comunicaciones y validar su integridad, pero no sirve para asegurar que nos estamos conectando al servidor correcto, ya que la única "autoridad" que nos asegura que el servidor es el correcto, es el propio servidor 😖

De eso precisamente es de lo que va ese mensaje de error. Lo que nos indica es que, por defecto, como no se puede verificar la identidad del servidor, no permite la conexión.

Algo similar ocurre con muchos otros servicios que usan por defecto un certificado auto-firmado. Por ejemplo, al conectarnos por primera vez a un equipo remoto usando Terminal Server (llamado también Escritorio Remoto), se nos pregunta si queremos confiar o no en ese certificado y por lo tanto conectarnos al servidor:

Advertencia mostrada por escritorio remoto al conectarse a un servidor sin certificado de confianza

Es normal, al fin y al cabo los principales propósitos de un certificado digital son tres:

  1. Privacidad de la información, cifrando las comunicaciones en el tránsito
  2. Integridad de la comunicación, combinándolos con resúmenes digitales
  3. Confianza, saber que las comunicaciones vienen de quién dicen venir y que no estamos comunicando con quien creemos.

Las 2 primeras no sirven de mucho si falla la tercera...

¿Cómo lo solucionamos?

Si el error nos lo está dando el propio SQL Server Management Studio, cuando nos queremos conectar desde la pantalla de login, lo que tenemos que hacer es ir a las opciones avanzadas de ese diálogo:

Al entrar, enl a pestaña de "Propiedades de la conexión" veremos que está marcada la opción de "Cifrar conexión":

Siempre podemos desmarcarla y evitar que se produzca el error, pero entonces todo el tráfico entre nuestro equipo y el servidor SQL Server remoto se enviará en claro a través de Internet, así que es una mala idea.

Si vamos a la pestaña "Parámetros adicionales de la conexión", podemos escribir un modificador para que la conexión confíe en el certificado del servidor SQL Server remoto. Este parámetro adicional es:

TrustServerCertificate=True

Basta con escribirlo en el cuadro de texto de esa ventana:

Ahora al pulsar en "Conectar" veremos que el error desaparece y podemos trabajar con normalidad.

Si el error lo está dando una aplicación, solo hay que modificar la cadena de conexión y ponerle al final el mismo parámetro.

Evidentemente, si hacemos esto tenemos que estar seguros de que el servidor al que nos estamos conectando es el que nos interesa de verdad y que no existe un problema de seguridad que pueda estar falseando las DNS para que nos conectemos a otro sitio...

¡Espero que te resulte útil!

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor

Escrito por un humano, no por una IA