Наборы шифров DSA не поддерживаются встроенным причалом 9.4 в java

Я использую последнюю версию причала и jdk, она должна поддерживать наборы шифров DSA, такие как TLS_DHE_DSS... Итак, я создал файл сертификата и пары ключей с алгоритмом DSA, загрузил его на свой сервер и перезапустил свой сервер, сервер успешно запустился. . Но после этого я не мог использовать какой-либо браузер, чтобы открыть какую-либо страницу этого сервера. Все, что я увидел, это сообщение об ошибке на странице: ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Может ли кто-нибудь помочь мне с этим? Есть ли проблема с причалом для DSA?


java jetty dsa
person enbo tang    schedule 17.02.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Нет смысла спамить как stackoverflow, так и проблемы github (мы платим внимание обоим)

Что касается DSA в вашем инструменте/хранилище ключей, вы не можете использовать его для SSL/TLS (не поддерживается Jetty, Java и даже самими различными версиями протокола SSL/TLS. DSA — это просто алгоритм подписи/проверки, он не t к шифрованию/дешифрованию/обмену ключами, необходимыми для SSL/TLS).

Используйте RSA для хранилища ключей и укажите алгоритм SHA256 (или выше) и разрядность 4096 (или выше).

Сбросьте свой стартап и посмотрите, почему интересующие вас шифры отключены.

$ cd /path/to/my/jettybase
$ java -jar /path/to/jetty-dist/start.jar jetty.server.dumpAfterStart=true

Найдите дерево SslContextFactory и ветвь Cipher Suites. В разделе Disabled будут перечислены все отключенные наборы шифров, а также указано, где был отключен этот конкретный набор шифров.

Ты увидишь...

  • JreDisabled что означает, что сама JVM отключила его.
  • ConfigExcluded, что означает, что в вашей конфигурации ${jetty.base} он отключен.

В любом случае вы захотите просмотреть Включение/отключение определенных наборов шифров в документации, чтобы понять, как настроить их в соответствии с вашими конкретными потребностями.

person Joakim Erdfelt    schedule 17.02.2017

arrow_upward
0
arrow_downward

У меня аналогичная проблема со встроенным Jetty в OpenNMS.Захват Wireshark, показывающий шифры, предлагаемые браузером

Насколько я могу судить, существует несколько общих шифров и версий TLS между тем, что предлагается браузером, и тем, что поддерживается Jetty, и все же Jetty отклоняет соединение с приведенным выше сообщением об ошибке несоответствия шифра. Похоже, что все три основных браузера дают сбой аналогично с ошибкой Fatal Hanshake (TLS1.2). Однако использование имени хоста, отличного от FQDN, для создания несоответствия имени хоста/домена позволяет пользователю настроить исключение сайта и TLS для «успешного выполнения» с TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA и TLS v1.2. Поэтому может показаться, что проблема не в шифрах. Что-то еще в рукопожатии вызывает сбой Jetty, и браузеры неверно интерпретируют ответ как несоответствие шифра.

Из постстартового дампа Jetty:

 |   |   += SslContextFactory@629464ad(file:///opt/opennms/etc/jetty.keystore,file:///opt/opennms/etc/jetty.keystore) trustAll=false
 |   |   |   +- Protocol Selections
 |   |   |   |   +- Enabled (size=3)
 |   |   |   |   |   +- TLSv1
 |   |   |   |   |   +- TLSv1.1
 |   |   |   |   |   +- TLSv1.2
 |   |   |   |   +- Disabled (size=2)
 |   |   |   |       +- SSLv2Hello - ConfigExcluded:'SSLv2Hello'
 |   |   |   |       +- SSLv3 - JreDisabled:java.security, ConfigExcluded:'SSLv3'
 |   |   |   +- Cipher Suite Selections
 |   |   |       +- Enabled (size=42)
 |   |   |       |   +- TLS_DHE_DSS_WITH_AES_128_CBC_SHA
 |   |   |       |   +- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
 |   |   |       |   +- TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
 |   |   |       |   +- TLS_DHE_DSS_WITH_AES_256_CBC_SHA
 |   |   |       |   +- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
 |   |   |       |   +- TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
 |   |   |       |   +- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
 |   |   |       |   +- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
 |   |   |       |   +- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
 |   |   |       |   +- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
 |   |   |       |   +- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
 |   |   |       |   +- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
 |   |   |       |   +- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
 |   |   |       |   +- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
 |   |   |       |   +- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
 |   |   |       |   +- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
 |   |   |       |   +- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 |   |   |       |   +- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
 |   |   |       |   +- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
 |   |   |       |   +- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 |   |   |       |   +- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
 |   |   |       |   +- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
 |   |   |       |   +- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 |   |   |       |   +- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
 |   |   |       |   +- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
 |   |   |       |   +- TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
 |   |   |       |   +- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
 |   |   |       |   +- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
 |   |   |       |   +- TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
 |   |   |       |   +- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
 |   |   |       |   +- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
 |   |   |       |   +- TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
 |   |   |       |   +- TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
 |   |   |       |   +- TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
 |   |   |       |   +- TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
 |   |   |       |   +- TLS_EMPTY_RENEGOTIATION_INFO_SCSV
 |   |   |       |   +- TLS_RSA_WITH_AES_128_CBC_SHA
 |   |   |       |   +- TLS_RSA_WITH_AES_128_CBC_SHA256
 |   |   |       |   +- TLS_RSA_WITH_AES_128_GCM_SHA256
 |   |   |       |   +- TLS_RSA_WITH_AES_256_CBC_SHA
 |   |   |       |   +- TLS_RSA_WITH_AES_256_CBC_SHA256
person ppanon    schedule 03.04.2017