we've been facing an issue while connecting to Azure PostgreSQL Database from our application when SSL is turned on and TLS set to 1.2. However, we were able to connect to the database successfully when TLS is set to 1.0, which is no longer recommended version. we're facing issue especially when creating or retrieving the Quartz jobs.
Are there any parameters that can be set in the connection string if we're using an older version of the drivers?
we've the below in our application:
WPF
Quartz 1.0.3.3
NHibernate
Fluent NHibernate
Castle.Facilities.NHibernateIntegration
Npgsql 4.1.5
Error:
Failed to obtain DB connection from data source XXXXXX:
Npgsql.NpgsqlException:TLS version used does not meet minimal requirements for this server. Please use a higher TLS version and retry.
Severity: FATAL
Code: 28000
at Npgsql.NpgsqlConnector.CheckErrors() at
Npgsql.NpgsqlConnector.Open() at
Npgsql.NpgsqlConnectorPool.GetPooledConnector(NpgsqlConnection
Connection) at
Npgsql.NpgsqlConnectorPool.RequestPooledConnectorInternal(NpgsqlConnection
Connection) at
Npgsql.NpgsqlConnectorPool.RequestPooledConnector(NpgsqlConnection
Connection) at
Npgsql.NpgsqlConnectorPool.RequestConnector(NpgsqlConnection
Connection) at Npgsql.NpgsqlConnection.Open()
at Quartz.Impl.AdoJobStore.JobStoreSupport.GetConnection()'
Inner Exception:
NpgsqlException: FATAL: 28000: TLS version used does not meet minimal requirements for this server. Please use a higher TLS version and retry.
Related
Here is how Database url is given : jdbc:postgresql://Hostname:portnumber/dbname
Kept the following jar file in C:\Program Files\Apache\apache-jmeter-5.0\lib
postgresql-9.1-901-1.jdbc4.jar
I am getting the below error in JMeter when trying to connect AWS postgres db in JMeter.
Cannot create PoolableConnectionFactory (FATAL: no pg_hba.conf entry for host "xxx", user "xxuser", database "xxname", SSL off).
Can it be the case you have SSL enabled in your PostgreSQL cluster? Looking at Requiring an SSL/TLS connection to an Aurora PostgreSQL DB cluster chapter
If you enable set rds.force_ssl and restart your DB cluster, non-SSL connections are refused with the following message:
psql: FATAL: no pg_hba.conf entry for host "host.ip", user "someuser", database "postgres", SSL off
So it might be the case you just need to enable SSL in your JDBC URL like:
jdbc:postgresql://Hostname:portnumber/dbname?ssl=true
Otherwise just add the following entry to your pg_hba.conf file:
hostnossl all all 0.0.0.0/0 trust
and upon Postgres restart you will be able to connect from anywhere by anyone without SSL
Also according to 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure and JMeter Best Practices you should always be using the latest version of JMeter so consider upgrading to JMeter 5.4.1 (or whatever is the latest stable version available at JMeter Downloads page)
I am having trouble using .net connector (https://github.com/snowflakedb/snowflake-connector-net). It works from browser/Tableau/Excel. For tableau/excel I have to pass CaBundleFile.
Is there a way to pass a certificate file (CaBundleFile) using the .net connector?
I am getting following error.
System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: Could not
establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
Unlike the ODBC driver, Snowflake doesn’t perform OCSP checking for .NET driver which uses the underlying .NET framework for checking validity of the HTTPS certificate.
One thing that might help is looking through similar GitHub issues for ideas (they discuss upgrading and network traces):
https://github.com/snowflakedb/snowflake-connector-net/issues/6
You might also try looking at some of the Microsoft docs and forums for the error on some troubleshooting ideas:
https://learn.microsoft.com/en-us/archive/blogs/jpsanders/troubleshooting-asp-net-the-remote-certificate-is-invalid-according-to-the-validation-procedure
Is there any relation between TLS_RSA_WITH_AES_128_GCM_SHA256 cipher and SQL Server?
When TLS_RSA_WITH_AES_128_GCM_SHA256 is disabled, ASP.NET application cannot connect to SQL Server. Although SQL Server is still running, SQL Server Management Studio also cannot connect to database. The following error is shown in SSMS.
A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - No process is on the other end of the pipe.) (.Net SqlClient Data Provider)
Read TLS 1.2 support for Microsoft SQL Server, identify the SQL Server version you use, download and apply the relevant components from the article linked, try again:
Use the following table to determine whether your current version of SQL Server already has support for TLS 1.2 or whether you have to download an update to enable TLS 1.2 support. Use the download links in the table to obtain the server updates that are applicable to your environment.
As a result of TLS 1.0 being phased out, we're starting to implement additional security on our servers. Primarily, explicitly disabling TLS 1.0 client and server (and SSL 1/2/3), and explicitly enabling TLS 1.2 and 1.1. In addition, we're restricting the ciphers available for use when connecting over TLS 1.2/1.1.
We followed the article Remus posted to the letter (https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server), and used additional resources to ensure we weren't missing anything (this was a good one: https: //blogs.sentryone.com/aaronbertrand/tls-1-2-support-read-first/). We also forced .NET Framework to use TLS 1.2->1.1->1.0 search order by adding the SchUseStrongCrypto registry keys on our servers (https://technet.microsoft.com/en-us/library/security/2960358.aspx).
Despite the above, we were unable to connect to SQL 2014 or SQL 2016 instances on a Windows Server 2016 environment when attempting to connect from a Windows Server 2012 R2 environment. We had a SharePoint installation in Windows 2012 R2 that was unable to connect to its database, and we were unable to connect to the instances with SSMS on this same server. Connecting via SSMS from a Windows 10 or another Server 2016 installation worked. Here's the error we were getting:
sql server Error Number: 10054 Severity: 20 State: 0
A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 – An existing connection was forcibly closed by the remote host.)
Once we allowed a TLS_RSA cipher for use on both servers, we were able to connect (didn't matter which cipher we used, we used the first one in this list):
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
I'm unable to find any resource which explicitly states which ciphers are required for communication to SQL Server, I'm assuming the above list isn't comprehensive. I'd like a definitive resource of some sort, but wanted to post this in case it helps someone.
I am trying to create / modify a system data source for my application which needs to connect to our Microsoft SQL Express 2014 database through an ODBC data source.
The connection used to work before we enabled the SSL encryption flow but,
now that we have an encrypted link, the connection does not work anymore.
Here are some details:
We run Microsoft SQL Server express 2014 SP1 with the latest cumulative update (CU #3) (which was necessary so that we could deactivate SSL 3.0 and TLS 1.0 and run only with TLS 1.1 and TLS 1.2)
The database instance is a named instance, configured to run with a TCP/IP connection and a fixed port.
We enabled the "Force Encryption" option and configured the certificate through the "Sql Server Configuration Manager"
We can successfully establish a connection to the database either using Management Studio or the SQL command line utility
We disabled all usage of SSL/TLS prior to version TLS 1.1 done through Microsoft Schannel. This required us to update SQL Express 2014 SP1 to the latest cumulative update (CU #3)
The ODBC data source we try to configure (through ODBC data source Administrator) is a "System DSN" and uses the "SQL server" driver and target the exact same server name as the one working in management studio (and whose server name corresponds to the machine FQDN which is reflected in the certificate CN value)
The Version indicated for the SQL Server ODBC driver is "Microsoft SQL Server ODBC Driver Version 06.03.9600"
I am testing the connection directly through the ODBC data source Administrator tool.
The first test I runs are run on the exact same machine as the one hosting the database server.
We get two consecutive error message in the Microsoft SQL Server Login:
Connection failed:
SQLState : '01000'
SQL Server Error: 771
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]ConnectionOpen(SECDoClientHandshake()).
Connection failed:
SQLState : '08001'
SQL Server Error: 18
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SSL Security error.
I went through all the literature I could find but cannot find a solution.
EDIT 27/01/2016 16:30
Following erg suggestion, I tried to use the last MS SQL Server Native Client version (11.00.2100 on my system), but it still does not resolve the issue. I experience another issue though (whether or not I force the strong encryption on the client side results in the same error):
Running connectivity tests...
Attempting connection
[Microsoft][SQL Server Native Client 11.0]TCP Provider: An existing connection was forcibly closed by the remote host.
[Microsoft][SQL Server Native Client 11.0]Client unable to establish connection
TESTS FAILED!
So, I finally got it working after struggling a little bit more.
First of all, it appears that there is another CU available (CU4) for SQL Server Express 2014 SP1.
I did download it and install it, but it did not resolve my problem: as soon as I deactivated TLS 1.0 and below version ODBC did not work.
Strangely, though the CU3 and installation of .NET 4.6 allowed me to successfully log in in Management Studio, when I tried to execute
the xp_readerrorlog query, it actually failed.
What I did to solve my issue was to follow malthus's answer on another related stack overflow question
https://dba.stackexchange.com/questions/93127/sql-server-service-won-t-start-after-disabling-tls-1-0-and-ssl-3-0 (3rd answer from the top).
I therefore activated the local security policy on my computer and managed to get the links to my SQL db working.
Now, I got IIS working along my own service and client working.
BTW, if somebody needs a more user friendly way of activating SSL/TLS version(s) and cryptographic algorithms on Windows, I stumbled uppon a nice GUI application which does not required to use regedit for it:
https://www.nartac.com/Products/IISCrypto. It's free and I am not a a Nartac Software employee, manager or shareholder.
I hope this will help!
EDIT Feb 25, 2016
It looks like the latest cumulative update (CU5 available at
https://support.microsoft.com/en-us/kb/3130926) removes the need to
activate the FIPS option for the System Cryptography.
I discovered this since I had to deactivate FIPS to enable another required
functionnality while still relying on a TLS 1.2 connection. Indeed, it
appears that activating the FIPS option for the System Cryptography prevents
.NET Framework to successfuly make use of some system algorithms (such as
SHA256Managed).
In addition, according to some discussions seen around the web (i.e.
http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recommending-fips-mode-anymore.aspx)
it is not recommended to activate FIPS (except to strictly comply with
some governmental recommendations) since it breaks applications
relying on non-FIPS validated implementations of cryptographic
algorithms, which, however are provided in Microsoft system libraries.
I am using pentaho data integration 4.1 (Kettle) to build an ETL system. My customer requires connecting to database (MS SQL Server) using window authentication, I knew that Kettle supported it . However when I run my Kettle job, it throws the exception
"I/O Error: SSO Failed: SSPI Not Initialized".
From an article on a forum, I copy library sqljdbc_auth.dll into jre/bin folder. The result is quite good, I can use window authentication to connect to SQL server. But this function is not stable, I mean sometimes it works well, sometimes it throws exception
"I/O Error: SSO Failed: SSPI Not Initialized".
Please tell me how to fix this error.
Thank you.
To connect to SQL Server 2008, I had to install the 'Microsoft JDBC Driver 4.0 for SQL Server' and then add the path to sqljdbc_auth.dll to Spoon.bat in %PENTAHO_DI_JAVA_OPTIONS%. Like this:
set OPT=%PENTAHO_DI_JAVA_OPTIONS% "-Djava.library.path=%LIBSPATH%;C:\PROGRA~1\MICROS~1.0FO\sqljdbc_4.0\enu\auth\x86;C:\PROGRA~1\IBM\SQLLIB\BIN" "-DKETTLE_HOME=%KETTLE_HOME%" "-DKETTLE_REPOSITORY=%KETTLE_REPOSITORY%" "-DKETTLE_USER=%KETTLE_USER%" "-DKETTLE_PASSWORD=%KETTLE_PASSWORD%" "-DKETTLE_PLUGIN_PACKAGES=%KETTLE_PLUGIN_PACKAGES%" "-DKETTLE_LOG_SIZE_LIMIT=%KETTLE_LOG_SIZE_LIMIT%"
Ugly, but that's Java under Windows for you. Works quite reliably now though.
Are you using the JTDS driver? Try that combined with the ntlmauth.dll - that works great for us when running PDI on Windows Server 2003 connecting to various remote sqlserver databases.
We place the DLL in this folder:
libswt\win64
I've had the same issue while using JDBC 1.2.2 with MSSQL 2008. It turns out that there is a bug in the driver, making it randomly crash if you initialize it with more than one connection.
If we used only one initial connection to the DB this error never presented itself.
The issue is fixed in a later versions of JDBC. We currently use 1.3.0 and I/O Error: SSO Failed: SSPI Not Initialized never comes up.