Приложения Atlassian позволяют использовать SSL в наших приложениях, однако Atlassian Support не предоставляет помощь для ее настройки. Следовательно, Atlassian не может гарантировать поддержку.
- Если требуется помощь в конверсиях сертификатов, обратитесь к поставщику, предоставившему сертификат.
- Если требуется помощь в настройке, задайте вопрос в ответах Atlassian.
На этой странице описывается, как заставить веб-приложения, такие как JIRA и Confluence, подключаться к внешним серверам через SSL через различные протоколы, защищенные SSL.
Например, вы можете:
- Обратитесь к https: // ... URL в макросе Confluence.
- Используйте сервер IMAPS для получения почты в JIRA.
- Используйте SMTP через SSL (SMTPS) для отправки почты в JIRA.
- Подключитесь к каталогу LDAP через SSL.
- Настройте доверенные приложения через SSL.
Если вы хотите запустить JIRA самостоятельно через SSL, см. «Запуск приложений JIRA через SSL или HTTPS» или «Интеграция JIRA с Apache с использованием SSL».
Добавьте сертификаты SSL автоматически!
Теперь у нас есть плагин JIRA SSL Atlassian Labs для этого процесса. Пожалуйста, установите и используйте плагин перед просмотром этих документов.
Симптомы проблем
Попытка доступа к URL-адресам, зашифрованным с помощью SSL (например, HTTPS, LDAPS, IMAPS), генерирует исключение, и JIRA отказывается подключиться к нему. Например:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:441)
at javax.mail.Service.connect(Service.java:233)
at javax.mail.Service.connect(Service.java:134)
Это то же самое, что и следующая ошибка, возникающая в Chrome при посещении страницы, зашифрованной самозаверяющим сертификатом, за исключением того, что Java не может «продолжать в любом случае», она просто отказывается от сертификата:
Причина
Всякий раз, когда JIRA пытается подключиться к другому приложению через SSL (например: HTTPS, IMAPS, LDAPS), она сможет подключиться к этому приложению, если оно может доверять ей. То, как доверие обрабатывается в мире Java (это то, что написано JIRA), заключается в том, что у вас есть хранилище ключей (обычно $ JAVA_HOME / lib / security / cacerts) или также известно как хранилище доверия. Оно содержит список всех известных сертификатов CA, и Java будет доверять только сертификатам, подписанным этими сертификатами CA или общедоступными сертификатами, которые существуют в этом хранилище ключей. Например, если мы посмотрим на сертификат для Atlassian:
Мы можем видеть, что сертификат * .atlassian.com был подписан промежуточными сертификатами, DigiCert High Assurance EV Root CA и DigiCert High Assurance CA-3. Эти промежуточные сертификаты были подписаны корневым сервером безопасности CA Entrust.net. Эти три сертификата вместе называются цепочкой сертификатов. Поскольку все эти сертификаты CA находятся в хранилище ключей Java (cacerts), Java будет доверять всем подписанным им сертификатам (в данном случае, * .atlassian.com). Кроме того, если сертификат * .atlassian.com находился в хранилище ключей, Java также будет доверять этому сайту.
Эта проблема исходит из сертификата, который либо сам подписан (CA не подписывал его), либо цепочка сертификатов не существует в хранилище ключей Java. Впоследствии JIRA не доверяет сертификату и не может подключиться к приложению.
Разрешение
Чтобы разрешить это, публичный сертификат необходимо импортировать в хранилище ключей Java, которое использует JIRA. В приведенном выше примере это * .atlassian.com, и мы расскажем, как его установить ниже.
Получение и импорт открытого сертификата сервера
- Загрузите и установите приложение Portecle на сервер, на котором запущена JIRA.
Это стороннее приложение и не поддерживается Atlassian.
- Убедитесь, что переменная <JAVA_HOME> указывает на ту же версию Java, что и JIRA. См. наши документы "Установка JAVA_HOME" для дальнейшей информации относительно этого.
Если вы работаете на сервере Linux / UNIX, X11 необходимо будет перенаправлять при подключении к серверу (так что вы можете использовать графический интерфейс GUI), как показано ниже:
ssh -X user@server
- Выберите меню «Осмотр» и нажмите «Проверить соединение SSL / TLS»:
- Введите хост SSL и порт целевой системы:
- Подождите, пока он загрузится, затем выберите общедоступный сертификат и нажмите PEM:
- Экспортируйте сертификат и сохраните его.
- Вернитесь на главный экран и выберите опцию Открыть существующее хранилище ключей с диска, выберите cacerts (например, $ JAVA_HOME / lib / security / cacerts), затем введите пароль (по умолчанию - changeit).
- Выберите кнопку "Импорт доверенного сертификата в загруженное хранилище ключей":
- Выберите сертификат, который был сохранен на шаге 6, и подтвердите, что вы доверяете ему, предоставив ему соответствующий псевдоним (например: слияние).
- Вы можете столкнуться с этой ошибкой:
- Если это так, нажмите «ОК», а затем примите сертификат как доверенный.
- Сохраните хранилище ключей на диск:
- Перезапустите JIRA.
- Проверьте, что вы можете подключиться к хосту.
Установка командной строки
- Выполните сертификат, заменив google.com на полное доменное имя сервера. JIRA пытается подключиться к:
Unix:
openssl s_client -connect google.com:443 < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > public.crt
Windows:
openssl s_client -connect google.com:443 < NUL | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > public.crt
(info) Вышеуказанная команда будет выполнена только в том случае, если у вас есть Sed для Windows, а также OpenSSL, установленный в вашей среде. Если у вас нет Sed или OpenSSL или вы не хотите его устанавливать, используйте приведенные ниже инструкции в качестве альтернативы. Выполните следующую команду:
openssl s_client -connect google.com:443
Сохраните вывод в файл public.cert. Отредактируйте файл public.cert, чтобы он содержал только то, что находится между строками BEGIN CERTIFCATE и END CERTIFICATE. Вот как ваш файл должен выглядеть после того, как вы его отредактировали:
----- НАЧАЛО СЕРТИФИКАТА -----
<Содержимое сертификата, полученное с помощью командной строки.Не изменяйте этот контент, удаляйте только то, что было раньше и после СЕРТИФИКАТА BEGIN CERTIFICATE и END CERTIFICATE.Это то, что делает ваша команда Sed для вас :-)>
----- КОНЕЦ СЕРТИФИКАТА ----
- Импортируйте сертификат:
<JAVA_HOME>/keytool -import -alias <server_name> -keystore <JAVA_HOME>/lib/security/cacerts -file public.crt
Альтернативные местоположения KeyStore (хранилища ключей)
Java обычно использует общесистемное хранилище ключей в $ JAVA_HOME / jre / lib / security / cacerts, но можно использовать другое хранилище ключей, указав параметр, -Djavax.net.ssl.trustStore = / path / to / keystore , где '/ path / to / keystore' - это абсолютный путь к файлу альтернативного хранилища ключей.
Однако установка этого не рекомендуется, потому что если Java будет использовать пользовательское хранилище ключей (например, содержащее самозаверяющий сертификат), тогда у Java не будет доступа к корневым сертификатам полномочий подписи, найденным в $ JAVA_HOME / jre / lib / безопасность / cacerts и доступ к большинству SSL-сайтов с сертификатами CA не удастся. Лучше добавить новые сертификаты (например, самозаверяющие) в общесистемное хранилище ключей (как указано выше).
Отладка
Проблемы обычно являются одной из двух форм:
- Сертификат был установлен в неправильное хранилище ключей.
- Хранилище ключей не содержит сертификат службы SSL, к которой вы подключаетесь.
Смотрите также
- Настройка SSL-подключения к Active Directory
- Запуск приложений JIRA через SSL или HTTPS
- Интеграция JIRA с Apache с использованием SSL