Как сделать промежуточный сертификат

Добавил пользователь Skiper
Обновлено: 04.10.2024

Что такое SSL-сертификат и зачем он нужен

Таким образом, наличие SSL-сертификата (в совокупности с грамотной настройкой сервера) гарантирует:

конфиденциальность, целостность и аутентификацию, что делает обмен информацией безопасным;
подлинность ресурса, что повышает уровень доверия посетителей и поисковиков.

Типы SSL-сертификатов

Существует несколько типов SSL-сертификатов.

Сертификат с проверкой домена (Domain Validation), например, DomainSSL или AlphaSSL. Самый простой и дешевый тип SSL-сертификатов. Подтверждает только домен. Не содержит информации о владельце, поэтому не предназначен для оказания коммерческих услуг на сайте. Физические лица могут использовать только этот тип сертификатов, но он доступен и для юридических лиц.

Сертификат с расширенной проверкой организации (Extended Validation) – например, ExtendedSSL. Считается самым надёжным и предназначен для крупных организаций. При его оформлении центр сертификации проведет расширенную проверку налоговой и коммерческой деятельности компании. Выпуск сертификата займет продолжительное время (от 5 дней до нескольких недель) в том числе, в зависимости от скорости предоставления необходимых документов центру сертификации.

Еще один термин, который встретится при выборе сертификата – WildCard. Он означает поддержку поддоменов. Один SSL-сертификат с WildCard сможет работать и на основном домене, и на поддоменах без ограничений на их количество.

При заказе сертификатов Extended Validation или Organization Validation, центр сертификации может запросить следующие виды документов:

Свидетельство ИНН / КПП;
Свидетельство ОГРН;
Приказ о назначении директора;
Свидетельство о регистрации доменного имени;
Устав организации (первые 3 и последние 3 страницы);
Счета на оплату телефонных разговоров с номера компании за последние 3 месяца, с обязательным указанием в счетах названия и номера телефона организации и названия организации-поставщика услуг.

Что нужно сделать чтобы установить SSL-сертификат

В зависимости от используемого хостинга или сервера часть шагов может отличаться или отсутствовать, но в целом классический процесс получения и установки сертификата сводится к следующим шагам:

приобрести SSL-сертификат;
сгенерировать CSR запрос на сертификат;
выпустить SSL-сертификат;
установить SSL-сертификат на хостинг или сервер;
внести изменения в настройки сайта.

Приобретение SSL-сертификата

Итак, вы знаете, что такое SSL и определились в выборе сертификата, далее его нужно приобрести.

Купить SSL-сертификат можно напрямую у одного из удостоверяющих центров, например Comodo , Thawte , GeoTrust . Однако проще всего это сделать у вашего хостинг-провайдера, где располагается домен, сервер, сайт.

На этапе покупки укажите тип сертификата и домен для которого он приобретается. Затем оплатите сертификат.

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

Генерация CSR запроса на сертификат

CSR (Certificate Signing Request) – это зашифрованный запрос на получение сертификата, включает в себя информацию о домене и организации.

CSR может быть сгенерирован одним из способов:

В независимости от способа, в результате вы должны получить 2 файла (или их текстовое содержание) — файл запроса (domain.csr) и файл приватного ключа (private.key). Файл запроса потребуется для генерации сертификата. А приватный ключ понадобится в дальнейшем, его вместе с сертификатом нужно будет установить на хостинг или сервер.

Первые два способа не должны вызвать трудностей, генерация на собственном сервере описана ниже, но для начала несколько важных замечаний:

Все данные запроса должны заполняться на английском языке.

Далее при генерации запроса CSR вам потребуется указать адрес электронной почты. Рекомендуется заранее создать почтовый ящик вида admin@domain, administrator@domain, hostmaster@domain, postmaster@domain или webmaster@domain и указать в контактных данных его. Этот же адрес пригодится позже для подтверждения владения доменом.

Генерация CSR запроса на собственном сервере

Потребуется криптографический пакет с открытым исходным кодом – OpenSSL . Он входит в состав большинства UNIX-подобных операционных систем.

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

Подключитесь к серверу по SSH и перейдите в домашнюю директорию.

Сгенерируйте закрытый ключ.

private.key – выходной файл, который будет содержать ключ;
4096 – размер ключа, резже 2048.

Закрытый ключ будет создан и сохранен в файл под именем private.key.

Сохраните копию закрытого ключа на своем компьютере. При компрометации ключа или утрате пароля сертификат придется перевыпустить.

Далее сгенерируйте CSR запрос.

private.key – созданный на предыдущем этапе закрытый ключ;
domaine.csr – выходной файл с CSR запросом.

Далее последовательно латинскими символами укажите следующие данные:

CSR запрос на сертификат будет сохранен в файле domain.csr в виде закодированного текста.

Проверить корректность введенных данных можно, выполнив следующую команду.

Файлы закрытого ключа и CSR запроса или их содержимое потребуются далее. Вывести (чтобы затем скопировать) содержимое файла можно командой cat.

Для выхода нажмите клавишу Q.

Выпуск SSL-сертификата

Теперь, когда есть запрос, на основании него можно выпустить сертификат.

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

После отправки запроса подтвердите владение доменом. Может быть доступно от одного до четырех способов подтверждения:

Подтверждение через электронную почту

Понадобится один из почтовых ящиков admin@domain, administrator@domain, hostmaster@domain, postmaster@domain или webmaster@domain. На него придет электронное письмо либо с уникальной ссылкой, либо с кодом, который нужно ввести для подтверждения управления доменом. Если следовали рекомендациям выше, то скорее всего такой ящик у вас уже есть.

Подтверждение через CNAME-запись

Вам будут предоставлены хеш-значения, которые необходимо ввести в DNS CNAME запись подтверждаемого домена.

Формат CNAME следующий:

Подтверждение через TXT-запись

Вам будет предоставлено хеш-значение, которое нужно добавить в TXT-запись подтверждаемого домена.

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

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

В скачанном архиве или письме будет несколько файлов: SSL-сертификат, один или несколько промежуточных и один корневой.

Например, для сертификатов Comodo:

domain_ru.crt — SSL-сертификат;
AddTrustExternalCARoot.crt (или AAACertificateServices.crt) — корневой;
SectigoRSADomainValidationSecureServerCA.crt, USERTrustRSAAddTrustCA, USERTrustRSAAAACA.crt- промежуточные.

Часто цепочка сертификатов может поставляться в виде одного файла – .CA-BUNDLE.

Установка SSL-сертификата

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

Как установить SSL-сертификат на хостинг

Найдите раздел SSL панели управления хостингом.

Если сертификат приобретался в другом месте, вручную загрузите файлы сертификата, файл приватного ключа и укажите домен (хостинг).

Аналогичным образом процедура выглядит для других хостеров. На скриншоте ниже скриншот с примером для Hostland.

Подробные инструкции можно найти у своего хостинг провайдера.

Как установить SSL-сертификат в панели управления ISPmanager

Войдите в панель управления ISPmanager.

На открывшейся странице заполните поля:

Имя SSL-сертификата – любое имя латиницей, под ним сертификат будет отображаться в панели управления;
SSL-сертификат – содержимое файла SSL-сертификата;
Ключ SSL-сертификата – приватный ключ сертификата;
Цепочка SSL-сертификатов – последовательно укажите сначала корневой сертификат, а затем с новой строки без пробела – промежуточный.

Затем нажмите Завершить.

Как установить SSL-сертификат на сервер с Nginx

Объедините три сертификата (SSL-сертификат, корневой и промежуточный) в один файл. Для этого с помощью блокнота или другого редактора создайте текстовый документ с именем domain.crt и поочередно поместите в него содержимое каждого из сертификатов (без лишних пробелов и пустых строк).

Так же понадобится приватный ключ, который был получен на этапе генерации CSR запроса на сертификат. Переименуйте его в domain.key.

Оба файла загрузите на сервер в директорию /etc/ssl/ или /etc/nginx/ssl/

Отредактируйте виртуальный хост сайта, для которого устанавливается сертификат. Файл /etc/nginx/sites-available/site.conf или или другой, в зависимости от особенностей сервера.

Указаных настроек должно быть достаточно, чтобы SSL заработал.

/etc/ssl/ca.crt – путь до файла с корневым сертификатом (его предварительно нужно загрузить на сервер);
8.8.8.8 – DNS-сервер.

Затем убедитесь, что конфигурационный файл Nginx не содержит ошибок.

Чтобы изменения вступили в силу, перезагрузите сервер Nginx.

Ubuntu

CentOS 6

CentOS 7

Как установить SSL-сертификат на сервер с Apache

Понадобится файл SSL-сертификата, назовите его domain.crt и приватный ключ, который был получен на этапе генерации CSR запроса на сертификат, переименуйте его в domain.key.

Так же, создайте текстовый документ, например с именем chain.crt и поместите в него цепочку сертификатов — поочередно добавьте в него содержимое промежуточного сертификата и следом за ним корневого (без лишних пробелов и пустых строк).

Все 3 файла загрузите на сервер в директорию /etc/ssl/

Откройте конфигурационный файл Apache сайта, для которого устанавливается сертификат. Если сайт один, конфигурационный файл скорее всего будет одним из указанных ниже:

Затем убедитесь, что конфигурационный файл Apache не содержит ошибок.

Чтобы изменения вступили в силу, перезагрузите Apache.

Centos

Debian или Ubuntu

Как установить SSL-сертификат на 1C-Bitrix

Воспользуйтесь официальными инструкциями от 1С-Битрикс:

Генератор конфигурационных файлов SSL

У Mozilla есть инструмент SSL Configuration Generator , он позволяет генерировать конфигурационные файлы для подключения SSL под большинство популярных серверов. Можно взять за основу рекомендуемые настройки или сверить текущим конфиг.

Внесение изменений в настройки сайта

Если в качестве web-сервера используется Apache, внесите изменения в файл .htaccess:

если вариант выше не сработал:

или (если возникает циклическая переадресация):

и последний вариант:

Оповестить поисковые системы об изменениях

Что еще нужно сделать

С помощью инструмента SSL Configuration Generator сравните конфигурацию сервера с рекомендуемой.

Просканируйте сайт на уязвимости в безопасности с помощью сервиса Mozilla Observatory и в случае замечаний исправьте их.

Полезные ссылки

На этом всё. Но вы можете поддержать проект. Даже небольшая сумма поможет нам писать больше полезных статей.

Если статья помогла или понравилась, пожалуйста поделитесь ей в соцсетях.

У меня была аналогичная проблема, и я решил ее после нескольких запусков Maven Update, когда она, наконец, решила проблему. Одного запуска было недостаточно, потому что файл jar все еще был поврежден, поэтому вам нужно убедиться, что он открывается с помощью любого инструмента сжатия, такого как winzip или gzip.

Я сделал один файл .pem всех сертификатов, думая, что это сработает. Это не так. Может ли кто-нибудь объяснить, что я делаю не так, или даже если это возможно?

2 ответа

Это также избавит от необходимости использовать > в вашей команде, поскольку каждый файл будет удален после добавления.

Вот как я это делаю на своем веб-сервере и почтовом сервере.

Поскольку выполнение цикла может занять больше минуты, я устанавливаю www-example-com.crt вне цикла, чтобы всегда использовалась одна и та же минута. Вы можете переместить это назначение внутри цикла, если вам нужны разные выходные файлы в зависимости от того, когда действительно происходит конкатенация.

Во-вторых, я открываю www-example-com.crt и добавляю промежуточный класс 1 от Startcom. Я получаю промежуточное звено из Index of / certs компании Startcom. Теперь в моем www-example-com.crt есть два закодированных сертификата PEM.

В-третьих, я выполняю следующее, чтобы создать файл PKCS12 / PFX для использования в IIS.

В вашем случае в вашем www-example-com.crt будет как минимум три сертификата в кодировке PEM:

Имена файлов примеров:

Если вы cat свой www-example-com.crt и у него НЕ несколько сертификатов, не продолжайте. Не выполняйте openssl pkcs12 , пока ваш серверный сертификат не будет иметь все требуемые промежуточные сертификаты, необходимые для проверки цепочки.

Сомневаюсь, что Доверяйте знакам их СА напрямую. Вероятно, они тоже используют промежуточное звено. Итак, ваша цепочка сертификатов, вероятно, должна выглядеть так:

Entrusts предоставляет свои сертификаты CA и промежуточные сертификаты в корневых сертификатах Entrust. Я не могу сказать вам, какой из них вам нужен, потому что вы не предоставите URL-адрес или не покажете нам имеющуюся у вас цепочку. Но я предполагаю, что это будет одно или несколько из:

Сертификат Entrust L1E Chain
Сертификат Entrust L1C Chain
Сертификат Entrust L1E Chain (SHA2)
Сертификат Entrust L1C Chain (SHA2)

Вы можете протестировать свою цепочку с помощью OpenSSL `s_client. На этот раз вы будете использовать сертификат Entrust:

Вы можете получить entrust-ca.pem из Доверительных корневых сертификатов. Запустите его и сообщите нам, какие ошибки вы получаете. Или, лучше, отправьте URL-адрес на свой сервер, чтобы мы могли видеть, что происходит.

У меня есть сертификат со следующей цепочкой сертификации: Entrust-> My CA-> My Issuing CA-> My JBoss Certificate .

В конце концов, вы должны найти эти включенные jar-файлы, доступные в папке проекта build.

Итак, ваше первое решение - сервер отправит цепочку с:

Во-вторых, у вас проблема с ненадежным эмитентом. Клиент должен доверять вашему внутреннему выдающему ЦС.

Я добавил jsf 2.0 и mojarra 2.0.3-fcs в POM, и это устранило мою проблему.

Если клиент не доверяет ни Entrust, ни My CA, вы получите ошибки проверки.

Я сделал один файл .pem всех сертификатов, думая, что это сработает. Это не так. Может ли кто-нибудь объяснить, что я делаю не так, или даже если это возможно?

Вот быстрый и грязный способ проверить соединение с OpenSSL s_client :

OpenSSL по умолчанию ничему не доверяет (в отличие от браузеров), поэтому вы должны указать свой якорь доверия с помощью -CAfile .

В статье мы рассмотрим, как установить SSL-сертификат на веб-сервер Nginx.

Сервис настройки NGINX

Не тратьте время на ручную подготовку конфигурационных файлов для NGINX. Выберите нужные параметры и скачайте уже сформированный конфигурационный файл.

Как установить SSL-сертификат на Nginx

После активации сертификата вам будут доступны необходимые данные для его установки, подробнее в статье Где взять данные для установки SSL-сертификата.

Также вы можете использовать для установки сертификат, купленный в сторонней компании.

Рассмотрим, как выполняется установка и настройка Nginx SSL:

Объедините три сертификата (сам SSL-сертификат, корневой и промежуточный сертификаты) в один файл. Для этого создайте на ПК новый текстовый документ с именем your_domain.crt (your_domain — доменное имя сайта, который вы хотите защитить). Создать его можно при помощи блокнота или другого текстового редактора. Поочередно скопируйте и вставьте в созданный документ каждый сертификат. После вставки всех сертификатов файл должен иметь вид:

Обратите внимание: один сертификат идёт следом за другим, без пустых строк.

Откройте конфигурационный файл Nginx и отредактируйте виртуальный хост вашего сайта, который вы хотите защитить сертификатом. Выполните минимальную для работы настройку, добавив в файл следующие строки:

/etc/ssl/your_domain.crt — путь до созданного файла с тремя сертификатами,

/etc/ssl/your_domain.key — путь до файла с приватным ключом.

Минимальная установка и настройка выполнена. Далее вы можете добавить расширенные настройки конфигурационного файла либо сразу перейти к шагу 12.

Добавьте в секцию server<>, которую вы создали на шаге 4, следующую строку:

Добавьте в конфигурационном файле в секции server<> строки:

Для того, чтобы обеспечить эти требования, все открытые ключи хранятся и передаются в виде сертификатов.

Сертификат — это набор данных специального формата, содержащий сам открытый ключ и всю информацию о нем: кто владелец, адрес электронной почты владельца, когда ключ создан, назначение ключа (подпись или обмен), для какого алгоритма предназначен ключ и т.д.

Удостоверяющие центры

Создает (выпускает) сертификаты специальный административный центр, называемый удостоверяющим центром (УЦ) или центром сертификации (ЦС).

Удостоверяющий центр устанавливает определенные требования к работе пользователей. Например, удостоверяющий центр определяет максимальный срок действия сертификатов, совокупность необходимых данных запросе на сертификат, способы передачи запроса от пользователя в УЦ, способы проверки корректности запросов пользователей и т.д.

Совокупность требований удостоверяющего центра называется регламентом удостоверяющего центра.

Удостоверяющий центр имеет собственные ключи подписи и подписывает на них все электронные документы, которые он выпускает.

Удостоверяющий центр выпускает сертификат на собственный открытый ключ. Такой сертификат называется сертификатом удостоверяющего центра.

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

Пользователь создает ключевую пару (открытый и закрытый ключи).
Пользователь отправляет в удостоверяющий центр запрос на сертификат, в который включает открытый ключ и всю необходимую информацию о себе и о ключах. Набор необходимых сведений определяется регламентом удостоверяющего центра, но всегда необходимо указывать имя владельца, назначение ключей, дату создания.
Удостоверяющий центр получает запрос и проверяет его подлинность и корректность. Как именно это делается, определяется регламентом удостоверяющего центра.
Если результат проверки запроса положительный, удостоверяющий центр создает сертификат на открытый ключ, подписывает его, заносит в свою базу данных и отправляет пользователю.
Пользователь получает сертификат и устанавливает его у себя в системе.

Криптографические операции и цепочки доверия

Для проверки подписи используется открытый ключ подписи автора подписи. Но для того, чтобы результат проверки можно было считать надежным, необходимо удостовериться, что сам открытый ключ подписи автора подписи, имеющийся у проверяющего, корректен.

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

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

Корневые сертификаты удостоверяющих центров

В каждой цепочке доверия рано или поздно встречается сертификат, на котором цепочка заканчивается. Т.е. для этого сертификата нет сертификата, на котором его можно было бы проверить.

Такие сертификаты называются корневыми.

Очевидно, что корневым сертификатом в цепочке доверия всегда является сертификат удостоверяющего центра (хотя необязательно каждый сертификат удостоверяющего центра будет корневым—могут, например, существовать сертификаты удостоверяющего центра, подписанные на корневом и т.д.)

Проверить такой сертификат электронными средствами невозможно. Для проверки этих сертификатов используются бумажные распечатки, содержащие определенную информацию: как правило, так называемые цифровые отпечатки, либо сами открытые ключи. Какая именно информация используется для проверки, зависит от регламента удостоверяющего центра.

Цифровой отпечаток документа — это последовательность символов, соответствующая документу таким образом, что каждому документу соответствует свой отпечаток, и по изменению документа нельзя определить, как изменится цифровой отпечаток. Таким образом, можно быть уверенными, что если цифровой отпечаток документа соответствует документу, документ подлинный и корректный. (Эта идея заложена также в основе формирования ЭП).

Для проверки корневого сертификата удостоверяющего центра необходимо получить в удостоверяющем центре бумажную распечатку, содержащую цифровой отпечаток этого сертификата либо открытый ключ, и заверенную подписью администратора удостоверяющего центра и печатью удостоверяющего центра, и сравнить информацию из распечатки с соответствующей информацией, содержащейся в сертификате (увидеть эту информацию можно при просмотре и при установке сертификата).

Если цифровой отпечаток или открытый ключ в распечатке и в сертификате совпадает, корневой сертификат считается корректным. Если цифровой отпечаток или открытый ключ в распечатке и в сертификате не совпадают, значит, файл корневого сертификата искажен. О факте искажения файла сертификата следует немедленно сообщить в удостоверяющий центр—это может означать компрометацию ключей удостоверяющего центра.

Промежуточные сертификаты удостоверяющих центров

Промежуточные сертификаты удостоверяющих центров—это сертификаты на ключи удостоверяющих центров, не являющиеся корневыми. Т.е. это сертификаты удостоверяющих центров, подписанные на других сертификатах удостоверяющих центров.

Если удостоверяющий центр по какой-то причине (например, окончание срока действия сертификата) создал новые ключи, выпустил сертификат на них и подписал его на старом сертификате;
Если ключи удостоверяющего центра заверены на ключах какого-то другого удостоверяющего центра. Такая схема удобна, например, для небольших удостоверяющих центров, обслуживающих небольшое количество абонентов. Такие удостоверяющие центры могут заверить свои ключи на сертификате крупного, хорошо известного и пользующегося доверием удостоверяющего центра, корневой сертификат которого установлен у многих пользователей.

Если в цепочке доверия присутствует промежуточный сертификат удостоверяющего центра, она оказывается трехзвенной:

Корневой сертификат УЦ—промежуточный сертификат УЦ—сертификат пользователя.

Более длинные цепочки (с несколькими промежуточными сертификатами) возможны, но встречаются очень редко.

Запрос на сертификат на открытый ключ

Точный набор данных, включаемых в запрос, определяется регламентом удостоверяющего центра. В запрос обязательно включается имя пользователя, назначение запрашиваемого сертификата (подпись или обмен), а также сам открытый ключ, на который создается сертификат. Таким образом, к моменту формирования запроса открытый ключ уже должен существовать.

У пользователя еще нет ключей. В этой ситуации перед формированием запроса ему необходимо создать ключи.
У пользователя есть ключи, но срок действия соответствующего сертификата истек. В этой ситуации можно:
- Создать запрос на новый сертификат на имеющиеся ключи. Новых ключей создавать не надо;
- Создать новые ключи и сформировать запрос на сертификат на эти ключи.
Конец срока действия сертификата

Каждый сертификат имеет ограниченный срок действия. Конкретный максимальный срок действия сертификата устанавливается регламентом УЦ, но обычно он не превышает одного года.

По истечении срока действия сертификат становится недействительным.

По истечении срока действия сертификата удостоверяющего центра необходимо получить и установить в системе новый.

По истечении срока действия сертификата на открытый ключ пользователя необходимо сформировать запрос на новый сертификат.

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

Отзыв сертификата

Существует ряд причин, по которым действие сертификата бывает необходимо прекратить до окончания его срока действия.
- Компрометация соответствующего закрытого ключа. Если несанкционированный доступ к закрытому ключу все же имел место или обнаружена хотя бы возможность такого доступа, закрытый ключ, а также парный к нему открытый считаются скомпрометированными. Работать с такими ключами нельзя.
- Замена сертификата (например, в связи с изменением адреса электронной почты пользователя).
- Задержка действия сертификата.
В таких ситуациях удостоверяющий центр отзывает соответствующий сертификат.

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

Удостоверяющий центр отзывает соответствующий сертификат, т.е. заносит его в так называемый список отзыва сертификатов (CRL — Certificate Revocation List). Все сертификаты, числящиеся в списке отзыва сертификатов, недействительны. Список отзыва сертификатов доводится до сведения всех пользователей в соответствии с регламентом удостоверяющего центра.

Владелец отозванного сертификата отправляет в удостоверяющий центр запрос на новый сертификат. Необходимость создания новых ключей в этом случае определяется конкретной ситуацией: если старые ключи скомпрометированы, необходимо создать новые; если речь идет о замене сертификата вследствие изменения актуальной информации о владельце, достаточно создать запрос на новый сертификат на имеющиеся ключи.

Часто бывает, что клиент присылает сертификат для своего домена без промежуточного сертификата или с неправильным промежуточным сертификатом. Почему-то чаще всего это наблюдается с теми, кто покупает сертификаты у RapidSSL. Причем проблема эта незаметна, пока не доходит дело до работы с сайтом с какого-нибудь Android-девайса. По слухам, обычные десктопные броузеры (Opera, Firefox, Chrome) умеют сами находить при необходимости недостающие промежуточные сертификаты и молча и незаметно для пользователя подгружать их в случае, если таковые не были предоставлены сервером. А вот броузеры на android-устройствах, а также curl, проявляют бОльшую принципиальность и выдают назойливое предупреждение в стиле "сертификат получен из недоверенного центра сертификации" если сервер не предоставил полную цепочку сертификатов из корневого и всех промежуточных.

Как найти промежуточный SSL-сертификат с помощью SSLLABS

Найденный промежуточный сертификат Symantec Basic DV SSL CA - G2

Там дальше клацаем по кнопочке PEM и получаем искомый промежуточный SSL-сертификат, который нужно прописать в конфигах веб-сервера. Профит!

А в этой статье написано как сделать правильный c точки зрения SSLLabs конфиг haproxy.

Читайте также: