Pkcs12 как создать windows

Обновлено: 03.07.2024

Разговор о центре сертификации логично начать с PKI — инфраструктуры открытых ключей. Находим определение в Википедии: «PKI — набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей». Так что к PKI стоит относиться именно как к инфраструктуре, в состав которой входят те или иные компоненты.

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

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

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

В систему PKI обычно входят:

Центр сертификации (англ. Certificate Authority (CA)), которому будет посвящена основная часть этой статьи. Он непосредственно работает с сертификатом — выписывает, хранит, проверяет подлинность. Центр сертификации не следует путать с удостоверяющим центром. Также отдельно рассматривается «корневой центр сертификации» — сторона, чья честность неоспорима, а открытый ключ широко известен.
Регистрационный центр (англ. Registration Authority (RA)). Согласно Википедии, «удостоверяющий центр доверяет регистрационному проверку информации о субъекте». Поэтому часто регистрационный центр полностью или частично объединяют с CA.
Сертификат (англ. Certificate) — публичный ключ и идентификаторы сущности, имеющие подпись центра сертификации. В качестве идентификатора может выступать электронная почта пользователя. Если ЦС подписывает набор данных, который состоит из имени пользователя, его публичного ключа и электронной почты, то он как бы гарантирует, что эти данные подлинные. Далее под термином «сертификат» мы будем понимать сертификат стандарта X.509.
Certificate Signing Request (CSR). По сути это запрос на подпись сертификата. В запросе обычно указывается сущность, её параметры и публичный ключ.
Certificate Revocation List (CRL), он же список отзывов, или отозванных сертификатов. По этому списку ЦС ведёт учёт «плохих» сертификатов. И если такой сертификат используется, то ЦС не подтвердит к нему доверие. Чаще всего причина — утрата ключей сертификата.

Для базового понимания структуры PKI этого списка достаточно. Теперь рассмотрим, как всё это применяется.

Центры сертификации: как они используются

Задача центра сертификации — подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи. Логику работы ЦС, как правило, можно описать тезисом «никто не доверяет друг другу, но все доверяют ЦС».

Допустим, условная сущность Аlice имеет сертификат, подписанный ЦС Comp, а сущность Bob пытается проверить подлинность этого сертификата. Проверка будет успешной, если Bob и Alice доверяют одному и тому же ЦС. Для решения такой проблемы в ОС Alice и ОС Bob установлено множество сертификатов различных ЦС.

Рассмотрим, как браузер реагирует на разные сертификаты. У Firefox, например, для идентификации есть такой набор сертификатов ЦС:

Если открыть подробности, то можно увидеть почему:

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

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

А вот пример для сайта, у которого истёк срок действия сертификата:

Как проверяется доверие на практике?

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

В Windows сертификаты можно просмотреть через оснастку certmgr.msc:

Если поместить сертификат в хранилище «Доверенные корневые центры сертификации», то такому центру система будет доверять. А поскольку это хранилище корневых центров сертификации, система потом будет доверять и всем объектам, которые подписаны этим сертификатом.

В ОС Ubuntu Linux сертификаты хранятся в каталоге /etc/ssl/cetrs. Причём часть из них — ссылки на другой объект:

Разворачиваем собственный ЦС

Чтобы лучше понять все процессы, лежащие в основе PKI, рассмотрим на практике развёртывание небольшого ЦС на виртуальной машине под управлением Ubuntu 18 (без выхода в глобальную сеть). Мы не будем жёстко придерживаться правил и стандартов выдачи сертификатов — просто разберём работу с ними.

Начальные настройки

Сперва заполним файл /root/.rnd, который используется как источник начальных случайных значений в генераторе псевдослучайных чисел OpenSSL. Суть использования этого файла описана на сайте OpenSSL. Нам надо заполнить свой файл случайными данными, как вариант — скопировав из /dev/urandom 32768 байт в файл .rnd таким образом:

Далее создадим сертификат для CA:

Опции для сертификата берутся из файла /etc/ssl/openssl.cnf. Сам файл довольно большой, мы не будем приводить здесь его содержимое. В реальности стоит создать свой конфигурационный файл с необходимыми опциями и блоками — и использовать его для генерации сертификатов.

На выходе получим два файла: ключ и сертификат.

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

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

Теперь используем этот ключ для генерации запроса на выдачу сертификата (CSR):

Отметим, что данные, которые вы вводите в поля, должны совпадать со значениями в тех полях, что указывались при создании сертификата корневого сервера. Теперь возьмём корневой сертификат CA и запрос — и сгенерируем на их основе сертификат для сервера:

Должно получиться 5 файлов.

Файл server.req можно удалить — а при необходимости создать заново. Теперь надо перенастроить веб-сервер для работы с сертификатами.

Настройка Apache 2 для использования сертификатов

Переходим в каталог /etc/apache2:

Создаём каталог для хранения сертификатов:

Включаем модуль SSL для веб-сервера. Тестирование проводилось на ОС Ubuntu Linux, поэтому модуль достаточно просто включить:

Аналогично нужно включить поддержку заголовков:

Теперь создадим конфигурационный файл для модуля SSL. Пример содержимого для него можно взять на Syslink.pl. Команды такие:

Сам файл будет содержать следующие параметры (чтобы было проще работать, мы отключили заголовки Strict-Transport-Securrity, X-Frame-Options и X-Content-Type-Options):

Далее созданный конфиг надо активировать:

Теперь переходим в каталог /etc/apache2/sites-available:

И делаем на всякий случай резервные копии всех хранящихся там файлов:

Теперь ещё раз проверяем подключённые модули headers и SSL:

Далее нам надо перенести созданные сертификаты (сертификат CA и сертификат сервера) в каталог /etc/ssl/certs, а ключ сертификата сервера — в каталог /etc/ssl/private:

Далее откроем конфиг сайта (/etc/apache2/sites-available/000-default-ssl.conf) и добавим туда следующие опции:

Теперь перезагружаем веб-сервер:

Проверяем доступность сайта:

Видим, что Firefox не может проверить сертификат сайта. Чтобы смог, надо импортировать цепочку сертификатов, подтверждающих сертификат сервера, в список доверенных. Создадим цепочку:

У полученного файла не забываем сменить атрибуты на 555:

Теперь откроем в браузере менеджер сертификатов и импортируем полученную цепочку (кнопка Import):

Далее можно просмотреть сертификаты и настроить доверие — вдруг что-то упущено:

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

Сейчас время настроить аутентификацию для клиентов.

Настройка аутентификации клиентов

Веб-сервер Apache поддерживает аутентификацию клиента. Это значит, что мы можем выписать клиенту сертификат SSL, а сервер сможет его проверить. Если у пользователя не будет сертификата — аутентификация не пройдёт. Для активации такой возможности надо добавить в конфиг default-ssl.conf такие опции:

После этого к сайту сможет подключиться только тот пользователь, сертификат которого:

установлен в браузере, если клиентом является браузер, — тогда сертификат будет предъявлен при подключении к серверу;
подписан сертификатом доверенного УЦ.

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

Затем на основе ключа сгенерируем CSR:

Теперь на базе запроса сгенерируем сам сертификат:

И импортируем сертификат в формате p12:

В итоге у нас должен получиться файл client.p12. Нужно поменять права на файл, иначе сертификат не импортируется:

Теперь можно импортировать его в браузер по аналогии с корневыми сертификатами:

После импорта должно получиться примерно так:

После этого перезапускаем веб-сервер и возвращаемся на сайт. Видим окно выбора сертификата того пользователя, которого мы импортировали в браузер:

После выбора сертификата пользователя можно успешно зайти на сайт:

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

если пользователей будет больше одного, то мы столкнёмся с проблемами при учёте выдаваемых сертификатов;
при настройке ЦС стоит грамотно выбирать параметры для используемых сертификатов, а для этого нужен свой конфигурационный файл.

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

Напоследок предлагаю ряд полезных материалов для изучения:

Источники, которые использовались при подготовке статьи:

Хотите в подробностях изучить работу центров сертификации и другие вопросы информационной безопасности? Тогда приглашаем вас на факультет GeekUniversity!

Генерация самоподписанного сертификата для hpd одной командой

Ниже приведены конкретные этапы создания ключа, которые которые в командах выше происходят в полностью автоматическом режиме.

Генерация секретного ключа RSA (RSA private key)

Дле генерации используется команда:

<Key Filename> — название секретного ключа;
<Key Size> — длина ключа. Доступные значения: 1024, 2048, 4096.

Генерация запроса на получение сертификата (Certificate Signing Request)

Чтобы получить SSL - сертификат необходимо сгенерировать запрос на получение сертификата (Certificate Signing Request) на сервере. CSR представляет собой зашифрованный текст, содержащий информацию о компании и доменном имени.

В большинстве случаев CSR содержит следующие поля: страна (Country), регион (State/Province), город (Locality/City), организация (Organization), отдел (Organizational Unit) и доменное имя (Common Name). Обратите внимание:

Поле "страна" должно содержать код из двух символов.
Поля "регион" и "город" должны содержать полные названия.
Поле "организация" — полное юридическое название компании или ФИО предпринимателя, если сертификат оформляется на него.
Поле "отдел" — отдел организации, который занимается покупкой сертификата, например "IT".
"Доменное имя" — полное доменное имя, на которое приобретается сертификат.

Команда создания запроса выглядит следующим образом:

<Key Filename> — название секретного ключа RSA;
<Request Filename> — название файла запроса на получение сертификата.

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

Создание самозаверенного сертификата (Self-signed public certificate)

<Amount days> — количество дней, но которое создается сертификат;
<Request Filename> — файл запроса на получение сертификата ( Certificate Signing Request );
<Key Filename> — файл, секретный ключ RSA;
<Certificate Filename> — название с амозаверенного сертификата (Self-signed public certificate ).

Команда :

Преобразовать клиентский сертификат в PEM-файл можно с помощью следующей команды:

После того, как вы создали сертификат, вам нужно будет загрузить его на сервера Telegram — для этого передайте его в поле certificate метода setWebhook. Это действие обязательно только для самозаверенных сертификатов. Приобретённые за деньги или полученные через certbot сертификаты никуда отправлять не нужно.

OpenSSL

Исполняемые файлы OpenSSL для Windows доступны в сети.

Исходные коды доступны на GitHub и на официальном сайте.

Генерация пары сертификатов

Необходимо использовать YOURPUBLIC.pem в качестве публичного ключа при настройки вебхука.

Проверить сертификат можно командой:
Конвертация из уже сгенерированного DER:
Конвертация из уже сгенерированного PKCS12:

Java keystore

С подробной документацией можно ознакомиться на сайте документации Oracle.

Генерация самозаверенного JKS

Конвертация JKS в PKCS12

Промежуточный этап перед конвертацией в PEM:

Конвертация PKCS12 в PEM

Для этой операции необходим OpenSSL:

Windows

Создание самозаверенного сертификата доступно и стандартными средствами Windows, несмотря на то, что исполняемые файлы OpenSSL для Windows доступны для скачивания.

Для настройки вебхука нужен только публичный ключ.

Создайте файл TEMPLATE.txt с таким содержанием:

Далее выполните в командной строке:

После этого будет создан и установлен самозаверенный сертификат. Для просмотра выполните:

Экспортируем в DER (промежуточный этап перед конвертацией в PEM):

Конвертация в PEM (используется для настройки вебхука):

Удаление сертификата из хранилища:

Экспорт в формат PFX(PKCS12):

С подробной документацией можно ознакомиться на сайте документации Microsoft.

Конвертировать YOURPKCS.pfx в PEM (который включает в себя приватный ключ) лучше делать с помощью OpenSSL:

В качестве графического интерфейса для экспорта публичной части сертификата в PEM можно использовать certmgr.msc.

Сайт про Telegram на русском (неофициальный).

Здесь собраны приложения на базе MTProto, переведена некоторая документация с официального сайта, а также работает Webogram.