it-roy-ru.com

Firefox "ssl_error_no_cypher_overlap" ошибка

У меня и моих коллег возникли проблемы с использованием Firefox 3.0.6 для доступа к веб-приложению Java 1.6.0 ___ 11, которое мы разрабатываем. Все отлично работает где-то от 1-30 минут до сеанса ... но в конце концов, соединение не удается, и появляется следующая ошибка:

Secure Connection Failed 

An error occurred during a connection to 10.x.x.x.

Cannot communicate securely with peer: no common encryption algorithm(s).

(Error code: ssl_error_no_cypher_overlap)

IE работает нормально. Firefox выдает ошибку как в Windows, так и в Fedora, поэтому проблема, похоже, не связана с ОС. Приложение Java EE работает на сервере Tomcat 6.0.16. Все страницы зашифрованы с использованием TLS 1.0 через HTTP-сервер Apache 2.2.8 с mod_nss.

Наш сервер Apache настроен на отклонение соединений SSL 3.0. У нас есть одна гипотеза, что Firefox может пытаться установить соединение SSL 3.0 ... но почему?

Основываясь на некоторых Google, мы попробовали следующее, но безуспешно:

  • используя Firefox 2.x (некоторые люди сообщали о случаях, когда 2.x работал, но 3.x не работал):

  • включение SSL2

  • отключение SSL3

  • отключение OCSP (Инструмент> Параметры> Дополнительно> Шифрование> Проверка)

  • обеспечение того, чтобы антивирус/брандмауэр клиентского компьютера не блокировал или не сканировал порт 443 (порт https)

Есть идеи?

17
Michael

У меня была такая же проблема при обновлении сертификата для нашего сервера на www.tpsynergy.com. После импорта нового сертификата сервера и перезапуска Tomcat мы получили ошибку ERR_SSL_VERSION_OR_CIPHER_MISMATCH. После долгих исследований я использовал эту ссылку https://www.sslshopper.com/certificate-key-matcher.html , чтобы сравнить csr (запрос на подпись сертификата с действительным сертификатом). Они оба не совпадали. Поэтому я создал новый CSR, получил новый сертификат и установил тот же. Это сработало.

Таким образом, полные шаги для процесса

  1. На том же сервере, где будет установлен сертификат, создайте CSR

keytool -keysize 2048 -genkey -alias Tomcat -keyalg RSA -keystore tpsynergy.keystore (при необходимости измените имя домена)

При создании, он будет запрашивать имя и фамилию. Не указывайте свое имя, а используйте доменное имя. Например я дал это как www.tpsynergy.com

2.keytool -certreq -keyalg RSA -alias Tomcat -file csr.csr -keystore tpsynergy.keystore

Это создаст файл csr.csr в той же папке. скопируйте содержимое этого сайта на godaddy и создайте новый сертификат.

  1. Загруженный Zip-файл сертификата будет иметь три файла Gd_bundle-g2-g1.crt Gdig2.crt Youractualcert.crt

  2. Вам нужно будет скачать корневой сертификат gdroot-g2.crt из хранилища godaddy.

  3. Скопируйте все эти файлы в тот же каталог, откуда вы создали CSR-файл и где находится файл хранилища ключей.

  4. Теперь выполните одну из следующих команд, чтобы импортировать сертификаты в хранилище ключей.

    keytool -import -trustcacerts -alias root -file Gd_bundle-g2-g1.crt -keystore tpsynergy.keystore

    keytool -import -trustcacerts -alias root2 -file gdroot-g2.crt -keystore tpsynergy.keystore

    keytool -import -trustcacerts -alias промежуточный -file gdig2.crt -keystore tpsynergy.keystore

    keytool -import -trustcacerts -alias Tomcat -file yourdomainfile.crt -keystore tpsynergy.keystore

  5. Убедитесь, что файл server.xml в папке conf содержит эту запись

     

  6. Перезагрузите Tomcat

7
Srinivasan Rajagopalan

Учитывая то, что вы пробовали, и сообщения об ошибках, я бы сказал, что это больше связано с точным алгоритмом шифрования, а не с версией TLS/SSL. Используете ли вы случайно не JRE Sun или реализацию безопасности другого поставщика? Попробуйте другую JRE/OS, чтобы проверить ваш сервер, если можете. В противном случае вы можете просто увидеть, что происходит с Wireshark (с фильтром 'tcp.port == 443').

5
alexh

Если вы просмотрите процесс согласования SSL в Википедии, вы узнаете, что в начале сообщения ClientHello и ServerHello отправляются между браузером и сервером.

Только если шифры, представленные в ClientHello, имеют перекрывающиеся элементы на сервере, сообщение ServerHello будет содержать шифр, который поддерживают обе стороны. В противном случае соединение SSL не будет инициировано, так как не существует общего шифра.

Чтобы решить эту проблему, вам нужно установить шифры (обычно на уровне ОС), вместо того, чтобы прикладывать большие усилия к браузеру (обычно браузер опирается на ОС). Я знаком с Windows и IE, но мало знаю о Linux и Firefox, поэтому я могу только указать, что не так, но не могу предложить вам решение.

3
Lex Li

У меня были похожие проблемы с просмотром защищенных сайтов (https: //) при использовании Burp (или, по крайней мере, проблема, которая привела бы вас на эту страницу при поиске в Google):

  • ssl_error_no_cypher_overlap в Firefox
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH в Chrome

Оказалось, проблема с с использованием Java 8 . Когда я переключился на Java 7, проблема прекратилась.

1
SharpC

Первое, что я хотел бы проверить, это конфигурация для mod_nss. Это странный случай, потому что он ваш, и в мире нет ни одного подобного :-) Принимая во внимание, что если бы в Firefox или самом mod_nss была какая-то огромная ошибка, я думаю, вы уже узнали об этом в своем гугл квест. Тот факт, что вы поиграли с конфигурацией (например, отключили SSL3 и другие случайные изменения), также вызывает подозрение.

Я бы вернул трек к самому конфигурационному модулю Vanilla mod_nss и посмотрел, работает ли он. Затем систематически изменяйте вещи в соответствии с текущей конфигурацией, пока не сможете воспроизвести проблему. Судя по всему, источник ошибки находится где-то в конфигурации конфигурации шифра mod_nss и связанных с ним согласованиях протоколов. Поэтому, возможно, вы случайно изменили что-то там, когда пытались отключить SSLv3 (кстати, зачем отключать SSL3? Обычно люди отключают V2?).

Еще одна вещь, которую нужно проверить, это то, что вы используете последнюю версию mod_nss, и это не известная ошибка в этом. Интересен тот факт, что ему удается запустить сеанс, а затем завершиться неудачей - это говорит о том, что, возможно, он пытается пересмотреть сеанс и не может согласовать шифры в этот момент. Так что это могут быть симметричные шифры. Или это может быть просто ошибка реализации в вашей версии mod_nss, которая каким-то образом искажает протокол.

Еще одна идея, и это дикое предположение, заключается в том, что браузер пытается возобновить сеанс, который был согласован с SSLv3 до того, как вы его отключили, и что-то не работает, когда попытка возобновить этот сеанс, когда V3 выключен, или, возможно, mod_nss просто не не правильно реализовать.

Материал Java/Tomcat выглядит как красная сельдь, поскольку, если я не понял ваше описание, ничего из этого не относится к рукопожатию/протоколу SSL. 

0
frankodwyer

Под расширенными настройками Firefox вы должны иметь возможность установить шифрование. По умолчанию должны быть проверены SSL3.0 и TLS1.0, поэтому, если firefox пытается создать подключения ssl 3.0, попробуйте снять флажок ssl 3.0s.

если это не сработает, попробуйте поискать по странице about: config для "ssl2" Мой Firefox имеет настройки с ssl2, установленным в false по умолчанию ... 

0
nchris