Как создать. ca-bundle
Если у вас нет в наличии отдельного файла с расширением. ca-bundle, то создать его очень просто. Вам должны были прислать несколько файлов в формате crt, от корневого и промежуточного центра сертификации. Посмотреть это можно в общем crt файле на вкладке «Путь сертификации».
В моем примере, корневым является DIGI, а промежуточным Thawte. При желании вы можете их выбрать и скопировать в виде файла формата crt. Откроем их с помощью блокнота. По сути создание. ca-bundle подразумевает объединение содержимого этих двух файлов цепочки. Это можно сделать через создание нового текстового файла и добавление в него данной информации с последующим изменением расширения txt на. ca-bundle или выполнить команду.
Вот так выглядит команда по созданию. ca-bundle файла.
copy intermediate_pem_thawte_sslwildcard_1. crt + root_pem_thawte_sslwildcard_1. crt pyatilistnik. ca-bundle
Как выпустить Wildcard SSL сертификат в Active Directory
И так у вас есть развернутый домен Active Directory, внутри домена есть инфраструктура по выпуску сертификатов, через Windows роль «Центр Сертификации». Поступила задача выпустить для вашего домена Wildcard SSL сертификат, чтобы использовать его на разных проектах предприятия. Что вы делаете, открываете окно «Выполнить» и пишите там слово mmc.
У вас откроется окно для добавления оснасток mmc. Нажмите меню «Файл — Добавить или удалить оснастку».
Находим в левом разделе «Доступные оснастки» запись «Сертификаты» и нажимаем «Добавить».
Выбираем пункт «Учетной записи компьютера» и нажимаем далее.
Оставляем, эта оснастка управляет «Локальным компьютером» и нажимаем готово.
Видим, что в корень консоли был добавлен пункт «Сертификаты», нажимаем «Ok».
Следующим шагом, переходим в раздел «личное — Сертификаты» и щелкаем по ним правой кнопкой мыши, из контекстного меню выбираем пункт «Все задачи (All Tasks) — Дополнительные операции (Advanced Options) — Создать настраиваемый запрос (Create Custom Request)»
У вас откроется мастер регистрации сертификатов, на первом экране просто нажимаем «Далее».
В выборе политики регистрации сертификатов выбираем пункт «Продолжить без политики регистрации (roceed without enrolment Policy)».
В шаблоне выставляем «Старый ключ (без шаблона)», формат записи «PKCS#10» и нажимаем далее.
Раскрываем подробности и щелкаем по кнопке «Свойства».
У вас откроется дополнительная форма со свойствами запрашиваемого сертификата. В понятном имени задаем, как будет вам удобно идентифицировать ваш сертификат, я подпишу его *. root. pyatilistnik. org, в описании можете задать Wildcard SSL сертификат для домена root. pyatilistnik. org.
Переходим на вкладку «Субъект», это самое важное в настройке Wildcard сертификата. Тут задается с какими доменными именами будет работать SSL, его поля. Задаваемые поля:
- Страна (Country) — пишем RU и добавляем на право
- Подразделение (Organizational Unit) — например, пишем IT
- Область (State) — Я пишу Moscow
- Размещение (Location) — Я пишу Moscow
- Организация (Organization) — Я пишу Pyatilistnik Inc
Переходим на вкладку «Расширения (Extensions)», тут мы зададим под, что мы будем использовать ваш Wildcard SSL сертификат, так называемые OID (Оиды). Раскрываем пункт «Использование ключа», из левой панели переносим вот такие пункты:
- Цифровая подпись (Digital Signature)
- Шифрование ключей (Key encipherment)
Так же при необходимости можете открыть «Расширенное использование ключа», тут много дополнительных возможностей:
Переходим на вкладку «закрытый ключ (private key)». В разделе «Параметры ключа» выставите его размер, у меня это будет 4096 байт, обязательно поставьте галку «Сделать закрытый ключ экспортируемым (Make private key exportable)»
При необходимости вы можете задать тип ключа в вашем Wildcard SSL. Тут будет два варианта:
- Обмен (Exchange) — относится к обмену ключами шифрования.С помощью S/MIME отправитель шифрует электронную почту с помощью открытого ключа получателя, а получатель расшифровывает сообщение своим закрытым ключом. Exchange = шифровать ключи сессии
- Подпись (Signature) — означает подтверждение личности отправителя.Само сообщение не зашифровано, однако, если сообщение подделано во время передачи, оно делает недействительной подпись.Для наших целей нам необходимо подтвердить свою личность на удаленном сервере, поэтому мы будем использовать. Signature = создать цифровую подпись
При желании вы потом с помощью утилиты certutil можете поменять тип у сертификата
Достаточно будет оставить значение по умолчанию (Подпись), второй режим часто используют в VPN построениях. Нажимаем «Ok»
В окне сведения о сертификате нажимаем далее.
Вас попросят указать имя файла и где его сохранить, оставляем формат файла в виде «base 64». Base 64 — это метод кодирования, разработанный для использования с безопасными/многоцелевыми расширениями почты Интернета (S/MIME), который является популярным, стандартным методом для передачи двоичных вложений через Интернет.
Двоичные данные — DER (отличительные правила кодирования) для ASN. 1, как определено в Рекомендации X. 509, может использоваться центрами сертификации, которые не работают на компьютерах под управлением Windows Server 2003, поэтому он поддерживается для обеспечения совместимости. Файлы сертификатов DER используют расширение. cer.
В результате вы получите с вашим CSR запросом. Откройте данный файл с помощью любого текстового редактора и скопируйте его содержимое. Далее вы переходите в веб интерфейс вашего центра сертификации по адресу:
Выбираете пункт «Request a certificate».
Далее нажимаем «advanced certificate request»
В поле «Base-64-encoded certificate request (CMC or PKCS #10 or PKCS #7):» вставляем ваш CSR запрос, выбираем шаблон в поле «Certificate Template» я выбираю «Web Server». После чего нажимаем «Submit».
Далее в оснастке сертификаты, открываем раздел «Личное — Сертификаты», щелкаем по ним правым кликом и выбираем пункт «Все задачи — импорт»
В мастере импорта просто нажимаем далее
Через кнопку «Обзор» укажите ваш сертификат в формате cer.
Помещаем его в личное
В итоге вы увидите, что импорт успешно выполнен.
Далее у вас появится ваш сертификат, щелкаем по нему правым кликом и экспортируем его. Ставим, что будем экспортировать, для этого выставите галку «да, экспортировать закрытый ключ». На выходе вы получите pfx архив со всеми ключами, который потом можно использовать.
очень легко без установки вы можете просматривать состав вашего pfx архива в keytool или KeyStore Explore
На этом у меня все, мы с вами научились выпускать Wildcard SSL сертификат на центре сертификации Windows. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik. org.
Что делать если нет сертификата в запросах заявок на сертификат
Бывают ситуации, что на вашем сервере по каким-то причинам, в папке запросы на сертификат, может не оказаться вашего, в этом случае вам необходимо будет перейти в этой же mmc в раздел «Личное-Сертификаты». Выбираем нужный и делаем экспорт.
Или вы можете просто открыть существующий CRT и в нем так же выгрузить P7B, это не потребует установку crt
Появится мастер экспорта сертификатов.
Обратите внимание, что в pfx выгрузить не получится, но это не страшно, нам подойдет и p7b, но с включенной галкой «Включить по возможности все сертификаты в путь сертификации»
Указываем путь сохраняемого файла.
Видим, что все успешно выполнено.
Преобразование p7b в pem
Попробует такое преобразование.
openssl pkcs7 -in cert. p7b -inform DER -print_certs -out cert. pem
openssl. exe pkcs7 -in new. pyatilistnik. p7b -inform DER -print_certs -out new. pyatilistnik. pem
В итоге я получил файл new. pyatilistnik. pem
Ну, а дальше уже по инструкции сверху. Если у вас выскочит ошибка, по типу
C:AMD64-Win64OpenSSL-0_9_8g>openssl. exe rsa -in new. pyatilistnik. pem -out new. pyatilistnik. key unable to load Private Key 6944:error:0906D06C:PEM routines:PEM_read_bio:no start line:. cryptopempem_lib. c:647:Expecting: ANY PRIVATE KEY
То наш вариант это. crt в. der и уже. der в. pem
Преобразование CRT в PEM
Кладем так же все в одну папку, файл crt вам должны были прислать вместе с ca-bundle.
Первое это crt в der
openssl x509 -in new. pyatilistnik. crt -out new. pyatilistnik. der -outform DER
Теперь der в pem.
openssl x509 -in new. pyatilistnik. der -inform DER -out new. pyatilistnik. pem -outform PEM
В итоге у меня получилось, вот так.
Операции с сертификатами¶
В данной инструкции рассматривается:
- Развертывание субординированного доменного центра сертификации на устройстве TING
- Распространение издательских сертификатов на доменные компьютеры через GPO
- Издание сертификатов для серверных служб TING с использованием субординированного ЦС
В нашем примере используется следующая схема сети:
Имена и адреса
После настройки субординированного доменного ЦС на устройстве TING появляется возможность генерировать конечные (end entity) сертификаты для серверных служб TING. Подход с разворачиванием субординированного доменного ЦС на устройстве TING более удобен по сравнению с запросом каждого нового end entity сертификата в корневом доменном ЦС.
После установки и настройки вышеозначенных компонентов, веб-интерфейс для выписки сертификатов доступен по адресу:
Веб-интерфейс устройства TING доступен по адресу:
Для настройки, нам потребуются программы putty и WinSCP.
Для конвертирования между форматами хранения сертификатов и ключей понадобится пакет OpenSSL, который предустановлен на устройсте TING или доступен в среде Cygwin для Windows.
Создание субординированного доменного ЦС¶
Настроим на устройстве TING издательство tinga. dom. loc CA, которое будет субординированным по отношению к корневому доменному ЦС dom. loc CA.
С компьютера comp1. dom. loc заходим программой putty по SSH на tinga. dom. loc и выполняем команду:
Отвечаем на задаваемые вопросы аналогично примеру:
# openssl req -new -newkey rsa:2048 -nodes -keyout tinga. dom. loc_ca. key -out tinga. dom. loc_ca. csr
С компьютера comp1. dom. loc заходим программой WinSCP по SFTP на tinga. dom. loc.
Скачиваем файл /root/tinga. dom. loc_ca. key. Это файл с секретным ключом, который будем импортировать в TING через веб-интерфейс.
Скачиваем файл /root/tinga. dom. loc_ca. csr. Это запрос на подпись сертификата, который будем использовать при запросе к доменному ЦС.
Выбираем действие Расширенный запроса сертификата.
Выбираем действие Выдать запрос, используя base-64 шифрованный файл PKCS #10, или выдать запрос обновления, используя base-64 шифрованный файл PKCS #7. Нажимаем кнопку Выдать.
Подтвердите, что Вы доверяете веб-сайту осуществление операций с сертификатами от Вашего лица.
Установите радиокнопку Base64-шифрование и нажмите на ссылку Загрузить сертификат (файл certnew. cer). Также, нажмите на ссылку Загрузить цепочку сертификатов (certnew. p7b).
Скопируйте содержимое файла certnew. cer:
С компьютера comp1. dom. loc заходим на веб-интерфейс устройства TING в раздел СистемаДоверенные сертификатыПолномочия.
Кликните на кнопку Добавить или импортировать CA. Заполните поля следующим образом:
В поле Описательное имя укажите tinga. dom. loc CA.
В поле Метод выберите Импортировать существующий ЦС.
В поле Данные сертификата скопируйте данные сертификата, выданного доменным ЦС (файл certnew. cer).
В поле Секретный ключ сертификата (необязательно) скопируйте секретный ключ из файла tinga. dom. loc_ca. key.
Нажмите кнопку Сохранить.
Для того, чтобы доменные машины могли доверять сертификатам, изданным ЦС tinga. dom. loc CA, сертификат данного издательства должен быть установлен на этих машинах.
Перенесите файл certnew. p7b на компьютер controller. dom. loc. В нашем случае, файл располагается по пути С:certnew. p7b.
Запустите оснастку Управление групповой политикой и откройте на редактирование объект групповой политики Default Domain Policy.
В Редакторе управления групповыми политиками пройдите в раздел Конфигурация компьютераКонфигурация WindowsПараметры безопасностиПолитики открытого ключаДоверенные корневые центры сертификации.
Вызовите контекстное меню по узлу Доверенные корневые центры сертификации, кликните Импортировать и выберите файл С:certnew. p7b.
При выборе хранилища, в которое будет импортирована цепочка сертификатов, укажите Доверенные корневые центры сертификации.
Откройте командную строку с привилегиями администратора и выполните команду:
Для попадания сертификатов на доменные компьютеры, их, возможно, придется перезагрузить.
На компьютерах, которые не входят в домен, издательские сертификаты могут быть установлены вручную из файла certnew. p7b в хранилище Доверенные корневые центры сертификации. Здесь особенно уместным будет то, что certnew. p7b содержит цепочку сертификатов, а не только лишь один сертификат ЦС tinga. dom. loc CA.
Проверить наличие издательских сертификатов на пользовательских компьютерах можно с помощью оснастки консоли MMC.
На компьютере comp1. dom. loc создайте оснастку для работы с сертификатами. Для этого, в меню Выполнить (вызывается по нажатию Win+R) наберите mmc и нажмите Enter.
После синхронизации с контроллером домена, сертификаты издательств dom. loc CA и tinga. dom. loc CA должны присутствовать в хранилище Сертификаты(локальный компьютер)Доверенные корневые центры сертификации.
Издание сертификатов для серверных служб TING с использованием субординированного ЦС¶
С помощью субординированного ЦС можно выписывать различные end entity сертификаты, для использования в следующих функциях:
Продемонстируем генерацию серверного сертификата для нужд защищенного доступа к веб-интерфейсу TING.
С компьютера comp1. dom. loc заходим на веб-интерфейс устройства TING в раздел СистемаДоверенные сертификатыСертификаты и нажимаем кнопку Добавить или импортировать сертификат.
В появившемся окне указываем настройки по аналогии с примером:
Нажмите на кнопку Сохранить.
В веб-интерфейсе пройдите в раздел Система -> Настройки -> Администрирование и в поле Сертификат SSL выберите ранее созданный сертификат Web GUI certificate. Нажмите на кнопку Сохранить.
Через несколько секунд веб-интерфейс управления будет доступен уже с новым сертификатом.
Конвертирование между форматами¶
Конвертирование PKCS#12 (файлы с расширением *. PFX) в PEM
ЦС Windows позволяет экспортировать сертификаты и ключи в формате PKCS#12 (. PFX). В то же время, Traffic Inspector Next Generation поддерживает импорт сертификатов и ключей в представлении Base64 (PEM формат).
Получить сертификат и ключ в PEM-формате из файла cert_with_private_key. pfx можно следующими командами:
Конвертирование DER в PEM
ОС Windows часто использует формат DER для хранения сертификатов.
Получить сертификат в PEM-формате из формата DER можно с помощью следующей команды:
Проверка соответствия секретного ключа и сертификата¶
Для проверки соответствия, нужно сравнить modulus ключа и сертификата.
Если они совпадают, то перед нами криптографически связанные ключ и сертификат. Такой сертификат будет работать.
В случае, если они не сходятся, перед нами криптографически несвязанные ключ и сертификат. Такой сертификат не сможет выполнять свою функцию. Требуется перевыпустить сертификат на базе нового ключа.
С компьютера comp1. dom. loc заходим программой putty по SSH на tinga. dom. loc.
Для вывода modulus ключа, выполняем команду:
Для вывода modulus сертификата, выполняем команду:
Как реализовать на практике?
Стандарт CMS/PKCS#7 с поддержкой российских криптоалгоритмов реализован в сертифицированных СКЗИ наших партнеров:
- КриптоПро CSP компании Крипто-Про
- VipNet CSP компании Инфотекс
- СигналКом CSP или Message-PRO компании СигналКом и др.
Кроме того, стандарт CMS с российской криптографией реализован в Open Source приложении OpenSSL.
Наша компания поддержала CMS c российской криптографией в продукте Рутокен Плагин. Рутокен Плагин предназначен для использования в браузерах, все криптографические операции производятся аппаратно, «на борту» USB-токена.
Обрабатываем запрос сертификата
Далее выбираем “расширенный запрос сертификата”
Выбираем “Выдать запрос, используя base-64 шифрованный файл PKCS #10, или выдать запрос обновления, используя base-64 шифрованный файл PKCS #7″
В окно “Сохранный запрос” переносим содержимое созданного ранее файла web-srv. req; “Шаблон сертификата” выбираем “Веб-сервер” и нажимаем “Выдать”.
На последней странице выбираем “DER-шифрование” и “Загрузить сертификат”.
Стандарт CMS (PKCS #7 и RFC 5652)
Синтаксис криптографических сообщений (CMS) впервые был определен в PKCS #7, который позже был опубликован в качестве рекомендаций RFC 2315 «PKCS #7: Cryptographic Message Syntax Version 1. Спустя еще несколько версий RFC в сентябре 2009 года был принят RFC 5652 «Cryptographic Message Syntax (CMS)», который является действующим стандартом на данный момент. Под спойлером иллюстрируется тяжелая судьба стандарта.
Подпись в CMS-формате (signed data type)
Подпись, описанная стандартом CMS, характеризуется следующими особенностями:
- Данные могут быть подписаны несколькими сторонами (множественная подпись). В таком случае в сообщении будут присутствовать несколько структур SignerInfo с информацией о подписывающих сторонах: значением подписи и необходимой для проверки ее подлинности информацией.
- Тип данных никак не регламентируется, лишь уточняется, что в качестве данных может быть сообщение формата CMS, то есть подписанное Алисой сообщение может быть целиком подписано Бобом.
- Подписывать можно не только данные, но и некоторые атрибуты сообщения – хеш сообщения (digest message), время подписи (signing time), значение другой подписи (countersignature).
- Открытый ключ подписывающей стороны может быть несертифицированным.
- Подпись может отсутствовать и вовсе.
Данные с электронной подписью используются не только для подписи содержимого и часто используются для распространения сертификатов и списков отзыва сертификатов (Certification Revocation List, CRL). В таком случае подписываемые данные отсутствуют, а поля Certificates и CRLs, наоборот, присутствуют.
Подписанное Алисой сообщение в формате CMS будет иметь следующий вид (серым отмечены необязательные атрибуты):
- Версия синтаксиса CMS Version зависит от сертификатов, типа подписываемых данных и информации о подписывающих сторонах
- Digest Algorithms включает в себя идентификаторы используемых алгоритмов хеширования и ассоциированные с ними параметры.
- Encapsulated Content содержит подписываемые данные (Content) вместе с их типом (Content Type). Содержимое может отсутствовать, тип – нет.
- Certificates предназначен для цепочки сертификатов, отражающих путь сертификации от центра сертификации, выдавшего сертификат, до каждой из подписывающих сторон. Также могут присутствовать сертификаты подписывающих сторон.
- CRLs (Certificate Revocation List) предоставляет информацию о статусе отзыва сертификатов, достаточную для определения валидности сертификата подписывающей стороны.
- Информация о каждой подписывающей стороне содержится в структурах типа Signer Info, которых может быть любое количество, в том числе и нулевое (в случае отсутствия подписи).
Версия синтаксиса CMS Version определяется значением Signer ID. Signer ID определяет открытый ключ подписывающей стороны (subjectKeyIdentifier) или сертификат его открытого ключа, необходимый для проверки подлинности подписи (issuerAndSerialNumber).Digest Algorithm определяет алгоритм хеширования и все ассоциированные с ним параметры, используемые подписывающей стороной.В Signed Attributes помещаются атрибуты, требующие подписи. Поле может отсутствовать только при подписи простых данных (Content Type = id-data), при подписи других данных (например, Content Type = id-SignedData) должно присутствовать с как минимум двумя обязательными атрибутами – типом (Content Type) и хешем данных (Message Digest).Signature Algorithm содержит идентификатор алгоритма подписи вместе с его параметрами.В Signature Value помещается значение подписанного закрытым ключом хеша от данных (Content) и атрибутов для подписи (Signed Attributes). В Unsigned Attributes помещаются оставшиеся атрибуты, не требующие подписи. - Версия синтаксиса CMS Version определяется значением Signer ID.
- Signer ID определяет открытый ключ подписывающей стороны (subjectKeyIdentifier) или сертификат его открытого ключа, необходимый для проверки подлинности подписи (issuerAndSerialNumber).
- Digest Algorithm определяет алгоритм хеширования и все ассоциированные с ним параметры, используемые подписывающей стороной.
- В Signed Attributes помещаются атрибуты, требующие подписи. Поле может отсутствовать только при подписи простых данных (Content Type = id-data), при подписи других данных (например, Content Type = id-SignedData) должно присутствовать с как минимум двумя обязательными атрибутами – типом (Content Type) и хешем данных (Message Digest).
- Signature Algorithm содержит идентификатор алгоритма подписи вместе с его параметрами.
- В Signature Value помещается значение подписанного закрытым ключом хеша от данных (Content) и атрибутов для подписи (Signed Attributes).
- В Unsigned Attributes помещаются оставшиеся атрибуты, не требующие подписи.
Если Боб решает целиком подписать полученное от Алисы сообщение, то используется механизм инкапсуляции, и сообщение будет выглядеть вот так:
CMS предлагает два интересных атрибута, расширяющих возможности обычной подписи: время подписи (Signing Time) и контрасигнатуру (Countersignature). Первый атрибут определяет предполагаемое время осуществления подписи, а второй предназначен для подписи другой подписи (подписывается хеш от значения подписи). Атрибут Countersignature представляет собой структуру Signer Info с отсутствующим в Signed Attributes атрибутом Content Type и обязательно присутствующим атрибутом Message Digest. Атрибут Countersignature может иметь свой собственный атрибут Countersignature.
Если Боб решит подписать только данные, переданные Алисой, и заодно подписать подпись Алисы, то сообщение будет иметь такой вид:
Галопом по Европам оставшимся типам
СMS предлагает еще несколько интересных типов сообщений, не охватываемых темой этой статьи. Поэтому буквально по паре слов об оставшихся типах для общей картины. Упакованные данные (enveloped data) представляют собой зашифрованные данные вместе с зашифрованными для одного или более получателей ключами, которыми эти данные были зашифрованы. Комбинация зашифрованного сообщения с одним зашифрованным ключом шифрования для одного получателя называется цифровым конвертом. Данный тип используется в качестве конверта с (подписанными) данными для одного или нескольких получателей. Хешированные данные (данные вместе со своим хешем) используются для проверки целостности сообщения и часто являются содержимым упакованных данных. Зашифрованные данные часто используются для шифрования данных для локального хранилища, иногда с выработанным из пароля ключом шифрования. Данные из аутентифицированного источника (данные с проверкой подлинности) включают в себя данные вместе с их MAC-кодом и зашифрованными ключами аутентификации для одного или нескольких получателей. Используются для защиты целостности сообщений для неограниченного количества получателей.
В следующей статье мы подробно остановимся на сообщениях типа enveloped data с использованием российских криптоалгоритмов.
CMS в реальной жизни
Стандарт CMS имеет немало воплощений в современном мире IT – на нем основаны:
- стандарт защищенной электронной почты S/MIME (RFC 3851),
- расширенные сервисы защиты для S/MIME (RFC 2634, кстати, тут описаны дополнительные атрибуты CMS и технология тройного «обертывания» на основе множественной инкапсуляции: данные подписываются, затем шифруются и снова подписываются),
- расширенные форматы представления информации об аннулированных сертификатах (RFC 5940) и пр.
Закономерным развитием идей CMS для сообщений с электронной подписью cтал CAdES (CMS Advanced Electronic Signature), расширенный стандарт подписанных сообщений CMS, который также послужит темой для еще одной нашей статьи.
Как получить PFX ключ на IIS
нажимаем сочетание клавиш WIN+R и вводим mmc, для вызова оснастки. Я вам уже рассказывал о ее применении и удобстве для системного администратора.
Далее вам необходимо через меню «Файл» добавить новую оснастку.
Находим сертификаты и нажимаем кнопку «Добавить»
В следующем окне выбираем «для учетной записи компьютера»
подтверждаем, что нас интересует локальный компьютер.
Далее находим пункт «Запросы заявок на сертификат», тут вы обнаружите ваш запрос, находите его и через правый клик экспортируете его.
У вас откроется мастер экспорта сертификатов
Далее вы выбираете «Да, экспортировать закрытый ключ»
Ставим галку «Включить по возможности все сертификаты в путь сертификации» и начинаем наш экспорт PFX архива.
Теперь мастер экспорта, просит вас указать два раза нужный вам пароль, для защиты pfx архива.
Через кнопку обзор, указываем место сохранения вашего файла.
Как видим, все успешно выгружено.
Для чего нужно преобразование сертификатов
Тут ответ, очень простой, все дело в формате работы с ними у каждой программы, будь то IIS или же Apache сервер. Более подробно про виды сертификатов и их назначение, я вам посоветую прочитать вот эту статью.
Давайте я подробнее покажу как выглядит ошибка импортирования сертификата. Во первых когда вы получаете от comodo ваш архив с сертификатами, то там будет два файла:
- с расширением .ca-bundle
- с расширением .crt
Попытавшись на сервере IIS произвести их импорт вы увидите вот такую картинку.
Сертификат не содержит закрытого ключа
И тут нет ничего удивительного, так как это не pfx архив, то в нем нет нужного приватного ключа. Для его получения придется слегка постараться.
Установка OpenSSL для Windows
Теперь нам необходимо наш файл pfx переделать в pem, Pem преобразовать в key:
Вы получите из этих трех файлов, нужный для импорта pfx архив. Во всем этом нам поможет утилита OpenSSL для Windows.
В итоге у вас будет архив, распакуйте его куда вам будет угодно. Далее выберите вашу папку, зажмите SHIFT и щелкните по ней правым кликом, в открывшемся контекстном меню, выберите пункт «Открыть окно команд».
В результате чего у вас откроется командная строка Windows, но уже в нужной папке содержащей утилиту openssl. exe, она нам и поможет все сделать красиво.
Преобразование PFX в PEM
Теперь приступаем к получению фала в формате Pem. Положите в папку с дистрибутивом файл в формате pfx.
openssl. exe pkcs12 -in «имя вашего pfx файла» -nocerts -out key. pem
openssl. exe pkcs12 -in api. pyatilistnik. pfx» -nocerts -out key. pem
Вас попросят указать пароль от Pfx архива, вы его задавали при экспорте, после чего нужно придумать пароль на pem файл.
В папке с дистрибутивом OpenSSL вы обнаружите файл key. pem, он нам нужен будет для следующего этапа.
Преобразование PEM в KEY
Теперь получим файл с расширением key, для этого есть вот такая команда:
openssl rsa -in key. pem -out <путь к вашему файлу key>
openssl rsa -in key. pem -out api. pyatilistnik. key
Вас попросят указать пароль от pem ключа.
В итоге я получил закрытый ключ в формате key.
Еще у вас может возникнуть ошибка: unable to load Private Key 31320:error:0909006C:PEM routines:get_name:no start line:crypto/pem/pem_lib. c:745:Expecting: ANY PRIVATE KEY
Тут вся проблема, что в вашем pem файле просто нет закрытого ключа, в результате чего вы и получаете данную ошибку.
Если у вас есть файл с csr запросом, ты вы его можете просто переделать из текущего расширения в key
Осталась финишная прямая.
Получаем PFX ключ для импорта в IIS
Теперь когда у вас есть все составляющие, вы можете выполнить последнюю команду для создания PFX файла для IIS сервера.
openssl pkcs12 -export -out doman_com. pfx -inkey doman_com. key -in doman_com. crt -certfile doman_com. ca-bundle
openssl. exe pkcs12 -export -out api. pyatilistnik. pfx -inkey api. pyatilistnik. key -in api. pyatilistnik. crt -certfile api. pyatilistnik. ca-bundle
Задаем пароль для pfx файла, потребуется при импортировании.
В итоге вы получаете нужный вам файл, который можно загружать на ваш почтовый сервер.
Конфигурирование Stunnel
Осталось только правильно настроить наш туннель. Для этого создадим файл stunnel. conf с настройками Stunnel по умолчанию и напишем туда следующее:
Теперь, если всё сделано правильно, можно запустить Stunnel с нашей конфигурацией и подключиться к серверу:
stunnel. exe /path/to/stunnel. conf
Откроем браузер и зайдём по адресу localhost:8080. Если всё верно, то отобразится следующее:
Если же нет, то смотрим логи и используем отладчик, чтобы понять в чём же всё-таки проблема.