Enter pem pass phrase что это

Первый экран: информация о закрытом ключе

Сначала сценарий выдаст вам информацию о том, куда будет сохранен ваш закрытый ключ:

------------------------------------------------------------------------ Creating the cryptographic keypair for your certificate. The file named /home/test/.globus/userkey.pem will contain your private key. This file must not be shared with anyone and must be kept in a safe place. Never transfer your private key using plain communication channels (email, telnet sessions, ftp and so on). Choose strong password for your private key. Remember, CP/CPS states that the password should be at least 15 characters long. If you will forget your password no one will help you: your certificate will become useless. NEVER USE EMPTY PASSWORD! NEWER STORE YOUR PASSWORD ALONG WITH THE PRIVATE KEY! ------------------------------------------------------------------------ Press [Enter].

От вас требуется прочитать выведенное, запомнить или записать полный путь к закрытому ключу и нажать клавишу «Enter».

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

------------------------------------------------------------------------ Creating the cryptographic keypair for your certificate. The file named /home/test/.globus/testhost.ru/hostkey.pem will contain your private key. This file must not be shared with anyone and must be kept in a safe place. Never transfer your private key using plain communication channels (email, telnet sessions, ftp and so on). ------------------------------------------------------------------------ Press [Enter].

Второй экран: ввод пароля закрытого ключа

После нажатия клавиши «Enter» будет сгенерирован закрытый ключ:

Generating a 1024 bit RSA private key . ++++++ . ++++++ unable to write 'random state' writing new private key to '/home/test/.globus/userkey.pem' Enter PEM pass phrase:

Приглашение «Enter PEM pass phrase:» выдается только для пользовательских сертификатов. В ответ на это приглашение нужно ввести пароль, которым будет зашифрован закрытый ключ. Далее вам будет предложено еще раз набрать пароль, чтобы проверить правильность ввода:

Verifying - Enter PEM pass phrase:

Если пароли в обоих попытках не совпадут, то будет выдано соответствующее сообщение и вам придется снова дважды ввести пароль:

Verifying - Enter PEM pass phrase: Verify failure Enter PEM pass phrase:

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

Verifying - Enter PEM pass phrase: phrase is too short, needs to be at least 4 chars Enter PEM pass phrase:

Завершающий экран

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

----- ------------------------------------------------------------------------ All done. Your private key is stored in the file /home/test/.globus/userkey.pem Your request was automatically sent through the CA Web interface. You will be mailed back with the serial number of your request. Then you should completely fill the paper request form and go to your Registration Authority to complete your request. You will need you public key modulus: E248BAF5F2 1E383E741C36B496F7EF19A1A82A77534CA4E914⇒ D45378D25904D012227F90D29B6809C82933632C431AC26FC479EF⇒ 6092B9CBF5199DD61A21E5E325C23472E277866F18550BE544A956⇒ 7DFD4608444866239BEB66C05A23E1E350EE02806C6FFCD0B3CAD0⇒ 6DC3FB8F2787228DC662C7C1FF4B8669EC 088870E793 10 starting digits and 10 ending digits of modulus was separated by spaces from the rest of the digits for your convinience. ------------------------------------------------------------------------ Press [Enter].

Внутри этого сообщения есть несколько важных частей.

Часть первая

All done. Your private key is stored in the file /home/test/.globus/userkey.pem

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

Суффикс имени файла

Обратите внимание, что файл может называться не «userkey.pem», а, например, «userkey.20080116-191210.pem». Это может произойти потому что на момент запуска сценария файл «userkey.pem» уже существует и, возможно, содержит какой-то закрытый ключ. Поэтому сценарий будет использовать другой файл: к исходному имени добавляется суффикс, основанный на текущих дате и времени.

Если суффикс используется, то он дописывается ко всем создаваемым файлам:

$ ls ~/.globus usercert.20080116-191210.pem userkey.pem usercert.pem userreq.20080116-191210.mail userkey.20080116-191210.pem userreq.mail

В этом примере сценарий был запущен тогда, когда в каталоге ~/.globus/ уже существовали файлы usercert.pem, userkey.pem и userreq.mail. Но даже если бы в каталоге ~/.globus/ существовал бы только один из этих файлов, то все три созданных файла все равно бы имели суффикс «.20080116-191210».

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

Часть вторая

Your request was automatically sent through the CA Web interface.

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

Если вместо этого вы получаете сообщение

Now you should send the message, contained in the file /home/test/.globus/userreq.mail to rdig-ca@grid.kiae.ru

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

Третья часть

You will be mailed back with the serial number of your request. Then you should completely fill the paper request form and go to your Registration Authority to complete your request. You will need you public key modulus: E248BAF5F2 1E383E741C36B496F7EF19A1A82A77534CA4E914⇒ D45378D25904D012227F90D29B6809C82933632C431AC26FC479EF⇒ 6092B9CBF5199DD61A21E5E325C23472E277866F18550BE544A956⇒ 7DFD4608444866239BEB66C05A23E1E350EE02806C6FFCD0B3CAD0⇒ 6DC3FB8F2787228DC662C7C1FF4B8669EC 088870E793 10 starting digits and 10 ending digits of modulus was separated by spaces from the rest of the digits for your convinience.

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

Четвертая часть, необязательная

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

Your private key and certificate have non-standard names to avoid overwriting of your current files. When you will get your certificate you should backup your current certificate and the private key and overwrite them with the new files. 
Итог работы сценария
После отработки сценария в директории ~/.globus/ (или её поддиректории) должны появиться файлы с закрытым ключом и запросом, который, если сценарий не смог автоматически передать запрос через Web-интерфейс, необходимо отослать обратно в RDIG CA. 
Имена файлов различны для разных типов сертификатов: 
Тип сертификата
Файл с закрытым ключом
Файл с запросом
Пользовательский
~/.globus/userkey.pem
~/.globus/userreq.mail
Сертификат узла
~/.globus//hostkey.pem
~/.globus//hostreq.mail
Сертификат сервиса
~/.globus/-/hostkey.pem
~/.globus/-/hostreq.mail
В некоторых случаях имена файлов могут быть немного другими, но сценарий в конце своей работы выдаст имена файлов, которые были для вас сгенерированы.
Отправка запроса в RDIG CA
Если файл с запросом не был автоматически отправлен сценарием создания запроса, то он может быть отправлен в RDIG CA двумя способами: 

  
электронной почтой по адресу rdig-cagrid.kiae.ru,
  
используя Web-интерфейс.

В случае отсылки по электронной почте, запрос нужно отправлять в теле письма, а не как вложение (attachment). Также стоит удостовериться, что ваш почтовый агент никак не изменяет содержимое файла запроса: не разделяет чересчур длинные строки на несколько, не вставляет лишних заголовков в тело запроса и т.д. Лучший способ отправки запроса по электронной почте — команда mail: 
$ mail rdig-cagrid.kiae.ru < userreq.mail

После отправки запроса в RDIG CA, на указанный вами в запросе адрес должно придти потверждение о получении вашего запроса. В нём будет содержаться серийный номер вашего запроса. Используйте его при заполнении бумажной формы.
Может случиться, что вы в течении долгого времени (порядка четырёх-пяти часов) не получаете ответа от RDIG CA с серийным номером вашего запроса. Если вы отправляли запрос по электронной почте, то, вероятно, ваш почтовый агент как-то повредил сгенерированный текст и запрос был отброшен как недействительный. В этом случае, пожалуйста, воспользуйтесь Web-интерфейсом отправки запроса.
Исли и это не исправит ситуации — напишите по адресу rdig-ca-supportgrid.kiae.ru, описав сделанные вами шаги, указав дату и время отсылки запроса в RDIG CA и способ отправки: через Web-интерфейс или электронной почтой. В случае отсылки электронной почтой укажите почтовый адрес, с которого отсылался запрос.
Посещение Registration Authority
При посещении вашего Registration Authority (список всех RA) вам будет необходимо представить ему бумажную форму запроса на сертификат, заполненную и подписанную вами. В форму должны быть заполнены поле с серийным номером запроса и поле с модулем открытого ключа.
Вдобавок, вы должны расписаться и поставить дату в первой части бумажной формы, которая ограничена рамкой с надписью «Заполняется пользователем» (это для сертификата пользователя; для сертификата узла надпись гласит «Заполняется администратором узла», а для сертификата сервиса — «Заполняется администратором сервиса»).
Во второй части бумажной формы, рамка которой имеет подпись «Заполняется Registration Authority», писать ничего не нужно.
Также вам будет необходимо иметь с собой паспорт и ваше рабочее удостоверение (если таковое используются внутри вашей организации).
Модуль открытого ключа вы сможете получить после успешного завершения работы ранее загруженного файла сценария, а номер запроса — после отправки сгенерированного сценарием запроса в RDIG CA.
Registration Authority удостоверит вашу личность, проверит правильность вашего запроса и ваше право получать сертификат в RDIG CA. Registration Authority имеет право отвергнуть ваш запрос или задержать его одобрение; при этом он должен объяснить вам причину данного действия.
Дальнейшие шаги
После того, как вы посетите вашего Registration Authority и он одобрит или отвергнет ваш запрос, вам должно придти об этом уведомление. Уведомление придет по электронной почте, на адрес, который вы указывали, создавая запрос на получение сертификата.
Письмо об отвержении вашего запроса означает, что Registration Authority не счел возможным выдачу вам сертификата. В письме будет изложена причина отвержения. Если вы просто ошиблись при заполнении формы, указали неправильные данные или сделали что-то подобное, то вы можете попытаться получить сертификат, сделав новый запрос на получение сертификата.
Письмо об одобрении запроса означает, что ваша заявка автоматически поступит операторам RDIG CA и в течение трёх рабочих дней ваш запрос будет рассмотрен. Результатом рассмотрения, скорее всего, станет выдача сертификата.
Готовый сертификат придёт вам по электронной почте. Если сертификат не приходит долгое время, то проверьте страницу действительных сертификатов: быть может, ваш сертификат был подписан, но электронное сообщение не дошло. Тогда сохраните содержимое вашего сертификата на вашу локальную машину.
Руководство. Создание и отправка сертификатов для тестирования
Сертификаты X.509 можно использовать для проверки подлинности устройств в Центре Интернета вещей. Для рабочих сред рекомендуется приобрести сертификат ЦС X.509 у профессионального поставщика служб сертификации. Затем вы можете выдавать сертификаты в организации из внутреннего самоуправляемого центра сертификации (ЦС), привязанного к приобретенному сертификату ЦС в рамках комплексной стратегии инфраструктуры открытых ключей (PKI). Дополнительные сведения о получении сертификата ЦС X.509 от профессионального поставщика служб сертификации см. в разделе Получение сертификата ЦС X.509статьи Проверка подлинности устройств с помощью сертификатов ЦС X.509.
Однако создание собственного самостоятельного частного ЦС, использующего внутренний корневой ЦС в качестве привязки доверия, подходит для тестовых сред. Самоуправляемый частный ЦС с по крайней мере одним подчиненным ЦС, привязанным к внутреннему корневому ЦС, с клиентскими сертификатами для устройств, подписанными подчиненными ЦС, позволяет смоделировать рекомендуемую рабочую среду.
Мы не рекомендуем использовать самозаверяемые сертификаты для рабочих сред. Это руководство представлено только в демонстрационных целях.
В следующем руководстве используются OpenSSL и поваренная книга OpenSSL , чтобы описать, как выполнять следующие задачи:

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

Корпорация Майкрософт предоставляет скрипты PowerShell и Bash, которые помогут вам понять, как создавать собственные сертификаты X.509 и проверять их подлинность в Центре Интернета вещей. Скрипты включены в пакет SDK для Центр Интернета вещей Azure устройств для C. Скрипты предоставляются только в демонстрационных целях. Не используйте в рабочей среде созданные с помощью этих скриптов сертификаты. Они содержат жестко заданные пароли ("1234"). Срок действия таких сертификатов истекает через 30 дней. Необходимо использовать собственные рекомендации по созданию сертификатов и управлению жизненным циклом в рабочей среде. Дополнительные сведения см. в статье Управление сертификатами тестового ЦС для примеров и учебников в репозитории GitHub для пакета SDK для Центр Интернета вещей Azure устройств для C.
Предварительные требования

Подписка Azure. Если у вас еще нет подписки Azure, создайте бесплатную учетную запись, прежде чем начинать работу.
Центр Интернета вещей в подписке Azure. Если у вас еще нет центра, выполните действия, описанные в разделе Создание центра Интернета вещей.
Последняя версия Git. Обязательно добавьте GIT в переменные среды, доступные в командном окне. Последнюю версию средств git для установки, которая включает Git Bash (приложение командной строки для взаимодействия с локальным репозиторием GIT), можно найти на этой странице.
Установка OpenSSL . В Windows установка Git включает установку OpenSSL. Вы можете получить доступ к OpenSSL из командной строки Git Bash. Чтобы убедиться, что OpenSSL установлен, откройте командную строку Git Bash и введите openssl version .

Примечание Если вы не знакомы с OpenSSL и уже установили его на компьютере с Windows, рекомендуется использовать OpenSSL из командной строки Git Bash. Кроме того, можно скачать исходный код и выполнить сборку OpenSSL. Дополнительные сведения см. на странице Загрузки OpenSSL . Кроме того, можно скачать предварительно созданную версию OpenSSL от стороннего производителя. Дополнительные сведения см. на вики-сайте OpenSSL. Корпорация Майкрософт не гарантирует допустимость пакетов, скачанных сторонними организациями. Если вы решили выполнить сборку или скачивание OpenSSL, убедитесь, что двоичный файл OpenSSL доступен по вашему пути, а для переменной OPENSSL_CNF среды задан путь к файлу openssl.cnf .
Создание корневого ЦС
Сначала необходимо создать внутренний корневой центр сертификации (ЦС) и самозаверяющий сертификат корневого ЦС, чтобы служить в качестве привязки доверия, из которой можно создавать другие сертификаты для тестирования. Файлы, используемые для создания и обслуживания внутреннего корневого ЦС, хранятся в структуре папок и инициализируются в рамках этого процесса. Выполните следующие действия, чтобы:

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


Запустите окно Git Bash и выполните следующую команду, заменив нужным каталогом, в котором будет создан корневой ЦС.



Каталог или файл
Описание




rootca
Корневой каталог корневого ЦС.


rootca/certs
Каталог, в котором создаются и хранятся сертификаты ЦС для корневого ЦС.


rootca/db
Каталог, в котором хранятся база данных сертификатов и файлы поддержки для корневого ЦС.


rootca/db/index
База данных сертификатов для корневого ЦС. Команда touch создает файл без содержимого для последующего использования. База данных сертификатов — это обычный текстовый файл, управляемый OpenSSL, который содержит сведения о выданных сертификатах. Дополнительные сведения о базе данных сертификатов см. на странице руководства openssl-ca в документации по OpenSSL.


rootca/db/serial
Файл, используемый для хранения серийного номера следующего сертификата, который будет создан для корневого ЦС. Команда openssl создает 16-байтовое случайное число в шестнадцатеричном формате, а затем сохраняет его в этом файле для инициализации файла для создания сертификата корневого ЦС.


rootca/db/crlnumber
Файл, используемый для хранения серийных номеров отозванных сертификатов, выданных корневым ЦС. Команда echo передает пример серийного номера 1001 в файл.


rootca/private
Каталог, в котором хранятся закрытые файлы для корневого ЦС, включая закрытый ключ.
Файлы в этом каталоге должны быть защищены и защищены.



mkdir rootca cd rootca mkdir certs db private chmod 700 private touch db/index openssl rand -hex 16 > db/serial echo 1001 > db/crlnumber 


Заполнитель
Описание





Имя корневого ЦС. Например, rootca .



Суффикс доменного имени для корневого ЦС. Например, example.com .



Общее имя корневого ЦС. Например, Test Root CA .




Политика ЦС, используемая корневым ЦС для полей различающегося имени сертификата (DN)
Запросы сертификатов, созданные корневым ЦС
Расширения X.509, применяемые к сертификатам корневого ЦС, сертификатам подчиненного ЦС и сертификатам клиента, выданным корневым ЦС

Атрибуту home в ca_default разделе присвоено значение ../rootca , так как этот файл конфигурации также используется при создании сертификата для подчиненного ЦС. Указанный относительный путь позволяет OpenSSL переходить из подчиненной папки ЦС в корневую папку ЦС во время этого процесса.
Дополнительные сведения о синтаксисе файлов конфигурации OpenSSL см. на странице руководства по настройке в документации по OpenSSL.
[default] name = domain_suffix = aia_url = http://$name.$domain_suffix/$name.crt crl_url = http://$name.$domain_suffix/$name.crl default_ca = ca_default name_opt = utf8,esc_ctrl,multiline,lname,align [ca_dn] commonName = "" [ca_default] home = ../rootca database = $home/db/index serial = $home/db/serial crlnumber = $home/db/crlnumber certificate = $home/$name.crt private_key = $home/private/$name.key RANDFILE = $home/private/random new_certs_dir = $home/certs unique_subject = no copy_extensions = none default_days = 3650 default_crl_days = 365 default_md = sha256 policy = policy_c_o_match [policy_c_o_match] countryName = optional stateOrProvinceName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [req] default_bits = 2048 encrypt_key = yes default_md = sha256 utf8 = yes string_mask = utf8only prompt = no distinguished_name = ca_dn req_extensions = ca_ext [ca_ext] basicConstraints = critical,CA:true keyUsage = critical,keyCertSign,cRLSign subjectKeyIdentifier = hash [sub_ca_ext] authorityKeyIdentifier = keyid:always basicConstraints = critical,CA:true,pathlen:0 extendedKeyUsage = clientAuth,serverAuth keyUsage = critical,keyCertSign,cRLSign subjectKeyIdentifier = hash [client_ext] authorityKeyIdentifier = keyid:always basicConstraints = critical,CA:false extendedKeyUsage = clientAuth keyUsage = critical,digitalSignature subjectKeyIdentifier = hash 
Примечание Несмотря на то, что этот корневой ЦС предназначен для тестирования и не будет предоставляться как часть инфраструктуры открытых ключей (PKI), рекомендуется не копировать и не предоставлять общий доступ к закрытому ключу.
winpty openssl req -new -config rootca.conf -out rootca.csr \ -keyout private/rootca.key 
openssl req -new -config rootca.conf -out rootca.csr \ -keyout private/rootca.key 
Вам будет предложено ввести парольную фразу PEM, как показано в следующем примере, для файла закрытого ключа. Введите и подтвердите парольную фразу для создания закрытого ключа и CSR.
Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- 
Прежде чем продолжить, убедитесь, что CSR-файл rootca.csr присутствует в каталоге rootca , а файл закрытого ключа rootca.key — в закрытом подкаталоге. Дополнительные сведения о форматах файлов CSR и закрытых ключей см. в разделе Сертификаты X.509.
winpty openssl ca -selfsign -config rootca.conf -in rootca.csr -out rootca.crt \ -extensions ca_ext 
openssl ca -selfsign -config rootca.conf -in rootca.csr -out rootca.crt \ -extensions ca_ext 
Вам будет предложено указать парольную фразу PEM, как показано в следующем примере, для файла закрытого ключа. После указания парольной фразы OpenSSL создает сертификат, а затем предлагает подписать и зафиксировать сертификат для корневого ЦС. Укажите y в обоих запросах на создание самозаверяющего сертификата для корневого ЦС.
Using configuration from rootca.conf Enter pass phrase for ../rootca/private/rootca.key: Check that the request matches the signature Signature ok Certificate Details: Certificate is to be certified until Mar 24 18:51:41 2033 GMT (3650 days) Sign the certificate? [y/n]: 1 out of 1 certificate requests certified, commit? [y/n] Write out database with 1 new entries Data Base Updated 
После обновления базы данных сертификатов OpenSSL убедитесь, что файл сертификата rootca.crt присутствует в каталоге rootca , а PEM-файл сертификата (PEM) — в каталоге rootca/certs . Имя pem-файла совпадает с серийным номером сертификата корневого ЦС. Дополнительные сведения о форматах файлов сертификатов см. в разделе Сертификаты X.509.
Создание подчиненного ЦС
После создания внутреннего корневого ЦС необходимо создать подчиненный ЦС, который будет использоваться в качестве промежуточного ЦС для подписи сертификатов клиента для устройств. Теоретически вам не нужно создавать подчиненный ЦС; Вы можете отправить сертификат корневого ЦС в Центр Интернета вещей и подписать сертификаты клиента непосредственно из корневого ЦС. Однако использование подчиненного ЦС в качестве промежуточного ЦС для более точной подписи сертификатов клиента имитирует рекомендуемую рабочую среду, в которой корневой ЦС хранится в автономном режиме. Вы также можете использовать подчиненный ЦС для подписи другого подчиненного ЦС, который, в свою очередь, может подписать другой подчиненный ЦС и т. д. Использование подчиненных ЦС для подписывания других подчиненных ЦС создает иерархию промежуточных ЦС в рамках цепочки доверия сертификатов. В рабочей среде цепочка доверия сертификатов позволяет делегирование доверия устройствам подписывания. Дополнительные сведения о подписи устройств в цепочке доверия сертификатов см. в статье Проверка подлинности устройств с помощью сертификатов ЦС X.509.
Как и в случае с корневым ЦС, файлы, используемые для создания и обслуживания подчиненного ЦС, хранятся в структуре папок и инициализируются в рамках этого процесса. Выполните следующие действия.

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


Запустите окно Git Bash и выполните следующую команду, заменив каталогом, содержащим ранее созданный корневой ЦС. В этом примере как корневой ЦС, так и подчиненный ЦС находятся в одном базовом каталоге.



Заполнитель
Описание





Имя каталога для подчиненного ЦС. Например, subca .



На этом шаге создается структура каталогов и вспомогательные файлы для подчиненного ЦС, аналогичные структуре папок и файлам, созданным для корневого ЦС в разделе Создание корневого ЦС.
mkdir cd mkdir certs db private chmod 700 private touch db/index openssl rand -hex 16 > db/serial echo 1001 > db/crlnumber 


Заполнитель
Описание





Имя подчиненного ЦС. Например, subca .



Суффикс имени домена для подчиненного ЦС. Например, example.com .



Общее имя подчиненного ЦС. Например, Test Subordinate CA .



Как и в случае с файлом конфигурации для корневого ЦС теста, этот файл предоставляет OpenSSL со значениями, необходимыми для настройки подчиненного ЦС теста. Вы можете создать несколько подчиненных ЦС для управления сценариями тестирования или средами. Дополнительные сведения о синтаксисе файлов конфигурации OpenSSL см. на странице конфигурации master вручную в документации по OpenSSL.
[default] name = domain_suffix = aia_url = http://$name.$domain_suffix/$name.crt crl_url = http://$name.$domain_suffix/$name.crl default_ca = ca_default name_opt = utf8,esc_ctrl,multiline,lname,align [ca_dn] commonName = "" [ca_default] home = ../ database = $home/db/index serial = $home/db/serial crlnumber = $home/db/crlnumber certificate = $home/$name.crt private_key = $home/private/$name.key RANDFILE = $home/private/random new_certs_dir = $home/certs unique_subject = no copy_extensions = copy default_days = 365 default_crl_days = 90 default_md = sha256 policy = policy_c_o_match [policy_c_o_match] countryName = optional stateOrProvinceName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [req] default_bits = 2048 encrypt_key = yes default_md = sha256 utf8 = yes string_mask = utf8only prompt = no distinguished_name = ca_dn req_extensions = ca_ext [ca_ext] basicConstraints = critical,CA:true keyUsage = critical,keyCertSign,cRLSign subjectKeyIdentifier = hash [sub_ca_ext] authorityKeyIdentifier = keyid:always basicConstraints = critical,CA:true,pathlen:0 extendedKeyUsage = clientAuth,serverAuth keyUsage = critical,keyCertSign,cRLSign subjectKeyIdentifier = hash [client_ext] authorityKeyIdentifier = keyid:always basicConstraints = critical,CA:false extendedKeyUsage = clientAuth keyUsage = critical,digitalSignature subjectKeyIdentifier = hash 
winpty openssl req -new -config subca.conf -out subca.csr \ -keyout private/subca.key 
openssl req -new -config subca.conf -out subca.csr \ -keyout private/subca.key 
Вам будет предложено ввести парольную фразу PEM, как показано в следующем примере, для файла закрытого ключа. Введите и проверьте парольную фразу, чтобы создать закрытый ключ и CSR.
Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- 
Прежде чем продолжить, убедитесь, что CSR-файл subca.csr находится в подчиненном каталоге ЦС, а файл закрытого ключа subca.key — в закрытом подкаталоге. Дополнительные сведения о форматах файлов CSR и закрытых ключей см. в разделе Сертификаты X.509.
winpty openssl ca -config ../rootca/rootca.conf -in subca.csr -out subca.crt \ -extensions sub_ca_ext 
openssl ca -config ../rootca/rootca.conf -in subca.csr -out subca.crt \ -extensions sub_ca_ext 
Вам будет предложено ввести парольную фразу, как показано в следующем примере, для файла закрытого ключа корневого ЦС. После ввода парольной фразы OpenSSL создаст и отобразит сведения о сертификате, а затем предложит подписать и зафиксировать сертификат для подчиненного ЦС. Укажите y для обоих запросов, чтобы создать сертификат для подчиненного ЦС.
Using configuration from rootca.conf Enter pass phrase for ../rootca/private/rootca.key: Check that the request matches the signature Signature ok Certificate Details: Certificate is to be certified until Mar 24 18:55:00 2024 GMT (365 days) Sign the certificate? [y/n]: 1 out of 1 certificate requests certified, commit? [y/n] Write out database with 1 new entries Data Base Updated 
После того как OpenSSL обновит базу данных сертификатов, убедитесь, что файл сертификата subca.crt присутствует в подчиненном каталоге ЦС и что PEM-файл сертификата (PEM- файл) для сертификата находится в каталоге rootca/certs . Имя pem-файла совпадает с серийным номером сертификата подчиненного ЦС. Дополнительные сведения о форматах файлов сертификатов см. в разделе Сертификаты X.509.
Регистрация сертификата подчиненного ЦС в Центре Интернета вещей
После создания сертификата подчиненного ЦС необходимо зарегистрировать его в Центре Интернета вещей, который использует его для проверки подлинности устройств во время регистрации и подключения. Регистрация сертификата — это двухэтапный процесс, который включает в себя отправку файла сертификата, а затем подтверждение владения. При отправке подчиненного сертификата ЦС в Центр Интернета вещей можно настроить автоматическую проверку сертификата, чтобы не было необходимости вручную устанавливать подтверждение владения. Ниже описано, как отправить и автоматически проверить сертификат подчиненного ЦС в Центр Интернета вещей.


В портал Azure перейдите в Центр Интернета вещей и выберите Сертификаты в меню ресурсов в разделе Параметры безопасности.
Выберите Добавить на панели команд, чтобы добавить новый сертификат ЦС.
Введите отображаемое имя для сертификата подчиненного ЦС в поле Имя сертификата .
Выберите PEM-файл сертификата (PEM) подчиненного сертификата ЦС из каталога rootca/certs , чтобы добавить его в поле PEM- или CER-файл сертификата .
Установите флажок Задать для параметра "Состояние сертификата" значение "проверено при передаче" . 
Щелкните Сохранить.

Отправленный сертификат подчиненного ЦС отображается с состоянием Проверено на вкладке Сертификаты рабочей области.
Создание сертификата клиента для устройства
После создания подчиненного ЦС можно создать сертификаты клиента для своих устройств. Файлы и папки, созданные для подчиненного ЦС, используются для хранения CSR, закрытого ключа и файлов сертификатов для сертификатов клиента.
Сертификат клиента должен иметь значение в поле Общего имени субъекта (CN), равное значению идентификатора устройства, который использовался при регистрации соответствующего устройства в Центр Интернета вещей Azure. Дополнительные сведения о полях сертификатов см. в разделе Поля сертификатовсертификатов X.509.
Выполните следующие действия.

Создание закрытого ключа и запроса на подпись сертификата (CSR) для сертификата клиента
Создание сертификата клиента, подписанного подчиненным сертификатом ЦС


Запустите окно Git Bash и выполните следующую команду, заменив каталогом, содержащим созданный ранее корневой ЦС и подчиненный ЦС.



Заполнитель
Описание





Имя каталога для подчиненного ЦС. Например, subca .



Имя устройства Интернета вещей. Например, testdevice .



На этом шаге создается 2048-разрядный закрытый ключ RSA для сертификата клиента, а затем создается запрос на подпись сертификата (CSR) с помощью этого закрытого ключа.
cd winpty openssl genpkey -out private/.key -algorithm RSA \ -pkeyopt rsa_keygen_bits:2048 winpty openssl req -new -key private/.key -out .csr 
cd openssl genpkey -out private/.key -algorithm RSA \ -pkeyopt rsa_keygen_bits:2048 openssl req -new -key private/.key -out .csr 
Вам будет предложено указать сведения о сертификате, как показано в следующем примере. Замените следующие заполнители соответствующими значениями.


Заполнитель
Описание



*device_id>
Идентификатор устройства Интернета вещей. Например, testdevice .


При необходимости можно ввести собственные значения для других полей, таких как название страны, название организации и т. д. Вам не нужно указывать пароль запроса или необязательное название компании. После предоставления сведений о сертификате OpenSSL создает и отображает сведения о сертификате, а затем предлагает подписать и зафиксировать сертификат для подчиненного ЦС. Укажите y для обоих запросов на создание сертификата для подчиненного ЦС.
----- Country Name (2 letter code) [XX]:. State or Province Name (full name) []:. Locality Name (eg, city) [Default City]:. Organization Name (eg, company) [Default Company Ltd]:. Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server hostname) []:'' Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: 
Прежде чем продолжить, убедитесь, что CSR-файл присутствует в подчиненном каталоге ЦС, а файл закрытого ключа — в закрытом подкаталоге. Дополнительные сведения о форматах CSR-файлов и файлов закрытого ключа см. в разделе Сертификаты X.509.
winpty openssl ca -config subca.conf -in .csr -out .crt \ -extensions client_ext 
openssl ca -config subca.conf -in .csr -out .crt \ -extensions client_ext 
Вам будет предложено ввести парольную фразу, как показано в следующем примере, для файла закрытого ключа подчиненного ЦС. После ввода парольной фразы OpenSSL создает и отображает сведения о сертификате, а затем предлагает подписать и зафиксировать сертификат клиента для вашего устройства. Укажите y для обоих запросов на создание сертификата клиента.
Using configuration from subca.conf Enter pass phrase for ../subca/private/subca.key: Check that the request matches the signature Signature ok Certificate Details: Certificate is to be certified until Mar 24 18:51:41 2024 GMT (365 days) Sign the certificate? [y/n]: 1 out of 1 certificate requests certified, commit? [y/n] Write out database with 1 new entries Data Base Updated 
После того как OpenSSL обновит базу данных сертификатов, убедитесь, что файл сертификата клиента присутствует в подчиненном каталоге ЦС и что PEM-файл сертификата (PEM) для сертификата клиента присутствует в подкаталоге certs подчиненного каталога ЦС. Имя pem-файла совпадает с серийным номером сертификата клиента. Дополнительные сведения о форматах файлов сертификатов см. в разделе Сертификаты X.509.
Дальнейшие действия
Вы можете зарегистрировать устройство в Центре Интернета вещей для тестирования сертификата клиента, созданного для этого устройства. Дополнительные сведения о регистрации устройства см. в разделе Регистрация нового устройства в Центре Интернета вещей статьи Создание центра Интернета вещей с помощью портал Azure.
Если у вас есть несколько связанных устройств для тестирования, можно использовать службу подготовки устройств Центр Интернета вещей Azure для подготовки нескольких устройств в группе регистрации. Дополнительные сведения об использовании групп регистрации в службе подготовки устройств см. в статье Руководство. Подготовка нескольких устройств X.509 с помощью групп регистрации.


Похожие публикации:

Absolute reminder что это за программа
Ssl pinning что это
Для чего используется корончатая зубчатая передача
Как сменить пользователя в приложении вк