Руководство. общие сведения о сертификатах x.509 с открытым ключом для центра интернета вещей azure

Способы конвертации

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

Конвертация SSl сертификатов посредством OpenSSL

OpenSSL — это надежный, коммерческий и полнофункциональный инструментарий для протоколов Transport Layer Security (TLS) и Secure Sockets Layer (SSL). А также библиотека криптографии общего назначения. Конвертация с использованием библиотеки OpenSSL считается одним из самых безопасных способов: все данные будет сохранены непосредственно на устройстве, на котором будут выполняться операции по конвертированию.

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

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

Конвертировать PEM в DER можно посредством команды:

openssl x509 -outform der -in site.crt -out site.der

Аналогично, для других типов:

PEM в P7B

openssl crl2pkcs7 -nocrl -certfile site.crt -out site.p7b -certfile site.ca-bundle

PEM в PFX

openssl pkcs12 -export -out site.pfx -inkey site.key -in site.crt -certfile site.ca-bundle

Обращаем ваше внимание, что после выполнения команды, будет запрошена установка пароля ключа. DER в PEM

DER в PEM

openssl x509 -inform der -in site.der -out site.crt

P7B в PEM

openssl pkcs7 -print_certs -in site.p7b -out site.cer

P7B в PFX

openssl pkcs7 -print_certs -in site.p7b -out certificate.ceropenssl pkcs12 -export -in site.cer -inkey site.key -out site.pfx -certfile site.ca-bundle

PFX в PEM

openssl pkcs12 -in site.pfx -out site.crt -nodes

Конвертация при помощи онлайн-сервисов

Для конвертации сертификатов самый удобный способ — использование специальных сайтов, например, https://ssl4less.ru/ssl-tools/convert-certificate.html

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

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

Для конвертации необходим только файл сертификата .crt, .pem

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

В этом случае существует возможность добавить также цепочку сертификатов.

Что такое цепочка сертификатов и для чего она нужна, можно узнать в статье «Что такое корневой сертификат»

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

В этом случае необходимо обратить внимание на то, что обязателен ключ сертификата, а также необходимо установить пароль ключа. Конвертация из DER в PEM

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

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

Конвертация из P7B в PFX

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

Конвертация скриптом openssl-ToolKit

OpenSSL ToolKit — скрипт, который облегчает работу с библиотекой OpenSSL. Работа со скриптом является безопасным решением, т.к сертификаты и ключи сертификата никуда не передаются, а используются непосредственно на вашем сервере.

Для начала работы скрипт необходимо скачать и запустить. Сделать это можно одной командой:

echo https://github.com/tdharris/openssl-toolkit/releases/download/1.1.0/openssl-toolkit-1.1.0.zip \
| xargs wget -qO- -O tmp.zip && unzip -o tmp.zip && rm tmp.zip && ./openssl-toolkit/openssl-toolkit.sh

После выполнения команды откроется следующее окно:

Нас интересует пункт

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

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

В нашем случае мы их скачали в директорию

После корректного ввода директории, скрипт отобразит все файлы в этой директории.

Далее нужно ввести имя сертификата, который будем конвертировать, в нашем случае это

Обращаю ваше внимание, что для корректной конвертации, с PEM в PFX, необходимо вручную объединить файл сертификата, цепочки и ключа в один файл, иначе будет возникать ошибка конвертации. Сделать это можно простой командой

Сделать это можно простой командой

cat site.crt site.ca-bundle site.key > site.pem

Данное действие необходимо только для конвертации из PEM в PFX.

Мы рассмотрели пример конвертации PEM в PFX. Этим же путем можно конвертировать сертификаты в другие форматы. Единственное, что вам уже не понадобится шаг с объединением файлов.

Пример конвертации PEM В DER.

Что делать если нет сертификата в запросах заявок на сертификат

Бывают ситуации, что на вашем сервере по каким-то причинам, в папке запросы на сертификат, может не оказаться вашего, в этом случае вам необходимо будет перейти в этой же mmc в раздел «Личное-Сертификаты». Выбираем нужный и делаем экспорт.

Появится мастер экспорта сертификатов.

Обратите внимание, что в pfx выгрузить не получится, но это не страшно, нам подойдет и p7b, но с включенной галкой «Включить по возможности все сертификаты в путь сертификации»

Указываем путь сохраняемого файла.

Видим, что все успешно выполнено.

Преобразование p7b в pem

Попробует такое преобразование.

openssl pkcs7 -in cert.p7b -inform DER -print_certs -out cert.pem

Мой пример

openssl.exe pkcs7 -in new.pyatilistnik.ru.p7b -inform DER -print_certs -out new.pyatilistnik.ru.pem

В итоге я получил файл new.pyatilistnik.ru.pem

Ну, а дальше уже по инструкции сверху. Если у вас выскочит ошибка, по типу

C:\AMD64-Win64OpenSSL-0_9_8g>openssl.exe rsa -in new.pyatilistnik.ru.pem -out new. pyatilistnik.ru.key unable to load Private Key 6944:error:0906D06C:PEM routines:PEM_read_bio:no start line:.\crypto\pem\pem_lib .c:647:Expecting: ANY PRIVATE KEY

То наш вариант это .crt в .der и уже .der в .pem

Преобразование CRT в PEM

Кладем так же все в одну папку, файл crt вам должны были прислать вместе с ca-bundle.

Первое это crt в der

openssl x509 -in new.pyatilistnik.ru.crt -out new.pyatilistnik.ru.der -outform DER

Теперь der в pem.

openssl x509 -in new.pyatilistnik.ru.der -inform DER -out new.pyatilistnik.ru.pem -outform PEM

В итоге у меня получилось, вот так.

Поля сертификата

Со временем появились три версии сертификата. В каждой из версий добавлялись новые поля. Версия 3, которая действует в настоящий момент, содержит все поля версий 1 и 2, дополненные полями версии 3. Версия 1 определяет следующие поля:

Version (Версия) — значение 1, 2 или 3, которое указывает используемую версию сертификата.
Serial Number (Серийный номер) — уникальный идентификатор, который присваивается каждому сертификату ЦС.
CA Signature Algorithm (Алгоритм подписывания ЦС) — имя алгоритма, который ЦС использует для подписывания содержимого сертификата.
Issuer Name (Имя издателя) — различающееся имя ЦС, который выдал этот сертификат.
Validity Period (Период действия) — период времени, в течение которого сертификат считается действительным.
Subject Name (Имя субъекта) — имя сущности, которую представляет сертификат.
Subject Public Key Info (Данные открытого ключа субъекта) — открытый ключ, принадлежащий субъекту сертификата.

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

Issuer Unique ID (Уникальный идентификатор издателя): уникальный идентификатор центра сертификации, который выдал сертификат. Он определяется самим центром сертификации.
Subject Unique ID (Уникальный идентификатор субъекта) — уникальный идентификатор субъекта сертификата, который определяется ЦС, выдавшим сертификат.

В сертификатах версии 3 добавлены следующие расширения:

Authority Key Identifier (Идентификатор ключа центра) — может содержать одно из двух значений:
- субъект ЦС и серийный номер сертификата ЦС, который выдал сертификат;
- хэш-код открытого ключа ЦС, который выдал этот сертификат.
Subject Key Identifier (Идентификатор ключа субъекта) — хэш-код открытого ключа сертификата.
Key Usage (Использование ключа) — определяет службу, для которой можно использовать сертификат. Здесь могут содержаться одно или несколько значений из следующего списка:
- Цифровая подпись
- Неотрекаемость
- Шифрование ключа
- Data Encipherment (Шифрование данных);
- Key Agreement (Согласование ключей);
- Key Cert Sign (Подпись сертификата с ключом);
- CRL Sign (Подпись списка отзыва сертификатов);
- Encipher Only (Только шифрование);
- Decipher Only (Только расшифровка).
Private Key Usage Period (Период использования закрытого ключа) — период действия закрытого ключа из пары ключей.
Certificate Policies (Политики сертификатов) — политики, используемые для проверки субъекта сертификата.
Policy Mappings (Сопоставления политик) — сопоставляет политику в одной организации с политикой в другой.
Subject Alternative Name (Альтернативное имя субъекта) — список альтернативных имен для субъекта.
Issuer Alternative Name (Альтернативное имя издателя) — список альтернативных имен для ЦС, выдавшего сертификат.
Subject Dir Attribute (Атрибут DIR субъекта) — атрибуты из каталога X.500 или LDAP.
Basic Constraints (Базовые ограничения) — позволяет определить в сертификате, кому он выдан: ЦС, пользователю, компьютеру, устройству или службе. Это расширение также включает ограничение длины пути, которое ограничивает допустимое количество подчиненных ЦС в цепочке.
Name Constraints (Ограничения имен) — определяет, какие пространства имен разрешены в сертификате, выданном ЦС.
Policy Constraints (Ограничения политики) — позволяет запретить сопоставления политик между ЦС.
Extended Key Usage (Расширенное использование ключа) — указывает, как можно использовать открытый ключ сертификата, кроме целей, определяемых расширением Key Usage (Использование ключа).
CRL Distribution Points (Точки распространения списков отзыва сертификатов) — содержит один или несколько URL-адресов, в которых публикуется базовый список отзыва сертификатов.
Inhibit anyPolicy (Запрет любой политики) — запрещает использование значения All Issuance Policies (Все политики выдачи) с идентификатором OID (2.5.29.32.0) в сертификатах подчиненного ЦС.
Freshest CRL (Актуальный список отзыва сертификатов) — содержит один или несколько URL-адресов, в которых публикуется разностный список отзыва сертификатов ЦС, выдавшего этот сертификат.
Authority Information Access (Доступ к информации центра) — содержит один или несколько URL-адресов, в которых публикуется сертификат ЦС, выдавшего этот сертификат.
Subject Information Access (Доступ к сведениям о субъекте) — содержит сведения о том, как можно получить дополнительные сведения о субъекте сертификата.

Что изменилось в CSP 5.0 R2 12000

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

Нами был написан модуль поддержки Cryptoki (cryptoki.dll, cprocsp-rdr-cryptoki), который отображает интерфейс READER в PKCS#11. Поскольку этот релиз является первым с данной опцией, он обладает рядом особенностей:

Рутокен

Поддержка носителей Рутокен полностью переведена на PKCS#11 на всех платформах. CSP 5.0 R2 не будет работать с неизвлекаемыми ключами, пока не будет установлена библиотека PKCS#11. Свежие версии библиотеки умеют перечислять и использовать и старые ключи, которые были созданы в КриптоПро CSP 5.0 11455 через READER;
Если вам всё еще нужна поддержка «старого формата» напрямую — например, для создания ключей, которые будут работать в CSP 5.0.11455, её можно вернуть тут: Панель управления — КриптоПро CSP — Оборудование — Настроить типы носителей — Рутокен ЭЦП — Свойства — Настройки — Включить режим совместимости. Режим включается одной галкой не для одного токена, а для всех носителей Рутокен (в т.ч. Рутокен ПинПад, Рутокен 2151 и т.д.)

На Unix поддержка возвращается так: cpconfig -ini ‘\config\parameters’ -add long EnableNativeTokenCryptMode 1

JaCarta и ESMART

По умолчанию на Windows для данных носителей ничего не изменилось — используется старый режим работы.
Для регистрации поддержки PKCS#11 нужно переподключить модуль PKCS#11:

Панель управления — КриптоПро CSP — Оборудование — Настроить считыватели — Считыватель смарт-карт PKCS#11 — Удалить — Добавить — Считыватель смарт-карт PKCS#11.

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

На Linux и MacOS регистрация PKCS#11 прописывается по умолчанию.

Создание ключей и имя считывателя

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

Например:

Имя считывателя для PKCS#11-режима, которое используется в формате FQCN, отличается от стандартного. В перечислении оно начинается с PKCS11:

Winlogon, Распространение сертификата и RDP

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

При подключении токена к системе сертификаты из PKCS#11-контейнеров не устанавливаются в хранилище автоматически. Рекомендуем для этого пользоваться кнопкой «Установить сертификат» в Инструментах КриптоПро (cptools):

Использование PKCS#11-ключей для подключения по RDP или входа в систему через Winlogon невозможно.

Поддержка иных библиотек PKCS#11

Технически вы можете подключить любую другую библиотеку PKCS#11. Если она следует стандарту и его расширениям от ТК26, то, скорее всего, её поддержка заработает «из коробки». Подобное подключение будет соответствовать правилам использования КриптоПро CSP только при использовании ключевых носителей из Формуляра CSP.

Добавить можно в свойствах считывателя PKCS#11: Панель управления — КриптоПро CSP — Оборудование — Настроить считыватели — Считыватель смарт-карт PKCS#11 — Свойства — Настройки:

Обратите внимание, что на данной вкладке обязательно указывать путь только до 64-разрядной библиотеки. Если она будет находиться в стандартной системной директории System32, то 32-разрядная библиотека будет автоматически загружаться из директории SysWOW64

Если же вы тестируете библиотеки, не установленные в системный стандартный путь, рекомендуем прописать путь до обеих библиотек.

Несколько важных замечаний, на которые нужно обратить внимание:

cptools (Инструменты КриптоПро) является 32-разрядным приложением. Некорректная регистрация 32-разрядной PKCS#11-библиотеки не позволит её использовать через данную утилиту;
мы рекомендуем использовать только самые последние версии сторонних библиотек;
если на машине установлено несколько криптопровайдеров, работающих с одной pkcs#11-библиотекой, они могут мешать друг другу в ряде случаев (например, при создании запросов на сертификат). Рекомендуем убрать регистрации используемых носителей из других критопровайдеров.

История

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

Предвкушение

В своей книге 1874 г. Принципы науки , Уильям Стэнли Джевонс писал:

Здесь он описал связь односторонних функций с криптографией и продолжил обсуждение конкретно проблемы факторизации, используемой для создания функции лазейки . В июле 1996 года математик Соломон В. Голомб сказал: «Джевонс предвидел ключевую особенность алгоритма RSA для криптографии с открытым ключом, хотя он определенно не изобрел концепцию криптографии с открытым ключом».

Секретное открытие

В 1970 году Джеймс Х. Эллис , британский шифровальщик из штаб-квартиры правительства Великобритании (GCHQ), задумал возможность «несекретного шифрования» (теперь называемого криптографией с открытым ключом), но не нашел способа реализовать его. В 1973 году его коллега Клиффорд Кокс внедрил то, что стало известно как алгоритм шифрования RSA , дав практический метод «несекретного шифрования», а в 1974 году другой математик и криптограф GCHQ, Малкольм Дж. Уильямсон , разработал то, что теперь известно как Обмен ключами Диффи – Хеллмана . Схема также была передана в Агентство национальной безопасности США . Обе организации имели военную направленность, и в любом случае были доступны лишь ограниченные вычислительные мощности; потенциал криптографии с открытым ключом остался нереализованным ни одной из организаций:

Эти открытия не были публично признаны в течение 27 лет, пока исследование не было рассекречено британским правительством в 1997 году.

Публичное открытие

В 1976 году Уитфилд Диффи и Мартин Хеллман опубликовали криптосистему с асимметричным ключом, которые под влиянием работы Ральфа Меркла по распределению открытых ключей раскрыли метод согласования открытых ключей. Этот метод обмена ключами, который использует , стал известен как обмен ключами Диффи – Хеллмана . Это был первый опубликованный практический метод установления общего секретного ключа по аутентифицированному (но не конфиденциальному) каналу связи без использования предварительного общего секрета. «Техника согласования открытых ключей» Меркла стала известна как «Пазлы Меркла» , была изобретена в 1974 году и опубликована только в 1978 году.

В 1977 году Рон Ривест , Ади Шамир и Леонард Адлеман независимо друг от друга изобрели обобщение схемы Кокса, работавших тогда в Массачусетском технологическом институте . Последние авторы опубликовали свою работу в 1978 году Мартин Гарднер «s Scientific American колонке, и алгоритм стал известен , как RSA , с их инициалами. RSA использует возведение в степень по модулю произведения двух очень больших простых чисел для шифрования и дешифрования, выполняя как шифрование с открытым ключом, так и цифровые подписи с открытым ключом. Его безопасность связана с чрезвычайной трудностью факторизации больших целых чисел , проблемой, для которой не существует известной эффективной общей техники (хотя разложение на простые множители может быть получено с помощью атак грубой силы; это тем труднее, чем больше простые множители). Описание алгоритма было опубликовано в колонке « Математические игры» в августовском выпуске журнала Scientific American за 1977 год .

С 1970-х годов было разработано большое количество разнообразных методов шифрования, цифровой подписи, согласования ключей и других методов, включая криптосистему Рабина , шифрование Эль-Гамаля , DSA и криптографию на основе эллиптических кривых .

Файл-контейнер

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

Внешние программы, например Microsoft Outlook, Microsoft Word/Excel или любая программа создания и проверки электроной подписи, при вызове функций подписания или проверки обращаются к части операционной системы, отвечающей за криптографию (Microsoft Crypto API), которая в зависимости от задействованных криптографических алгоритмов вызывает соответствующий криптопровайдер. В нашем случае используется отечественная криптография. Поскольку Microsoft Windows не имеет встроенной поддержки российских алгоритмов электронной подписи, следует установить криптопровайдер отечественной криптографии.
Если сертификат подписи был заранее установлен в систему (в Хранилище сертификатов), то криптопровайдер знает, в каком контейнере от какого сертификата лежит закрытый ключ, и требует от пользователя ввода пароля от этого контейнера. Если закрытый ключ расположен на электронном ключе, криптопровайдер запрашивает пин-код. При успешном вводе пароля контейнер открывается, осуществляются операции с использованием закрытого ключа, после чего контейнер закрывается.

Про использование криптопровайдера и Microsoft Outlook/Office рассказывается в статье Использование электронного ключа доступа к порталу госуслуг для осуществления электронной подписи. Если требуется создать электронную подпись произвольного документа, например, XML-формы запроса «Единого реестра доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено» с сайта http://zapret-info.gov.ru, необходимо программное обеспечение с соответствующим функционалом (создание электронной подписи в формате PKCS#7).

При использовании программного криптопровайдера создание подписи с использованием квалифицированного сертификата, содержащегося в файле-контейнере и на электронном ключе ничем не отличается.

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

Рассмотрим частный случай второго варианта.

Установка OpenSSL для Windows

Теперь нам необходимо наш файл pfx переделать в pem, Pem преобразовать в key:

с расширением .ca-bundle
с расширением .crt
key

Вы получите из этих трех файлов, нужный для импорта pfx архив. Во всем этом нам поможет утилита OpenSSL для Windows.

Скачать OpenSSL для Windows x64 — https://cloud.mail.ru/public/MZmy/yKvJkc7Ad

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

В результате чего у вас откроется командная строка Windows, но уже в нужной папке содержащей утилиту openssl.exe, она нам и поможет все сделать красиво.

Преобразование PFX в PEM

Теперь приступаем к получению фала в формате Pem. Положите в папку с дистрибутивом файл в формате pfx.

openssl.exe pkcs12 -in «имя вашего pfx файла» -nocerts -out key.pem

Мой пример:

openssl.exe pkcs12 -in api.pyatilistnik.ru.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.ru.key

Вас попросят указать пароль от pem ключа.

В итоге я получил закрытый ключ в формате key.

Осталась финишная прямая.

Получаем PFX ключ для импорта в IIS

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

Задаем пароль для pfx файла, потребуется при импортировании.

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

Ключевые носители Рутокен и поддерживаемые ими режимы работы

Каждый Рутокен работает в одном, двух или трех режимах.

В таблице указаны носители, продемонстрировавшие работоспособность с соответствующими версиями КриптоПро CSP.

На пересечении строки с названием модели Рутокена и строки с версией КриптоПро CSP указаны режимы работы носителя.

Модель Рутокена	Версия КриптоПро CSP
4.0 R4	5.0 11455	5.0 R2 12000 (в т.ч. сборка с PKCS#11 модулями)	5.0 R3 12234
Рутокен S Рутокен Lite	Пассивный(Режим CSP)	Пассивный(Режим CSP)	Пассивный(Режим CSP)	Пассивный(Режим CSP)
Рутокен ЭЦП 2.0 2100 /Рутокен ЭЦП 2.0 (2000) /Рутокен ЭЦП 2.0 Flash /Рутокен ЭЦП Bluetooth	Пассивный(Режим CSP)	Пассивный (Режим CSP)	Пассивный(Режим CSP)	Пассивный(Режим CSP)
Режим Активный токен без защиты канала (rutoken_crypt)	Режим Активный токен (pkcs11_rutoken_ecp)	Режим Активный токен(pkcs11_rutoken_ecp)
Рутокен 2151 / Смарт-карта Рутокен 2151	Не поддерживается	Не поддерживается	Пассивный (Режим CSP)	Пассивный (Режим CSP)
Режим Активный токен (pkcs11_rutoken_ecp)	Режим Активный токен (pkcs11_rutoken_ecp)
Рутокен ЭЦП PKI	Не поддерживается	Пассивный(Режим CSP)	Пассивный(Режим CSP)	Пассивный(Режим CSP)
Рутокен ЭЦП 2.0 3000	Пассивный(Режим CSP)	Пассивный (Режим CSP)	Пассивный (Режим CSP)	Пассивный (Режим CSP)
Режим ФКН c защитой канала(rutoken_fkc)	Режим Активный токен (pkcs11_rutoken_ecp)	Режим Активный токен(pkcs11_rutoken_ecp)
Режим ФКН c защитой канала (rutoken_fkc)	Режим ФКН c защитой канала (rutoken_fkc)
Смарт-картаРутокен ЭЦП 3.0 NFC (бесконтактное подключение)	Не поддерживается	Не поддерживается	Режим ФКН c защитой канала (rutoken_fkc_nfc)	Режим ФКН c защитой канала (rutoken_fkc_nfc)
Смарт-картаРутокен ЭЦП 3.0 NFC(контактное подключение)	Не поддерживается	Не поддерживается	Пассивный 1(Режим CSP)	Пассивный 1(Режим CSP)
Режим Активный токен 1, 2 (pkcs11_rutoken_ecp)	Режим Активный токен 1, 2(pkcs11_rutoken_ecp)
Режим ФКН c защитой канала (rutoken_fkc_nfc)	Режим ФКН c защитой канала (rutoken_fkc_nfc)
Смарт-картаРутокен ЭЦП 2.0 2100	Пассивный(Режим CSP)	Пассивный (Режим CSP)	Пассивный(Режим CSP)	Пассивный(Режим CSP)
Режим Активный токен без защиты канала (rutoken_crypt)	Режим Активный токен (pkcs11_rutoken_ecp)	Режим Активный токен(pkcs11_rutoken_ecp)

1 не работает в ОС Android и iOS

2 не поддерживается в ОС Аврора

Как получить такой сертификат?

Вариантов и инструкций в Интернете достаточно много. В том числе у нас на вики в статье «».

В следующих разделах — краткие инструкции по самым популярным сервисам:

Lets’ Encrypt и certbot

Потребуется установить программу certbot. Под *nix- системами это сделать проще, но под Windows тоже не потребуется сверхъестественных усилий.

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

Предположим, что certbot у вас установлен. Что дальше? Запускаем несколько консольных команд.

Зарегистрироваться:

certbot register -m emailадминистратора@вашдомен.com

Сгенерировать сертификат:

certbot certonly --webroot -w /var/www/папкасервера -d вашдомен.com -d www.вашдомен.com

Если опасаетесь, что что-то не так и хотите сначала потренироваться, добавьте опцию —dry-run (режим эмуляции для отладки ошибок)

certbot certonly --dry-run --webroot -w /var/www/папкасервера -d вашдомен.com -d www.вашдомен.com

После успешной генерации сертификата у вас появятся 4 файла (их расположение также сильно зависит от вашей операционной системы):

cert.pem (конечный сертификат),
chain.pem (цепочка доверия от корневого сертификата, не включающая конечный),
fullchain.pem (нужная нам полная цепочка, включая конечный сертификат, по сути это сложение cert.pem + chain.pem),
privkey.pem (ваш приватный ключ, который никому нельзя ни показывать, ни отсылать).

Для веб-сервера необходимы два из них: fullchain.pem и privkey.pem.

Ещё несколько полезных команд certbot

Проверка и обновление сертификатов (полезно поставить запуск этой команды по расписанию):

certbot -q renew

Для проверки и обновления также есть тестовый режим (чтобы убедиться. что ваши домены будут обновляться):

certbot renew --dry-run

Добавление новых доменов и поддоменов к сертификату:

certbot certonly --webroot -w /var/www/папкасервера --expand -d вашдомен.com -d test.вашдомен.com -d www.вашдомен.ru

Изменение адреса администратора:

certbot register --update-registration -m newemail@вашдомен.ru

SSL For Free

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

Выбор настроек (обычно ничего трогать не нужно, просто жмите «Next Step»)
Подтверждение прав на домен, для которого получаете сертификат, любым из способов:
- на почту его владельца (список готовый, посторонний адрес вписать не получится) — вам должен быть доступен один из перечисленных email.
- изменением полей DNS (CNAME) — для новичков этот способ самый запутанный, но не требует доступности почты и http.
- скачиванием подтверждающего файла и размещением его в подпапке сайта — к домену должен быть http-доступ из Интернета в момент проверки.
После подтверждения останется выбрать формат: предлагается список шаблонов (Default, Tomcat, AWS, cPanel, Google App, Heroku. nginx, Plesk, итд) — но во всех случаях, кажется, скачивается идентичный архив.

Сертификат готов, но… сервис SSL For Free создаёт три файла:

ca_bundle.crt (цепочка, исключая конечный сертификат)
certificate.crt (сам конечный сертификат)
private.key (ваш приватный ключ, который никому нельзя ни показывать, ни отсылать).

Поэтому fullchain мы склеим вручную из двух первых файлов (сначала certificate.crt, затем ca_bundle.crt), и назовём его fullchain.crt (имена на самом деле могут быть любыми, но принято — и нужно — использовать «говорящие» названия: fullchain.crt/fullchain.pem, или domain.ca-bundle)

Сделать это можно как консольными командами, так и в обычном Блокноте Windows. Пример консольной команды:

cat domain.crt Intermediate1.crt Intermediate2.crt <все промежуточные что есть через пробел> CARoot.crt > fullchain.crt

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

Серверу отдаём, соответственно, fullchain.crt и private.key.

Немного паранойи

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

Ответ 2

PEM — сам по себе не является сертификатом, это просто способ кодирования данных. Сертификаты X.509 — это один из типов данных, которые обычно кодируются с помощью PEM.

PEM — это сертификат X.509 (структура которого определена с помощью ASN.1), закодированный с помощью ASN.1 DER (distinguished encoding rules), затем закодированный Base64 кодировкой и вставленный между заголовками текста (BEGIN CERTIFICATE и END CERTIFICATE).

Вы можете представить те же данные, используя представления PKCS#7 или PKCS#12, и для этого можно использовать утилиту командной строки OpenSSL.

Очевидным преимуществом PEM является то, что его безопасно вставлять в тело электронного сообщения, поскольку он имеет заголовки и 7-битную кодировку.

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