Самоподписанные сертификаты, Java, Hudson и JIRA

Ответ 1

имя хоста используется для доступа к вашему серверу Jira (например jira.acme.com в https://jira.acme.com/) должны либо соответствовать одному из полей CN имени субъекта, либо, если это не так, один из Subject Alternative Name сертификата.

Это подробно описано в RFC 2818:

В некоторых случаях указывается URI как IP-адрес, а не Имя хоста. В этом случае iPAddress subjectAltName должно присутствовать в сертификат и должен точно соответствовать IP в URI.

В вашем случае Java жалуется, потому что ни CN ( "Неизвестный" ), ни Subject Alternative Name (поскольку у вас их нет) соответствовали имени хоста вашего сервера Jira.

Итак, сгенерируйте сертификат с соответствующим CN, например, используя keytool:

Чтобы создать пару ключей и самозаверяющий сертификат

$ keytool -genkey -alias jira_acme_com -keyalg RSA -keysize 2048 -validity 365 -keystore jira_acme_com.jks
Enter keystore password:  
Re-enter new password: 
What is your first and last name?
  [Unknown]:  jira.acme.com
What is the name of your organizational unit?
  [Unknown]:  Our project
What is the name of your organization?
  [Unknown]:  Our company
What is the name of your City or Locality?
  [Unknown]:  Our town
What is the name of your State or Province?
  [Unknown]:  NJ
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=jira.acme.com, OU=Our project, O=Our company, L=Our town, ST=NJ, C=US correct?
  [no]:  y

Enter key password for 
        (RETURN if same as keystore password): 

Просмотр личной информации

$ keytool -list -v -keystore jira_acme_com.jks 
Enter keystore password:  

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: jira_acme_com
Creation date: Sep 4, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=jira.acme.com, OU=Our project, O=Our company, L=Our town, ST=NJ, C=US
Issuer: CN=jira.acme.com, OU=Our project, O=Our company, L=Our town, ST=NJ, C=US
Serial number: 4c81e9a9
Valid from: Sat Sep 04 10:39:37 CEST 2010 until: Sun Sep 04 10:39:37 CEST 2011
Certificate fingerprints:
     MD5:  15:6A:E3:14:E2:78:F4:95:41:E6:33:C9:F8:8B:64:23
     SHA1: CD:A6:9A:84:18:E8:62:50:2C:DC:2F:89:22:F6:BA:E9:1A:63:F6:C6
     Signature algorithm name: SHA1withRSA
     Version: 3

И настроить Tomcat для использования хранилища ключей.

Of, если вы хотите создать многосетевой сертификат, вам придется использовать OpenSSL (keytool не может добавлять расширения X509, такие как альтернативное имя субъекта). Эти ссылки - отличные ресурсы:

• Создание сертификата SSL с несколькими именами хостов
• OpenSSL - Документация сообщества Ubuntu

Обновление: Учитывая, что вы не можете изменить сертификат (вы действительно должны были упомянуть об этом), временным решением может быть изменение локального файла /etc/hosts требуемых машин для решения Unknown до реального IP-устройства машины.

123.123.123.123    Unknown

Чтобы вы могли получить доступ к https://Unknown/ с этих машин. Но, очевидно, это более грязный взлом, чем реальное решение и не масштабируется.

Обращение к администраторам, чтобы получить настоящий "хороший" сертификат, по-прежнему является хорошим решением.

Ресурсы

• Несколько часто используемых команд SSL (с помощью openssl или keytool)
• Создание сертификата SSL с несколькими именами хостов
• OpenSSL - Документация сообщества Ubuntu

Ссылки

• RFC 2818
• keytool - инструмент управления ключами и сертификатами
• Apache Tomcat 6.0 - Конфигурация SSL HOW-TO

Ответ 2

Если я не ошибаюсь, SSL требует, чтобы общее имя сертификата содержало имя хоста, к которому вы пытаетесь подключиться, таким образом клиентская сторона может проверить, что сертификат не просто доверен в целом, но и доверен для местоположения.

Я предполагаю, что вы создаете сертификат с OpenSSL. Есть ли причина, по которой вы не устанавливаете cn=[yourserver]?

Может быть, когда он не может найти правильное имя хоста в общем имени, что плагин пытается найти его в имени объекта alt, а когда это не удается, потому что нет объекта subjectAltName, вы получаете плохое сообщение об ошибке.

В любом случае, если вы используете это для нескольких сайтов, вам нужно иметь имена хостов в subjectAltName. Я нашел сайт, который документирует, как правильно создать самоподписанный сертификат.

http://library.linode.com/ssl-guides/subject-alt-name-ssl

Надеюсь, что это поможет.

Ответ 3

Существует несколько возможных решений, каждый из которых имеет свой собственный набор болей.

• Создайте новый сертификат для JIRA, на этот раз указав CN при создании секретной пары ключей для certficate.

  Я не понимаю, почему новый сертификат не может быть сгенерирован; Я уверен, что другой клиент на сервере JIRA также сталкивается с некоторыми проблемами, особенно предупреждениями браузеров, для описанного сертификата. Поэтому все клиенты (и клиентские приложения) должны быть повторно протестированы, но это не боль, если самозаверяющий сертификат был выпущен локальным ЦС, которому доверяют все клиенты.

• Отредактируйте записи DNS, чтобы убедиться, что поиск "Неизвестно" с сервера Hudson указывает на сервер, на котором установлена ​​JIRA [я действительно напоминал кому-то, что есть проблемы, связанные с некоторыми из решений:-)]. Это гарантирует, что значение CN, сохраненное в сертификате, совпадает с именем хоста - вам нужно настроить Hudson для использования URL-адреса, например http://Unknown/..... И о, используйте это, только если вы находитесь в очень плотном месте; вы не хотите объяснять, почему вы это сделали.