共用方式為

The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption.

  • 發行項

What is SSL and why is my JDBC driver using it?

The v1.2 JDBC driver uses SSL (Secure Sockets Layer) to encrypt connections to SQL Server for improved security. Where it can, the v1.2 driver ALWAYS uses SSL to encrypt the login to SQL Server. For integrated auth connections, SSL provides an added layer of security. For SQL auth, where the user name and password would otherwise be sent in the clear, SSL provides an essential layer of security.

 

I trust that my network is secure without SSL... How do I turn off SSL encryption?

You can control whether a connection encrypts all data to and from the server after login using the ‘encrypt’ connection property. However, where it can, the v1.2 driver ALWAYS uses SSL to encrypt the login to SQL Server. You cannot disable SSL encryption of the SQL Server login.

 

Ok, but I upgraded to v1.2 and now I can’t connect! Why am I getting the error “The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: …”?

Odds are good that your Java SSL setup is messed up somehow.

 

SSL in Java is provided through the Java Secure Socket Extension (JSSE). Its reference guide (for J2SE 5) is here: https://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html . A key aspect of JSSE is its pluggable provider model. Typically, JRE vendors supply JSSE provider implementations. There are at least two main JSSE providers available out there and they do not necessary work well together.

 

For SSL to work at all, it is absolutely necessary to have the JSSE providers configured correctly for the JRE you are using. There are two steps to this:

1) Look at the java.security file in your JRE installation (typically found in the jre\lib\security directory). The installed security providers are listed in that file as security.provider.x=… where ‘x’ is the priority used. For Sun JRE installations, the first priority provider should be Sun’s. E.g.: you should have the line “security.provider.1=sun.security.provider.Sun” in that file. For other JRE's, please refer to the JRE's documentation regarding their default provider name. We recommend when using the IBM JRE to specify the "com.ibm.jsse.IBMJSSEProvider" as the first security provider to use.

2) Next, make sure that the classpath points to the correct JAR files (in the jre\lib directory) for use with those providers. For Sun, the classpath should include jsse.jar. For IBM, should include ibmjsse.jar.

 

If either the classpath or the java.security file is not correct, SSL will not work. Not just with SQL Server, but with anything else either.

 

SSL works for other apps, just not with JDBC. And I’ve verified that the classpath is correct… Check certificates

If you are going to configure SQL Server to use a server certificate, then that certificate needs (or the certificate of one of its trusted issuing authorities) needs to be present in Java’s certificate store. If the certificate isn’t there, chances are that your JSSE provider will give you a nice descriptive, if sometimes cryptic, error. Configuring the client for use with SSL is covered in our docs here https://msdn2.microsoft.com/en-us/library/bb879943.aspx . Some certificates are quite large and trip up older JSSE providers. Of course there may be other VMs out there with similar problems, but we are not able to verify all of them. A smaller certificate may help in this case.

 

Not a configuration problem or a certificate problem. Now what.

When contacting Microsoft to help us be effective, we need to be armed with the following info:

1) The complete text of the error message. I.e. including the part after “Error: …” above.

2) A stack trace (if available).

3) A complete log (if available) containing FINEST TDS-level traces leading up to the error. In particular, the following loggers should be enabled in the logging properties:

com.microsoft.sqlserver.jdbc.TDSChannel.level = FINEST

com.microsoft.sqlserver.jdbc.TDSReader.level = FINEST

com.microsoft.sqlserver.jdbc.TDSWriter.level = FINEST

com.microsoft.sqlserver.jdbc.TDS.DATA.level = FINEST

               Generating the log file with the XMLFormatter is preferred over SimpleFormatter, as it gives us more info.

4) The java.security file that was used.

5) Vendor and version of the JRE used.

6) SQL Server version

7) The connection string/connection properties used.

David Olix & Jimmy Wu

SQL Server JDBC Team

Comments

  • Anonymous
    October 10, 2008
    Amigos espero que apoyen en la URL tengo lo siguiente: jdbc:sqlserver://IT-D106-002:8080;databaseName=DBSisCobrita01 y me arroja el siguiente error para conectarme a la Base de Datos. la respuesta de inicio de sesión previo TDS esta imcompleta. El servidor de destiono debe ser SQL server 2000 o posterior Nota estoy trabajando con SQL server 2005, NetBeans 6.1 y el driver sqljdbc_2.0 mi correo es eduansm@hotmail.com Gracias por la ayuda.

  • Anonymous
    October 16, 2008
    The thing is this just doesn't really do it for me, prefer something a little less... mainstream.

  • Anonymous
    November 05, 2009
    I still having the “The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: …”? I'm developing a program in Netbean to connect to SQL Server 2005. Previously is working fine but then suddenly it unable to connect. Now my application is not working. I check the java.security file, do have this. security.provider.1=sun.security.provider.Sun Please advise.

  • Anonymous
    November 06, 2009
    Hi Adrian, What is the complete error message?  The part of the message that you omitted is probably important to the diagnosis.  What version of the JDBC driver are you using?  What JRE vendor & version?  What are the other security provider entries?  For example, the Sun 1.4.2 JRE java.security file may have these entries: security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.net.ssl.internal.ssl.Provider security.provider.3=com.sun.rsajca.Provider security.provider.4=com.sun.crypto.provider.SunJCE security.provider.5=sun.security.jgss.SunProvide Try enabling Java's SSL debugging facilities: http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Debug Regards, --David Olix [SQL Server]

  • Anonymous
    February 03, 2011
    The comment has been removed

  • Anonymous
    April 27, 2011
    Hi Satheesh, How did you add that directory to your classpath and the -Djava.ext.dirs" parameters?

  • Anonymous
    December 31, 2011
    In case somebody wonders, MS Driver trips over the latest SSL BEAST Fix from Oracle in 1.6.0_29 and _30. You can turn that off with the java system property -Djsse.enableCBCProtection=false, but this is not recommended. In jTDS you can use "ssl=no" (unless server is configured to force encryption). With encrypt=false it wont work for MS JDBC Driver (since it always encrypts login).

  • Anonymous
    January 11, 2012
    @post on Dec 31 2011 The connection issues with 1.6.0_29 are known.  Watch this blog post for updates on this topic. blogs.msdn.com/.../supported-java-versions-november-2011.aspx

  • Anonymous
    May 06, 2014
    The comment has been removed

  • Anonymous
    September 09, 2014
    My fb isn't comin in..if I goggle facebook it says couldn't establish a secure connection but I can goggle anything else.  So what should I do ..I rebooted my wifi for 3 min.. it works beside that..what is rhe problem..oh I have wifi wild blue  can anyone help

  • Anonymous
    August 11, 2015
    I will allow myself this very old thread, here in 2015 - because so far Microsoft technology gives me a huge headache and a lot of frustration: stackoverflow.com/.../invalidkeyspecexception-on-deploying-ear-file-containing-entitybeans-and-using sqljdbc2 - is just incapable of connecting to SQL Server, when used from within Glassfish. Don't know why.

  • Anonymous
    February 08, 2016
    Hi, you can also make sure that your class path is well formed: Meaning that you have to ensure the colons ':' and semi-colons ';' are situated in the right places correctly separating each class path variable.

  • Anonymous
    January 05, 2017
    Today we have found a solution to this exception after 3 days of work and finally microsoft's assistance. The vendor we are working with have informed me about the application server's priorities for encryption has been changed due to some update on microsoft virtual machine. Our app was using java 1.6.045 with its own security priorities. They applied these rules/priorities for java on the server today. So this problem was all about transport layer securiy(TLS) priorities for app server.