Почему мы получаем ошибку метабазы при подключении к SQL Server 2016 на Red Hat Enterprise Linux 9, но не на Red Hat Enterprise Linux 7?

Мы заметили, что Java-приложение Metabase выдает ошибку при подключении к SQL Server 2016, и с той же конфигурацией проблема возникает в Red Hat Enterprise Linux 9, но не в Red Hat Enterprise Linux 7. Мы надеемся получить помощь, чтобы подтвердить, связано ли это с операционной системой, и исправить это.

Длинная история:

Мы тестируем обновленную версию Metabase, и обновленные компоненты включают

• операционную систему Red Hat Enterprise Linux (с версии 7 до версии 9),
• Java (с 11 до 21), и
• программное обеспечение Metabase (с версии 0.32.x до текущей версии 0.50.x).

И мы заметили следующую ошибку в обновленной версии при подключении к источнику данных SQL Server 2016.

Свойство “encrypt” установлено в “false”, а свойство “trustServerCertificate” установлено в “false”, но драйвер не смог установить безопасное соединение с SQL Server с использованием шифрования Secure Sockets Layer (SSL): Ошибка: Сертификаты не соответствуют алгоритмическим ограничениям. ClientConnectionId:6bf62750-d5c4-49c5-8ada-4253d8b55055

Мы подозреваем, что ошибка связана с поведением системы Red Hat Enterprise Linux 9, поэтому мы разработали следующий упрощенный тестовый случай для поддержки нашей точки зрения:

Тестовая конфигурация:

• Java openjdk v11.0.23
• metabase.jar v0.32.5

Мы запускаем приложение, вызывая команду java -jar metabase.jar, так что оно запускает свежий демонстрационный экземпляр Metabase на локальном H2 для базы данных приложения.

Затем мы пытаемся добавить источник данных SQL Server 2016, настроенный так, чтобы шифрование не требовалось.

Работая в Red Hat Enterprise Linux 7, вышеуказанный тест прошел успешно. Однако, работая в Red Hat Enterprise Linux 9, он завершился неудачей со следующими лог-событиями, обратите внимание на временную метку 12-19 14:58:44:

12-19 14:58:09 DEBUG middleware.log :: GET /api/setup/admin_checklist 200 14 ms (10 DB calls) Jetty threads: 8/50 (3 busy, 5 idle, 0 queued) (48 total активных потоков)
12-19 14:58:44 INFO metabase.driver :: Инициализация драйвера :sqlserver...
12-19 14:58:44 DEBUG plugins.classloader :: Установка текущего контекста загрузчика классов потока в общий загрузчик классов clojure.lang.DynamicClassLoader@1dc9fc0...
12-19 14:58:44 INFO plugins.classloader :: Добавлен URL file:/data/metabase-test/v0.32.5/plugins/sqlserver.metabase-driver.jar в classpath
12-19 14:58:44 DEBUG plugins.init-steps :: Загрузка пространства имен плагина metabase.driver.sqlserver...
12-19 14:58:44 INFO metabase.driver :: Зарегистрирован драйвер :sqlserver (родители: :sql-jdbc) 🚚
12-19 14:58:44 DEBUG plugins.jdbc-proxy :: Регистрация драйвера прокси JDBC для класса com.microsoft.sqlserver.jdbc.SQLServerDriver...
Загрузка ленивого драйвера :sqlserver заняла 173 мс
12-19 14:58:44 DEBUG middleware.log :: POST /api/database 400 314 ms (0 DB calls) Jetty threads: 8/50 (3 busy, 4 idle, 0 queued) (45 total активных потоков)
{:valid false,
 :dbname
 "com.microsoft.sqlserver.jdbc.SQLServerException: Драйвер не смог установить безопасное соединение с SQL Server с использованием шифрования Secure Sockets Layer (SSL). Ошибка: \"Сертификаты не соответствуют алгоритмическим ограничениям\". ClientConnectionId:ca179b99-b3b3-4351-a0de-736b7dc8e765",
 :message
 "com.microsoft.sqlserver.jdbc.SQLServerException: Драйвер не смог установить безопасное соединение с SQL Server с использованием шифрования Secure Sockets Layer (SSL). Ошибка: \"Сертификаты не соответствуют алгоритмическим ограничениям\". ClientConnectionId:ca179b99-b3b3-4351-a0de-736b7dc8e765"}

12-19 14:58:44 DEBUG middleware.log :: GET /api/database 200 5 ms (3 DB calls) Jetty threads: 8/50 (3 busy, 4 idle, 0 queued) (45 total активных потоков)
12-19 15:00:00 INFO task. Send-pulses :: Отправка запланированных пульсов...

Нам интересно, пропустили ли мы что-то относительно новой операционной системы, и мы очень ценим любые подсказки и советы.

Дополнительная информация

О TLS:

У тестируемого SQL Server 2016 нет установленного SSL-сертификата, и он настроен как “шифрование не требуется”.

• Мы проверили Windows-хост в контексте “SQLServerManager13.msc > Настройка сети SQL Server > Протоколы для MSSQLSERVER > Свойства”. “Принудительное шифрование” установлено в Нет, и в вкладке “Сертификат” ничего нет.
• Команда openssl s_client выводит следующие результаты:

  # openssl s_client -connect <sql-server-hostname>:1433 -showcerts
  Connecting to xxx.xxx.xxx.xxx
  CONNECTED(00000003)
  001EA5D0C87F0000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:689:
  ---
  no peer certificate available
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 0 bytes and written 309 bytes
  Verification: OK
  ---
  New, (NONE), Cipher is (NONE)
  This TLS version forbids renegotiation.
  Compression: NONE
  Expansion: NONE
  No ALPN negotiated
  Early data was not sent
  Verify return code: 0 (ok)
  ---
  

О версии SQL Server:

При всем том же для работы Metabase мы протестировали добавление источника данных на SQL Server 2022 вместо 2016, и тест прошел на RHEL9.

О различиях в java.security:

Справка:

• https://stackoverflow.com/questions/14149545/java-security-cert-certificateexception-certificates-does-not-conform-to-algori

Мы извлекли файлы java.security как из RHEL7, так и из RHEL9, затем отфильтровали комментарии и пробелы, чтобы получить чистое содержание.

Сравнивая два файла java.security.11.rhel7.txt java.security.11.rhel9.txt, мы заметили следующую часть в различиях.

$ diff java.security.11.rhel7.txt java.security.11.rhel9.txt
...

33a35
> security.useSystemPropertiesFile=true
59,60c61,63
< jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
<     DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
---
> jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, \
>     MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
>     ECDH, \
...

Если это вам интересно, пожалуйста, посмотрите полные результаты различий ниже.

$ diff java.security.11.rhel7.txt java.security.11.rhel9.txt
12a13,16
> fips.provider.1=SunPKCS11 ${java.home}/conf/security/nss.fips.cfg
> fips.provider.2=SUN
> fips.provider.3=SunEC
> fips.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS-FIPS
23a28
> fips.keystore.type=PKCS11
26,28c31
<                sun.reflect.,\
<                org.GNOME.Accessibility.,\
<                org.GNOME.Bonobo.
---
>                sun.reflect.
30,32c33
<                    sun.reflect.,\
<                    org.GNOME.Accessibility.,\
<                    org.GNOME.Bonobo.
---
>                    sun.reflect.
33a35
> security.useSystemPropertiesFile=true
59,60c61,63
< jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
<     DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
---
> jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, \
>     MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
>     ECDH, \
86c89
< jdk.security.caDistrustPolicies=SYMANTEC_TLS
---
> jdk.security.caDistrustPolicies=SYMANTEC_TLS,ENTRUST_TLS