-
Notifications
You must be signed in to change notification settings - Fork 371
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't Connect to Server, TCP Provider: Error code 0x2746. #1453
Comments
Which version of OpenSSL are you using? |
Looks like all of those are fine. Can you look at the server event log right after a failed attempt to see what it says? |
Sadly I haven't been granted access to the server yet, I'm working on that. What feels odd is even the cli trying to make a connection through TLS v1 where my system is configured to allow a minimum of v1.2 (the default) like the JDBC dirver does. Should I attach my openssl conf?. Also, is there a way to force the TLS version through ODBC config? I feel that could work. |
Can you provide contents of the Client Hello, Server Hello, Client Key Exchange, and Change Cipher Spec from the Wireshark log, for both working and non-working case? We need to see what the client and server are negotiating. Microsoft ODBC Driver should use the system setting for TLS, maybe Devart ODBC doesn't? I'm not familiar with it, so it'll be interesting to see what they negotiate differently. |
I have similar problem on RHEL 9, it's probably caused by unexpected eof. I tried to block access to OpenSSL 3 library forcing libmsodbcsql use OpenSSL 1.1 (for compat-openssl11 package) and everything works as expected.(blocked by mounting custom /usr/lib64 in cgroup) Building OpenSSL with forced SSL_OP_IGNORE_UNEXPECTED_EOF helps to get working openssl s_client :1433 without needing -ignore_unexpected_eof but not for msodbcsql... maybe it`s not unexpected_eof after all. |
We have same problem with OpenSSL 3.0.8, MS ODBC Driver 17, unixODBC2.3.11, SQL Server 2014. Client keeps waiting for 'Server Hello' but server doesn't reply. Even openssl is not able to connect to sql server, not even sslcan shows the server ciphers. Everything works with OpenSSL 1.1.1. Also the client uses TLSv1 with OpenSLL 3.0.8 but it's TLSv1.2 with OpenSLL 1.1.1 !!! @Lathanderjk Did you find a solution to it? Could you please share the steps? |
SQLServer could provide a library that could use by C/C++/PHP/ODBC/Ruby/Nodejs/JDBC? ODBC is not friendly for App, can't package it directly, and it's huge. |
Just run this in your shell: |
Works for me on In /etc/ssl/openssl.cnf file : 1/ change 2/ add those lines at the end of file
Then test it with
|
worked for me on same environment, thank you! |
A cleaner solution for RHEL9: update-crypto-policies --set LEGACY You might have to reboot afterwards. |
PHP version
PHP 8.1
PHP SQLSRV or PDO_SQLSRV version
PHP sqlsrv 5.111
Microsoft ODBC Driver versions tested
[ODBC Driver 18 for SQL Server]
libmsodbcsql-18.2.so.1.1
[ODBC Driver 17 for SQL Server]
libmsodbcsql-17.10.so.2.1
SQL Server version
SQL Server 2014 SP3 - Windows Server 2012
Client operating system
Fedora 38
Problem description
![image](https://private-user-images.githubusercontent.com/125930135/239284778-2d211142-2b36-481e-bd0b-c6f2b0195324.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjI1NjY0NzEsIm5iZiI6MTcyMjU2NjE3MSwicGF0aCI6Ii8xMjU5MzAxMzUvMjM5Mjg0Nzc4LTJkMjExMTQyLTJiMzYtNDgxZS1iZDBiLWM2ZjJiMDE5NTMyNC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODAyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgwMlQwMjM2MTFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wMjUxMzU0YWI3YjM5MGNkNDFkMGNlNjllNTUxNmU2ODZmMjQ5ZmMzMGM4Zjk0YjNjZjMyMDIzYzNlODJhNDlmJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.01hkesJdZNNOlyfM3bP2kGm1INcKHN9Fgp6dVROX39c)
I'm trying to connect to a Windows Server machine that has a SQL Server 2014 SP3 instance, but neither php driver or sqlcdm cli connect to the server because they use TLS v1 in the ssl negotiation where TLS v1.2 should be used as shown in the packet trace. The connection gets terminated by the server
Expected behavior and actual behavior
The connection to the server should be made using TLS v1.2, as shown in this packet trace generated from a connection using DBeaver with the Microsoft JDBC SQL Server driver.
Tried changing the openssl.cnf file to have
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=0
## tried with 1 too
# CipherString = DEFAULT@SECLEVEL=1
but none of these worked, the connection is still forced to use TLS v1
The text was updated successfully, but these errors were encountered: