Приложения 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 на сервер или выбрать командную строку, см. Раздел «Установка командной строки» ниже.
Получение и импорт открытого сертификата сервера
Это стороннее приложение и не поддерживается Atlassian.
Если вы работаете на сервере Linux / UNIX, X11 необходимо будет перенаправлять при подключении к серверу (так что вы можете использовать графический интерфейс GUI), как показано ниже:
ssh -X user@server
- Вы можете столкнуться с этой ошибкой:
- Если это так, нажмите «ОК», а затем примите сертификат как доверенный.
Установка командной строки
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