Cannot Create a PoolableConnectionFactory (The driver could not establish a secure connection to SQL Server using a Secure Sockets Layer (SSL) encryption.)
Problem
IBM Manta Data Lineage validation or extraction has failed with an error message stating that
Connect to database failed. Cannot create PoolableConnectionFactory (The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption.
Error: "Certificates do not conform to algorithm constraints". ClientConnectionId:1234565789)
Algorithm constraints check failed on keysize limits: RSA 1024 bit key used with certificate: CN=...
or
java.sql.SQLException: Cannot create PoolableConnectionFactory (The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption.
Error: "SQL Server did not return a response. The connection has been closed." ClientConnectionId: 123456789)
or
Caused by: javax.net.ssl.SSLHandshakeException: 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 1024 bit key used with certificate: CN=...
More Details about the Issue
The error message above means that the level of security (in this case the certificate key size) for the SSL/TLS encrypted connection required by Java used by Manta Data Lineage is higher than the certificate provided by the target application.
The security requirements for Java on Manta Server are defined:
-
In
c:\Program Files\Java\jdk-xx.xx.xx\conf\security\java.security
on Windows or/usr/lib/jvm/java-*-openjdk-amd64/conf/security/java.security
or similar on Linux. Note that the location on Linux may differ based on the Linux and Java distributions used. -
By system-level configuration in
/etc/crypto-policies/back-ends/java.config
on Linux.
Solution
There are a number of ways to resolve this issue. Here are a few options.
-
Use connection without encryption (provided that the target allows it). On Manta connection page, go to section Finetune extraction and set Connection with Encryption to false.
- In the MSSQL connection: even if
mssql.extractor.enabled.encryptConnection
property is set to false in Manta, or encryption is disabled usingencrypt=false
in the connection string, encryption can still be enforced by the driver to send login credentials to the server. For details see: https://learn.microsoft.com/en-us/sql/connect/jdbc/understanding-ssl-support?view=sql-server-ver16#remarks
- In the MSSQL connection: even if
-
Upgrade the resource’s SSL/TLS certificate on the server so that it is stronger (and provide Manta Data Lineage with the new public cert file if the certificate is self-signed or signed by a non-trusted certification authority). This is the most desired option as it is the most secure. The newly provided certificate must meet the security requirements defined in the
java.security
file for Manta Data Lineage to establish a connection with the resource. -
Reduce the level of security required by Java to allow certificates with smaller keys.
-
Check the
security.useSystemPropertiesFile
setting in the Java defaultjava.security
file and apply step #2 or #3 as follows. -
If
security.useSystemPropertiesFile=true
, then this defaultjava.security
file is overridden by the system filejava.config
(typically/etc/crypto-policies/back-ends/java.config
) for allowing TLS connections.
Check the systemjava.config
file, locate the propertyjdk.certpath.disabledAlgorithms
(if it exists) in/etc/crypto-policies/back-ends/java.config
, adjust it to match the required security level (it should suffice to simply update theRSA keySize
value to1024
), save the file, and retest the connection.
Alternatively set the property tosecurity.useSystemPropertiesFile=false
in the defaultjava.security
file to completely stop using the systemjava.config
file. -
If
security.useSystemPropertiesFile=false
, only this defaultjava.security
file should be used to control the security level; or if thejdk.certpath.disabledAlgorithms
property is not overridden injava.config
, the following steps apply.
Update thejava.security
file in Manta Data Lineage to accept a less secure certificate. In the error message above,failed on keysize limits: RSA 1024 bit key used with certificate
, the server is stating that that theRSA keysize
received is less than it is configured to accept. If you look in thejava.security
file, you will find properties similar to what is listed below, which define the acceptable RSA keySize limits.jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 2048, DSA keySize < 1024, EC keySize < 224 jdk.security.legacyAlgorithms=SHA1, RSA keySize < 2048, DSA keySize < 2048
It should be suffice to simply update the
RSA keySize
value to1024
, save the file, and retest the connection.
-
-
Reduce the level of security required by Java to allow old TLS versions and SHA1 algorithm. Reference the previous step to locate the relevant
java.security
file. Then removeTLSv1
,TLSv1.1
andTLSv1.2
fromjdk.tls.disabledAlgorithms
and add it tojdk.tls.legacyAlgorithms
. Also removeSHA1
fromjdk.certpath.disabledAlgorithms
. Save the file, and then retest the connection after restarting Manta.
java.security
file will be replaced during the update and all configuration changes will be lost. The above changes will need to be reapplied to reestablish a connection. To avoid this, you have the option of creating a custom Java
security file and placing it outside the java directory. This will reduce the chances of needing to make the above changes after each Java upgrade on the server. Implementing this however requires support/automation from administrators who upgrade
JVM. Essentially, it is needed to specify the following two properties (the second one points to the custom security file).
security.overridePropertiesFile=true
java.security.properties=/etc/sysconfig/jvm1.java.security
See, for example,
https://dzone.com/articles/how-override-java-security for more details.