Debezium 1.7 failing to connect to SQL Server

[Thiago Dantas]

Just upgraded to 1.7 and now the connector is failing to connect to the database

From research this may be a TLS version issue

2021-10-13 16:54:50,875 TRACE  ||  Props: {server.name=meiosdepagamento__db_eldorado_batch, history.consumer.security.protocol=SSL, history.kafka.bootstrap.servers=****************, history.producer.security.protocol=SSL, password=***, history.kafka.topic=meiosdepagamento__db_eldorado_batch.history, user=*********}   [io.debezium.jdbc.JdbcConnection]

2021-10-13 16:54:50,875 TRACE  ||  URL: jdbc:sqlserver://xxx.xxx.xxx.xxx:1433;databaseName=dbEldoradoBatch   [io.debezium.jdbc.JdbcConnection]

2021-10-13 16:54:50,883 ERROR  ||  [Worker clientId=connect-1, groupId=1] Failed to reconfigure connector's tasks (meiosdepagamento__db_eldorado_batch), retrying after backoff:   [org.apache.kafka.connect.runtime.distributed.DistributedHerder]

org.apache.kafka.connect.errors.ConnectException: com.microsoft.sqlserver.jdbc.SQLServerException: 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:063ec11c-f517-4ae2-b669-36458426b24d

        at io.debezium.jdbc.JdbcConnection.lambda$createPreparedStatement$6(JdbcConnection.java:1373)

        at java.base/java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:330)

        at io.debezium.jdbc.JdbcConnection.createPreparedStatement(JdbcConnection.java:1367)

        at io.debezium.jdbc.JdbcConnection.prepareQueryAndMap(JdbcConnection.java:752)

        at io.debezium.connector.sqlserver.SqlServerConnection.retrieveRealDatabaseName(SqlServerConnection.java:427)

        at io.debezium.connector.sqlserver.SqlServerConnector.taskConfigs(SqlServerConnector.java:64)

        at org.apache.kafka.connect.runtime.Worker.connectorTaskConfigs(Worker.java:354)

        at org.apache.kafka.connect.runtime.distributed.DistributedHerder.reconfigureConnector(DistributedHerder.java:1432)

        at org.apache.kafka.connect.runtime.distributed.DistributedHerder.reconfigureConnectorTasksWithRetry(DistributedHerder.java:1379)

        at org.apache.kafka.connect.runtime.distributed.DistributedHerder.lambda$null$24(DistributedHerder.java:1392)

        at org.apache.kafka.connect.runtime.distributed.DistributedHerder.tick(DistributedHerder.java:398)

        at org.apache.kafka.connect.runtime.distributed.DistributedHerder.run(DistributedHerder.java:316)

        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)

        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)

        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)

        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

        at java.base/java.lang.Thread.run(Thread.java:829)

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: "Certificates do not conform to algorithm constraints". ClientConnectionId:063ec11c-f517-4ae2-b669-36458426b24d

        at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:2892)

        at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1881)

        at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:2452)

        at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:2103)

        at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:1950)

        at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:1162)

        at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:735)

        at io.debezium.jdbc.JdbcConnection.lambda$patternBasedFactory$1(JdbcConnection.java:237)

        at io.debezium.jdbc.JdbcConnection$ConnectionFactoryDecorator.connect(JdbcConnection.java:122)

        at io.debezium.jdbc.JdbcConnection.connection(JdbcConnection.java:891)

        at io.debezium.connector.sqlserver.SqlServerConnection.connection(SqlServerConnection.java:171)

        at io.debezium.jdbc.JdbcConnection.connection(JdbcConnection.java:886)

        at io.debezium.jdbc.JdbcConnection.lambda$createPreparedStatement$6(JdbcConnection.java:1370)

        ... 16 more

Caused by: javax.net.ssl.SSLHandshakeException: Certificates do not conform to algorithm constraints

        at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)

        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:349)

        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)

        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:287)

        at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:654)

        at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:473)

        at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:369)

        at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)

        at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)

        at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)

        at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:182)

        at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)

        at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1426)

        at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1336)

        at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)

        at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)

        at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1799)

        ... 27 more

Caused by: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints

        at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1681)

        at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1606)

        at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1550)

        at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:638)

        ... 39 more

Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on signature algorithm: SHA1withRSA

        at java.base/sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:237)

        at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1677)

        ... 42 more

[Thiago Dantas]

It seems from 1.6 to 1.7 the java.security disabled a bunch more algorithms

1.6: in /usr/lib/jvm/java-11-openjdk-11.0.8.10-0.el7_8.x86_64/conf/security/java.security

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \

EC keySize < 224, 3DES_EDE_CBC, anon, NULL

1.7: in /usr/lib/jvm/java-11-openjdk-11.0.12.0.7-4.fc34.x86_64/conf/security/java.security

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \ 

DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \

include jdk.disabled.namedCurves

I tried rolling back these parameters in the java.security file but still it didn't work

After a lot of googling I found out about a file at /etc/crypto-policies/back-ends/java.config which overrides java.security which is not present in the 1.6 image.

jdk.tls.disabledAlgorithms=DH keySize < 2048, SSLv2, SSLv3, TLSv1, TLSv1.1, DHE_DSS, RSA_EXPORT, DHE_DSS_EXPORT, DHE_RSA

_EXPORT, DH_DSS_EXPORT, DH_RSA_EXPORT, DH_anon, ECDH_anon, DH_RSA, DH_DSS, ECDH, 3DES_EDE_CBC, DES_CBC, RC4_40, RC4_128,

DES40_CBC, RC2, HmacMD5

 

In it, I found the culprit. Although TLSv1 and 1.1 should be disabled by now, there is no replacement for them in this specific database so I rolled these back as well

I'm not a java guy and this was quite a complicated troubleshooting experience for me.

[Thiago Dantas]

Maybe this should be documented as a breaking change?

[Suhas Saheer]

Hi Dan,

We are also facing same error while using Debezium 1.8

We had to downgrade to 1.6 and then it started working after updating java.security

By the way, were you successful in running it in 1.7 or any higher version after this incident?

- Suhas

[Gopinath Varadarajan]

We are facing same/similar issue in 1.9.2 version.

java version "1.8.0_241"
Java(TM) SE Runtime Environment (build 8.0.6.7 - pxa6480sr6fp7-20200312_01(SR6 FP7))
IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20200219_440062 (JIT enabled, AOT enabled)
OpenJ9   - 3088245
OMR      - eb95a4d
IBM      - 83517b6)
JCL - 20200310_01 based on Oracle jdk8u241-b07

{"error_code":400,"message":"Connector configuration is invalid and contains the following 1 error(s):\nUnable to connect. Check this and other connection properties. Error: 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:595894cc-d7c7-4b6b-a433-b60e8ed933d1\".\nYou can also find the above list of errors at the endpoint `/connector-plugins/{connectorType}/config/validate`"}

Where can we update the java security in this version?

Any other ways to fix this issue?

Thanks,

Gopi

[Jürgen Albersdorfer]

Hi,

I had the same issue from Version 1.7 and higher.

I found out that this is caused by some `system-wide cryptographic policies` in the `RedHat Enterprise Linux` docker base image, which seem to override the settings mentioned by @dan in  

`in /usr/lib/jvm/java-11-openjdk-11.0.8.10-0.el7_8.x86_64/conf/security/java.security`

To fix this, try the following:

connect to the docker container as `root`

```

docker exec --user root -it connect /bin/bash

```

Then issue the following commands as root to check and change the active `system-wide cryptographic policy`

```

bash-5.1# update-crypto-policies --show
DEFAULT

bash-5.1# update-crypto-policies --set LEGACY
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

```

Then exit the Container and restart it

```

docker restart connect

```

Then, I was able to connect to the SQL Server again as I could with Version 1.6.

I tried this with the most current Version Tag `debezium/connect:1.9.2.Final`

Hope this helps you too.

Regards,

Jürgen

[Jürgen Albersdorfer]

Additional Reading for anybody interested: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

[Gopinath Varadarajan]

Thanks a lot  Jürgen.  We are using "Oracle Linux Server 7.9"
searching for similar command for this version, so far unable to find, if you know please update.

Thanks again.

Gopi

[Jürgen Albersdorfer]

Hi,

I found the "other" config files by searching the whole filesystem for files containing the "jdk.tls.disabledAlgorithms".

Then I googled/quacked the file paths and found the Article by RedHat. So maybe just try the same:

grep -RiP "^\s*jdk.tls.disabledAlgorithms=" /

Good Luck

[Bün]

Hello,

I just wanted to say thank you. I was having the same issue with mssql jdbc connector (Linux distribution we use is redhat 8) but the core reason is same. So I checked the link you shared and solved the problem with a single command:

update-crypto-policies --set LEGACY

This way it reduces security and my issue is resolved.

Thanks.

18 Mayıs 2022 Çarşamba tarihinde saat 17:11:01 UTC+3 itibarıyla Jürgen Albersdorfer şunları yazdı: