We Keep Coding

Issue with disabling protocols in java.security file

I have springboot application deployed on jetty server and running on java 8. I want to force my application to use TLSv1.3 only. For this in the java.security file of jre I disabled all protocols except TLSv1.3 with below property:
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, 3DES_EDE_CBC, DESede, \
EC keySize < 224, DES40_CBC, RC4_40, TLSv1, TLSv1.1, TLSv1.2
When I tried to start jetty, it gave me below error:
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "No appropriate protocol, may be no appropriate cipher suite specified or protocols are deactivated". ClientConnectionId:de77b523-984a-4700-a19b-ccfd0407dfb4
at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1748)
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1704)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:1401)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:1068)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:904)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:451)
at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:1014)
at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:138)
at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:364)
at com.zaxxer.hikari.pool.PoolBase.newPoolEntry(PoolBase.java:206)
at com.zaxxer.hikari.pool.HikariPool.createPoolEntry(HikariPool.java:476)
at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:561)
I am not using secure connection to DB. Below is application.properties file entry for DB:
spring.datasource.url=jdbc:sqlserver://172.20.186.175:1433;Databasename=DB_Jan_2023_new;SendStringParametersAsUnicode=false
spring.datasource.username=sa
spring.datasource.password={ENC}ACED0005740003414553757200025B42ACF317F8060854E0020000787000000008E3425FF8F9E058D0737200116A6176612E6C616E672E496E746567657212E2A0A4F781873802000149000576616C7565787200106A6176612E6C616E672E4E756D62657286AC951D0B94E08B0200007870000008007571007E000100000010B2E212D690ECC67BC4663C4DFEE3542C74000456322E30
spring.datasource.driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
spring.jpa.hibernate.dialect=org.hibernate.dialect.SQLServer2012Dialect
Q1. I am not sure why it is giving this error though I am not using secure connection.
Q2. Also, is this the right way to move application to TLSv1.3 or there are some more steps ?
Q3. How can I check if my application moved to TLSv1.3 ?

SQL Server TDS protocol version 8 is required for TLS 1.3 per the documentation. TDS 8 was introduced with SQL Server 2022 and is not available in other versions. Furthermore, only the latest ODBC and OLEDB client drivers have added support for TDS 8 as of this writing. TLS 1.3 not yet available with the Microsoft JDBC driver.

Overriding Java security properties on a Dataproc cluster to overcome SSL handshake issue with MS SQL 2019

I am stuck with a problem with Java security setting preventing my Dataproc cluster (Image 2.0.32-debian10) running PySpark to connect to SQL Server 2019 with Spark/JDBC connector (spark:spark.jars.packages=com.microsoft.azure:spark-mssql-connector_2.12:1.2.0 and sqljdbc4-2.0.jar). It seems the security level of the cluster and SQL Server 2019 (running on a GCE) do not match and there is this SSL/TLS error during handshake.
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The driver
could not establish a secure connection to SQL Server by using Secure
Sockets Layer (SSL) encryption. Error: "No appropriate protocol
(protocol is disabled or cipher suites are inappropriate)".
at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1368)
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1412)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:1058)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:833)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:716)
at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:841)
I could bypass this by using Jupyter Notebook to directly modify "Local Disk/usr/lib/jvm/temurin-8-jdk-amd64/jre/lib/security/java.security" and comment out this part of the code "jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA,
DH keySize lessThan 1024, EC keySize lessThan 224, 3DES_EDE_CBC, anon, NULL,
include jdk.disabled.namedCurves", and I will be able to connect to SQL Server successfully.
However this would work only if my Dataproc cluster is a single node cluster. If it's a standard cluster (e.g. 1 master+2 workers), it seems the node doesn't recognize this change in security properties and I faced the same error as before (perhaps because the job is distributed to a worker node which does not recognize the change in java.security in the master node local disk).
I tried passing these as the cluster properties hoping it would apply the change in security properties to worker nodes as well:
spark:spark.driver.extraJavaOptions='-Djava.security.properties==gs://greenline-demo-341617-spark-src/Demo/02_Microsoft_SQL/java.security',spark:spark.executor.extraJavaOptions='-Djava.security.properties==gs://greenline-demo-341617-spark-src/Demo/02_Microsoft_SQL/java.security'
But I'm stuck at this error instead 🤣
Exception in thread "main" java.lang.InternalError: internal error:
SHA-1 not available.
at sun.security.provider.SecureRandom.init(SecureRandom.java:108)
at sun.security.provider.SecureRandom.(SecureRandom.java:79)
at java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:198)
at java.security.SecureRandom.(SecureRandom.java:162)
at java.util.UUID$Holder.(UUID.java:96)
at java.util.UUID.randomUUID(UUID.java:142)
Connection string url_db = "jdbc:sqlserver://10.148.xx.xx:1433;databaseName=AdventureWorks2019;sslProtocol=TLSv1;encrypt=false"

how to fix The server selected protocol version TLS10 is not accepted by client preferences [TLS12]

I want to run a spring boot application with a sql server data base but when I run it, the following error appears :
com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "The server selected protocol version TLS10 is not accepted by client preferences [TLS12]". ClientConnectionId:73ea4fa4-e772-4fd7-90f5-d617aec091f2
at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:2924) ~[mssql-jdbc-7.4.1.jre8.jar:na]
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1881) ~[mssql-jdbc-7.4.1.jre8.jar:na]

TLS 1.2 must be configured on SQL Server: https://support.microsoft.com/en-us/topic/kb3135244-tls-1-2-support-for-microsoft-sql-server-e4472ef8-90a9-13c1-e4d8-44aad198cdbe

how can force intellij to work with specific TLS version?

got this annoying error when trying to connect new local mssql data source in intellij .
( getting same error when trying to connect from code )
[08S01] The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "Server chose TLSv1, but that protocol version is not enabled or not supported by the client.". ClientConnectionId:ffbe4d7e-70b5-4123-ad9a-36decc62858a javax.net.ssl.SSLHandshakeException: Server chose TLSv1, but that protocol version is not enabled or not supported by the client.
some details :
all mssql services are running .
intellij 2019.3 (can connect to remote mssql but cannot to one defined locally )
mssql installed locally 2014
project jdk jdk1.8.0_241
mssql driver - 7.4.1
spring-jdbc:5.1.2
connection string - jdbc:sqlserver://localhost:1433;database=local-test
another thing :
i got this error when trying to connect to remote mssql and by adding the port the issue was fixed ( doesnt work locally ) .
Thanks .

Cannot connect to SQL Server server with MS JDBC Driver from CentOS 8 server: SSL error but not using secure connection

I found one article that was close to the issue I am experiencing. It is this one:
SQL Server JDBC Error on Java 8: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption
I can provide the entire stack trace but the pruned version has this series of errors:
com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "java.security.cert.CertificateException: Certificates do not conform to algorithm constraints". ClientConnectionId:e7a5ebc2-d489-4743-85ba-7873926508fe
Caused by: javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: Certificates do not conform to algorithm constraints
Caused by: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints
Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on keysize limits. RSA 1024bit key used with certificate: CN=SSL_Self_Signed_Fallback. Usage was tls server
The JDBC connection is to a SQL Server 2012 that does NOT have connection encryption enabled or any security that I know of. I talked to our DB guy and he says there is no security on the connection that he knows of. So, I am not sure WHY the MS driver continues to complain about the SSL connection.
This Linux server (CentOS 8) has two tomcat installations that use JDBC connections. I have a Tomcat 8.0.32 instance that connects to the SQL Server 2012 instance using the JTDS driver that has no problem at all in connecting. I tried switching that driver to the MS driver and it then experienced the same errors. So I switched it back. But the second installation of Tomcat (9.0.33) has an app that requires a JDBC 4.0 or above driver and the JTDS driver is only a 3.0 driver so I have to use the MS driver. But, I cannot figure out how to get a successful connection.
Digging through the Internet I found reference to the jsse.jar and having the correct certs installed (although nothing specific as to how to do it or why). I also dug of an article that said that the JTDS driver uses NTLM to connect (not 100% sure about that since I have no reference to a domain in my connection for JTDS). In any case, I just need some guidance on how to configure the MS driver to connect from Linux to a non-secured SQL Server 2012. The Microsoft references I found addressed secured connections but nothing about connections that were not secured.
Running Java version:
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
url=jdbc:sqlserver://192.168.80.214:1433;databaseName=DB_Central;
integratedSecurity=true;authenticationScheme=NTLM;domain=mydomain.org;
Also tried:
url=jdbc:sqlserver://192.168.80.214:1433;databaseName=DB_Central;encrypt=false;sslProtocol=TLSv1.2;
And just:
url=jdbc:sqlserver://192.168.80.214:1433;databaseName=DB_Central
JTDS that works (in the tomcat 8.0.32 / JDBC 3.0 environment):
driverClassName=net.sourceforge.jtds.jdbc.Driver
url=jdbc:jtds:sqlserver://192.168.80.214:1433;databaseName=DB_Central
ANYTHING that might point me in the right direction would be helpful especially why the MS driver wants (or thinks) the connection is secure. The other tidbit is that I see none of these errors when deployed to Windows 10...so it has something to do with Linux and maybe the Java config on Linux. Or, maybe I just need the correct incantation for the connection string when in Linux.....

The driver believes that the connection is secure , if it is connecting to a port that is meant to receive only secure connections.
1.Check the port
2.Check for any other explicit setting of TLS / SSL on the JDBC url

So, the way I was able to get this to work after much trial and error was to copy the java.security file from the windows 10 install to the CentOS 8 install. The ONLY thing I can see as different between the two was in this section:
'# List of comma-separated packages that start with or equal this string
'# will cause a security exception to be thrown when
'# passed to checkPackageDefinition unless the
'# corresponding RuntimePermission ("defineClassInPackage."+package) has
'# been granted.
'#
'# by default, none of the class loaders supplied with the JDK call
'# checkPackageDefinition.
'#
The entries in CentOS included at the end of the list:
org.GNOME.Accessibility.,\
org.GNOME.Bonobo.
The entries in the Windows version had only one entry at the end:
com.sun.java.accessibility.
That was the only difference I could find. And, I don't understand why that made a difference.. But it DOES connect without error now and that is all I wanted....

spend quite some time to solve the connection issues between centos 8 with tomcat and jdbc:sql server 2014.
I replaced the self-signed certificate in the properties of protocols in sql server configuration.
It is misleading that you can't see it on windows. It's only visible in the tomcat catalina.out file - use debug with -Djavax.net.debug=ssl:handshake:all.
You have to prepare a certificate from an authority (a self-signed should also work) and store it in local computer - own certificate of the windows server.
Make sure the service account of sql server has access right on the private key of the certificate. Otherwise, the sql service will not start.
Restart sql server.
Add the certificate and chain to your tomcat configuration cacerts file.
add -Djavax.net.ssl.trustStore= and -Djavax.net.ssl.trustStorePassword= to setenv.sh
The string in the webapps web.xml had to be as simple as:
jdbc:sqlserver://yourURL;DatabaseName=yourDB;user=youruser;password=secret
[other options did not work and led to further exceptions: integratedSecurity=true;encrypt=true;trustServerCertificate=true - trustStore=storeName;trustStorePassword=storePassword
and i've tried all boolean options i.e.: false/true]
Restart tomcat

It has to do something with openjdk version of java. We have switched to amazon correto 1.8 you can find it here, and everything worked perfectly.

If anyone having the same problem at a Redhat 8 Linux, below command worked for me (it lowers the security)
update-crypto-policies --set LEGACY