Настройка 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 fisheye. Я нашел пару пробок использования обратного прокси-сервера, однако, это не вариант для нас. Я также нашел статью, связанную с типом хранилища ключей, но это нам не помогло. Если есть какая-либо документация о том, как настроить шифры или наборы шифров внутри файла config.xml. Это помогло бы нам значительно.
Если это требует внесения изменений непосредственно в apache, мы также открыты для этого.
Наконец, если это неправильный форум для публикации вопросов такого типа, пожалуйста, сообщите нам, и мы переместим его на правильный форум.
ОБНОВЛЕНИЕ 4/23/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, он делает то же самое.
Я поставлен в тупик на этом. Я очень удивлен, что это так сложно. Любые дополнительные советы будут оценены.
3 ответа
Я смог понять это через 3 дня. Тьфу!. Мне пришлось включить всю цепочку сертификатов в файл p12, а затем импортировать в хранилище ключей в формате, отличном от pkcs12. Недостаточно, чтобы мои ссылки были в магазине доверия. Вот команды, которые я использовал, чтобы заставить это работать
Сначала я сгенерировал комбинированный файл в формате 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 должен создать этот инструмент.
Спасибо
Прежде чем делать что-либо еще, вам нужно проверить, какие шифры на самом деле предоставляет ваш экземпляр. Есть несколько способов сделать это, используя либо openssl s_client или nmap, либо мои предпочтения использовать Wireshark для захвата рукопожатия SSL
После того, как вы точно определили, что вы предлагаете, должно быть довольно легко понять причину сбоя вашего соединения.
РЕДАКТИРОВАТЬ: На основе вашего вывода у вас нет сертификата сервера, представленного. Он должен быть указан почти прямо под "подключенным" выходом. Я бы предложил на время отключить все ваши записи excludeprotocol, а затем выяснить, почему ваш сертификат не представлен. Это может быть что-то столь же простое, как разрешения для хранилища ключей или / format для хранилища ключей /, требующие передачи имени сертификата.
У нас была такая же проблема с очень тихой пристанью.
Решение было наконец: хранилище доверенных сертификатов JKS должно содержать ключ (частный/открытый) с тем же паролем, что и само хранилище доверенных сертификатов JKS.