Назад | Перейти на главную страницу

Настройка TLS сервера Crucible Fisheye Server

В течение последних нескольких дней мы пытались настроить Fisheye с настройкой TLS. Мы прошли через процесс настройки нашего TrustStore с внутренним ЦС нашей компании и создания отдельного хранилища ключей с сертификатом уровня хоста. Затем мы обновили файл config.xml настройками ssl с исключенными и включенными протоколами. Вот как это выглядит:

<web-server>
 <http bind=":80"/>
 <ssl truststore="/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts"
 keystore="/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/hosts.jks" 
 keystore-password="****" 
 bind=":443" truststore-password="*****">

<proxy-info/>

<excludeProtocols>
  <protocol>SSLv1</protocol>
  <protocol>SSLv2</protocol>
  <protocol>SSLv3</protocol>
  <protocol>TLSv1</protocol>
  <protocol>TLSv1.1</protocol>
</excludeProtocols>
<includeProtocols>
  <protocol>TLSv1.2</protocol>
</includeProtocols>
</ssl>
</web-server>

При тестировании мы продолжаем получать следующую ошибку в браузере.

Поскольку мы используем последнюю версию Chrome, я подозреваю, что это связано с шифрами или наборами шифров, которые использует веб-сервер. Однако я не смог найти никакой документации о том, как установить их для файла config.xml рыбий глаз. Я нашел пару вариантов использования обратного прокси-сервера, однако это не вариант для нас. Я также нашел статью, относящуюся к типу хранилища ключей, но это нам не помогло. Если есть документация о том, как настроить шифры или cipherSuites внутри файла config.xml. Это нам очень поможет.

Если это требует внесения изменений непосредственно в apache, мы тоже открыты для этого.

Наконец, если это неправильный форум для размещения вопросов такого типа, сообщите нам, и мы переместим его на нужный форум.

ОБНОВЛЕНИЕ 23.04.19: Тим Бригам, спасибо за руководство,

Выполняя следующую команду:

openssl s_client -connect fisheyetest.us.corp:443 -tls1_2

Получаем такой вывод:

CONNECTED(00000005)
140735531881416:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.3/libressl/ssl/s23_clnt.c:541:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 318 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
---

Похоже, что переговоры не получают шифров и не работают при попытке использовать SSLv3. Есть ли способ это изменить.

ОБНОВЛЕНИЕ: 25.04.19 После того, как вчера вечером и сегодня я ударил головой, я не смог добиться большого прогресса. Вот что я пробовал: - Удаление включенных и исключенных протоколов из файла config.xml - Проверьте разрешения хранилища ключей. - Просмотрите журналы (на предмет ошибок, связанных с TLS или SSL, или ошибок, связанных с хранилищем ключей или надежным хранилищем) - Измените тип хранилища ключей с JKS на pkcs12 и наоборот

На последнем этапе единственное, что мне удалось получить, это немного другое сообщение об ошибке:

Использование команды openssl дает такую же ошибку. Если я удалю аргумент -tls1_2, он сделает то же самое.

Я в тупике на этом. Я действительно удивлен, что это так сложно. Любые дополнительные советы будут оценены.

ssl fisheye

Прежде чем делать что-либо еще, вам нужно проверить, какие шифры на самом деле предоставляет ваш экземпляр. Есть несколько способов сделать это, используя либо openssl s_client или nmap или мое предпочтение использования Wireshark для захвата рукопожатия SSL

Как только вы определили, что именно вы предлагаете, должно быть довольно легко понять, почему ваше соединение не работает.

РЕДАКТИРОВАТЬ: на основе ваших выходных данных у вас нет сертификата сервера. Он должен быть указан почти сразу под «подключенным» выходом. Я предлагаю на время отключить все ваши записи excludeprotocol, а затем выяснить, почему ваш сертификат не представлен. Это может быть что-то столь же простое, как разрешения для хранилища ключей или / формат хранилища ключей /, требующие передачи имени сертификата.

Я смог понять это через 3 дня. Ух !. Мне пришлось включить всю цепочку сертификатов в файл p12, а затем импортировать в хранилище ключей в формате, отличном от pkcs12. Недостаточно иметь мои ссылки на CA в хранилище доверия. Вот команды, которые я использовал, чтобы заставить это работать

Сначала я создал объединенный файл в формате pkcs12 (cert.p12) с помощью следующей команды.

openssl pkcs12 -export -out cert.p12 -in host.pem -inkey key.pem -CAfile cacerts_root.pem -caname root -name jetty -certfile cacerts_int.pem

Во-вторых, создайте новое хранилище с файлом в формате pkcs12:

keytool -importkeystore -deststorepass ***** -destkeypass ***** -destkeystore /path/to/jks-file/host.p12 -srckeystore cert.p12 -srcstoretype PKCS12 -srcstorepass **** -alias jetty

Наконец, я обновил файл config.xml с соответствующими настройками:

<web-server>
<http bind=":80"/>
<ssl truststore="/path/to/trust-file/cacerts"
truststore-password="*******"
keystore="/path/to/jks-file/host.p12"
keystore-password="********" bind=":443"><proxy-info/>
</ssl>
</web-server>

Перезагрузил, и он подошел. Это была огромная боль. Не было ни журналов, ни ошибок, ни документации.

Я попробовал команду openssl

openssl s_client -connect my.web.site:443

но это не помогло. Он все время говорил мне:

No client certificate CA names sent

Должен быть какой-то лучший инструмент для диагностики этих проблем, или Atlassian / Jetty / Tomcat должны создать этот инструмент.

Спасибо