2010-02-09 13 views
10

De repente comencé a recibir este error cuando trato de conectarme a cualquiera de mis servidores SQL (25+) desde SSMS en Windows XP. Cuando dejé el trabajo ayer todo estaba funcionando bien, llegó esta mañana y comencé a recibir esto. Intenté reiniciar mi PC pero eso obviamente no lo solucionó. Mis compañeros de trabajo pueden conectarse bien. Busqué una solución, pero todo lo que encontré fue sobre el cifrado en lo que respecta a las aplicaciones .NET. No estoy seguro de cómo aplicar eso a SSMS. alt text http://picasaweb.google.com/lh/photo/-l9VrFuYXk-A80NzZ1kzng?feat=directlinkError al conectar con todos mis servidores SQL

Por alguna razón la imagen no va a funcionar por lo que el error es el siguiente:

Una conexión fue establecida con éxito con el servidor, pero entonces se produjo un error durante el apretón de manos antes de inicio de sesión. (Proveedor: Proveedor SSL, error: 0 - La cadena de certificado fue emitido por una autoridad que no es de confianza.) (Microsoft SQL Server)

+0

Pregunta obvia: ¿Con qué autoridad/fue emitido el certificado? ¿Ha comprobado que es válido (no caducado, etc.) –

Respuesta

9

Prueba esto ...

su conseguido para ser una cuestión cliente si ha perdido la conexión a todos sus servidores remotos y sus compañeros de trabajo están bien. Probablemente haya recibido un "clic" y haya cambiado algunas configuraciones de forma involuntaria.

Abra su utilidad de red del cliente (la mía está aquí: C: \ WINDOWS \ system32 \ cliconfg.exe). En la pestaña General, echa un vistazo a los protocolos deshabilitados. Todos deben tener "cifrado de protocolo de fuerza" sin marcar. Si se comprueba si hay alguno de esos valores, es probable que su SSMS local intente forzar una conexión cifrada y fallar.

Informar si esto no funciona, y voy a hurgar un poco más.

1

Desde este enlace:

Disable client-side Force Encryption on the server. On the machine that runs the SQL Server instance, open up the SQL Server Configuration Manager, right-click SQL Native Client Configuration, and set Force Protocol Encryption to No. Then try connecting locally.

http://blogs.msdn.com/sql_protocols/archive/2005/12/22/506607.aspx

+0

en los 25 servidores? Parece que el problema está en mi máquina. Mis compañeros de trabajo todavía pueden conectarse bien, así que no creo que sea algo en los servidores. –

+0

No estoy en desacuerdo, pero si observa el problema, parece que no tiene el certificado autofirmado en el dominio registrado utilizado para autenticarse con los servidores. Eso también se menciona en este enlace. –

+0

Creo que estabas en el camino correcto aquí. De alguna manera desacredité su solución al principio porque sugirió cambiarlos en el servidor. Finalizado, no estoy usando cifrado e inadvertidamente verifiqué el cuadro de cifrado del protocolo de fuerza. ¡Gracias por tu ayuda! –

2

Se conecta a sus Servidores SQL solicitando conexiones cifradas y no confía en los certificados utilizados por esos servidores. Por qué eso sucede depende de una miríada de razones.

  • ¿Sus servidores utilizan certificados autofirmados o certificados emitidos por PKI?
  • ¿Quién es la autoridad de PKI que emitió sus certificados? ¿Es un servicio de certificado corporativo?
  • ¿Su computadora confía en la autoridad raíz de PKI?

Si no conoce las respuestas, debe ponerse en contacto con su red y con los administradores de seguridad. Simplemente deshabilitar el requisito de cumplimiento de protocolos de su cliente puede estar en contra de la política corporativa, o los servidores pueden hacer cumplir SSL sin importar su configuración local.

Estas son todas las preguntas que debe formular a los administradores de su propio entorno, no foros públicos. Debes tratar de resolver el problema, no hackear tu camino hacia el final y terminar con una máquina no conforme.

+0

"Estas son todas las preguntas que debe formular a los administradores de su propio entorno" Sí exactamente. – HLGEM

+1

Estoy un poco confundido por su comentario de que no debería hacer estas preguntas en un foro público. Estoy totalmente de acuerdo en que el problema debe ser resuelto y no un truco para una solución alternativa. –

+1

El comentario se refiere al hecho de que el problema es causado por su entorno y la solución correcta depende principalmente de sus * políticas * existentes. Si, por ejemplo, su empresa requiere que tenga conexiones cifradas a SQL Server (por ejemplo, los servidores almacenan datos médicos) y usted deshabilitó su requisito de cifrado del cliente, ha expuesto a su empleador a una demanda. O tal vez no. ¿Cómo lo sabríamos? –

13

La pregunta parece haber sido respondida, pero quería responder. Para algunos proveedores, como SQL Server, hay un parámetro en la cadena de conexión que le permite conectarse al servidor cifrado incluso si el certificado es desconocido: "TrustServerCertificate = True ", así que si incluye eso en una cadena de conexión, se conectará y trabajará encriptado, y no tendrá que ejecutar la conexión no cifrada.

+0

esto me ahorró mucho tiempo, este fue el problema exacto ... gracias galets – Bravo

0

Tengo este error, intenté conectar un servidor SQL Server remoto (SaaS) en la EM Nube he añadido una nueva regla de cortafuegos en el portal de Azure con mi IP del cliente que resolvió mi problema

Prompt
1
  • Comando Abrir : pulse la tecla de Windows + R a continuación, escriba cmd y ejecutar
  • Introduce este:

    runas/user: [YourDomainName] \ [YourActiveDirectoryUserName]/netonly cmd

  • Introduzca su contraseña de directorio activo y pulse enter

  • en Ventana Nueva Comando introduzca su SSMS.exe Ruta con doble cotation como:

"C: \ Archivos de programa (x86) \ Microsoft SQL Server \ 130 \ Tools \ Binn \ ManagementStudio \ Ssms.exe "

  • A continuación, inicie sesión con la autenticación de Windows
Cuestiones relacionadas