- Нужно ли нам связать промежуточный сертификат и root с нашим сертификатом домена и развернуть его (сертификат в формате pfx)
Вы должен обязательно настроить сервер для отправки всех необходимых промежуточных сертификатов; это требуется стандартами TLS. (Хотя, если вы этого не сделаете, у клиентов есть опция , чтобы попытаться получить их другими способами, такими как кэш или репозиторий или AIA, и иногда они делают.) Является ли сервер отправляет root необязательно; стандарты фактически утверждают это в обратном порядке, говоря, что сервер МОЖЕТ опустить root, где все заглавные буквы «МОГУТ» использовать значение, определенное в RF C 2119. Например, для TLS1.2 в RFC5246 7.4. 2 :
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
То, как вы делаете это, зависит от того, какое программное обеспечение веб-сервера вы используете, которое вы не определили. Хотя из того факта, что вы указываете Java версию, я могу предположить, что может быть Tomcat или чем-то, основанным на Tomcat, например Jboss / Wildfly. Даже в этом случае конфигурация SSL / TLS Tomcat существенно различается в зависимости от версии и типа используемого стека соединителя (чистая Java JSSE или Tomcat Native, также называемая APR Apache Portable Runtime, которая фактически является OpenSSL) , Тем не менее, файл 'pfx' (PKCS12) может определенно содержать как приватный ключ, так и соответствующий сертификат (EE) ПЛЮС сертификата (ов) цепочки, который ему необходим , и является удобным способом работы со всем kaboodle. сразу.
Для сертификата, полученного непосредственно от GoDaddy, они предоставляют инструкции, связанные с https://www.godaddy.com/help/install-ssl-certificates-16623 для многих распространенных серверов. Я не знаю, если для Azure они используют какую-либо другую цепочку, которая изменит эти инструкции.
Если ваш сервер общедоступен, на порту 443 https://www.ssllabs.com/ssltest проверит, это правильно обрабатывает цепочки сертификатов, а также многое другое. Есть и другие инструменты, но я не знаком с ними; для не публикуемых c серверов я обычно просто смотрю вручную.
Рекомендуется ли указывать нашим клиентам устанавливать сертификаты комплекта (root и промежуточные), чтобы это работало.
Клиенты не должны устанавливать промежуточный сертификат ( s) потому что, как указано выше, сервер должен их отправлять. Корни GoDaddy были приняты в большинстве официальных трестов в течение нескольких лет, поэтому большинству клиентов, использующих настройки по умолчанию, не нужно добавлять их. Тем не менее, некоторые могут; в частности, Ubuntu 16.04 может быть достаточно старым, чтобы на нем не было предустановлено GoDaddy. И любой клиент (клиенты), желающий использовать настроенное хранилище доверенных сертификатов и / или пин-код, должен убедиться, что он настроен на включение / разрешение цепочки доверия вашего сертификата.
Нужно ли GoDaddy обновлять сертификат комплекта в репозиториях Ubuntu, Alpine или я неправильно понимаю
GoDaddy поставил свои корни (AFAIK все) основные доверенные программы, как указано выше. IINM Ubuntu использует список Mozilla / NSS, который сегодня определенно включает GoDaddy, но, как и выше, я не уверен насчет 16.04. Я не знаю, для альпийских. Центры сертификации не требуют, чтобы программы хранилища доверенных сертификатов включали промежуточные продукты (хотя программа или пользователь могут добавлять выбранные промежуточные продукты в качестве доверенных в зависимости от используемого программного обеспечения).