Руководство. Создание и отправка сертификатов для тестирования

2025-03-27

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

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

Внимание

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

В следующем руководстве используются OpenSSL и OpenSSL Cookbook, чтобы описать, как выполнить следующие задачи:

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

Примечание.

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

Предварительные условия

Подписка Azure. Если у вас еще нет подписки Azure, создайте бесплатную учетную запись, прежде чем начинать работу.
Центр Интернета вещей в подписке Azure. Если у вас еще нет центра, выполните действия, описанные в разделе Создание центра Интернета вещей.
Последняя версия Git. Обязательно добавьте GIT в переменные среды, доступные в командном окне. На странице средств Git клиентов от Software Freedom Conservancy можно найти последнюю версию инструментов для установки, которая включает 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 и выполните следующую команду, заменив {base_dir} на желаемый каталог, в котором в этом руководстве будут создаваться сертификаты.
```
cd {base_dir}
```

В окне Git Bash выполните следующие команды одновременно. На этом шаге создается следующая структура каталогов и вспомогательные файлы для корневого ЦС.

Каталог или файл	Описание
rootca	Корневой каталог корневого ЦС.
rootca/certs	Каталог, в котором создаются и хранятся сертификаты корневого центра сертификации.
rootca/db	Каталог, в котором хранятся база данных сертификатов и файлы поддержки корневого ЦС.
rootca/db/index	База данных сертификатов для корневого ЦС. Команда `touch` создает файл без содержимого для последующего использования. База данных сертификатов — это обычный текстовый файл, управляемый OpenSSL, содержащий сведения о выданных сертификатах. Дополнительные сведения о базе данных сертификатов см. на странице руководства opensl-ca .
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.conf в каталоге rootca , который был создан на предыдущем шаге. Откройте этот файл в текстовом редакторе, а затем скопируйте и сохраните следующие параметры конфигурации OpenSSL в этот файл.

Файл предоставляет OpenSSL со значениями, необходимыми для настройки тестового корневого ЦС. В этом примере файл настраивает корневой ЦС с именем rootca с помощью каталогов и файлов, созданных на предыдущих шагах. Файл также предоставляет параметры конфигурации для следующих компонентов:
- Политика ЦС, используемая корневым ЦС для полей "Различающееся имя сертификата" (DN)
- Запросы сертификатов, созданные корневым центром сертификации
- Расширения X.509, применяемые к сертификатам корневого ЦС, подчиненным сертификатам ЦС и сертификатам клиента, выданным корневым ЦС
Примечание.

Атрибут home в разделе ca_default установлен на ../rootca, так как этот файл конфигурации также используется при создании сертификата для подчиненного УЦ. Указанный относительный путь позволяет OpenSSL перемещаться из подчиненной папки ЦС в корневую папку ЦС во время этого процесса.

Дополнительные сведения о синтаксисе файлов конфигурации OpenSSL см. на странице config в документации OpenSSL.
```
[default]
name                     = rootca
domain_suffix            = exampledomain.com
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               = "rootca_common_name"

[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
```
В окне Git Bash выполните следующую команду, чтобы создать запрос на подпись сертификата (CSR) в rootca каталоге и закрытый ключ в каталоге rootca/private . Дополнительные сведения о команде OpenSSSL см. на req manual" в документации по OpenSSL.

Примечание.

Рекомендуем не копировать и не предоставлять общий доступ к закрытому ключу, даже если этот корневой ЦС предназначен для тестирования и не является частью инфраструктуры открытых ключей (PKI).
- Windows
- Linux
```
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закрытого ключа присутствует в подкаталоге private , прежде чем продолжить.
В окне Git Bash выполните следующую команду, чтобы создать самоподписанный корневой сертификат ЦС. Команда применяет ca_ext расширения файла конфигурации к сертификату. Эти расширения указывают, что сертификат предназначен для корневого ЦС и может использоваться для подписывания сертификатов и списков отзыва сертификатов (CRLS). Дополнительные сведения о команде OpenSSL см. на странице руководства openssl-ca в документации по ca OpenSSL.
- Windows
- Linux
```
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:
    {Details omitted from output for clarity}
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
Database updated
```
После обновления базы данных сертификатов OpenSSL убедитесь, что файл rootca.crtсертификата присутствует в rootca каталоге, а файл сертификата PEM (PEM) для сертификата присутствует в каталоге rootca/certs . Имя файла с расширением .pem совпадает с серийным номером корневого сертификата УЦ.

Создание подчиненного ЦС

После создания внутреннего корневого ЦС необходимо создать подчиненный ЦС для использования в качестве промежуточного ЦС , с помощью которого подписываются сертификаты клиента для устройств. В теории, вам не нужно создавать подчиненный ЦС; Сертификат корневого ЦС можно передать в центр Интернета вещей и подписать сертификаты клиента непосредственно из корневого ЦС. Однако использование подчиненного ЦС в качестве промежуточного ЦС для подписания клиентских сертификатов более точно отражает рекомендуемую для эксплуатации среду, в которой ваш корневой ЦС хранится в режиме офлайн. Вы также можете использовать подчиненный ЦС для подписи другого подчиненного ЦС, который, в свою очередь, может подписать другой подчиненный ЦС и т. д. Использование подчиненных ЦС для подписывания других подчиненных ЦС создает иерархию промежуточных ЦС в рамках цепочки доверия сертификатов. В рабочей среде цепочка доверия сертификатов позволяет делегированию доверия к устройствам подписывания. Дополнительные сведения о входе устройств в цепочку доверия сертификатов см. в разделе "Проверка подлинности удостоверений с помощью сертификатов X.509".

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

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

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

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

Создайте текстовый файл с именем subca.conf в каталоге subca , который был создан на предыдущем шаге. Откройте этот файл в текстовом редакторе, а затем скопируйте и сохраните следующие параметры конфигурации OpenSSL в этот файл.

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

Дополнительные сведения о синтаксисе конфигурационных файлов OpenSSL см. на главной странице руководства по конфигурации в документации OpenSSL.

[default]
name                     = subca
domain_suffix            = exampledomain.com
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               = "subca_common_name"

[ca_default]
home                     = ../subca
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

В окне Git Bash выполните следующие команды, чтобы создать закрытый ключ и запрос на подпись сертификата (CSR) в подчиненном каталоге ЦС.
- Windows
- Linux
```
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 закрытого ключа присутствует в подкаталоге private , прежде чем продолжить.
В окне Git Bash выполните следующую команду, чтобы создать подчиненный сертификат ЦС в подчиненном каталоге ЦС. Команда применяет sub_ca_ext расширения файла конфигурации к сертификату. Эти расширения указывают, что сертификат предназначен для подчиненного ЦС, а также может использоваться для подписывания сертификатов и списков отзыва сертификатов (CRLS). В отличие от сертификата корневого ЦС, этот сертификат не подписывается самостоятельно. Вместо этого подчиненный сертификат ЦС подписывается с помощью корневого сертификата ЦС, устанавливая цепочку сертификатов, аналогичную тому, что вы будете использовать для инфраструктуры открытых ключей (PKI). Затем сертификат подчиненного удостоверяющего центра используется для подписания клиентских сертификатов для тестирования ваших устройств.
- Windows
- Linux
```
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:
    {Details omitted from output for clarity}
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
Database updated
```
После обновления базы данных сертификатов OpenSSL убедитесь, что файл subca.crt сертификата присутствует в подчиненном каталоге ЦС. Затем убедитесь, что файл сертификата PEM (PEM) для сертификата присутствует в каталоге rootca/certs . Имя файла .pem совпадает с серийным номером подчинённого сертификата УЦ.

Зарегистрируйте подчиненный сертификат ЦС вашего IoT-хаба

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

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

Отправленный подчиненный сертификат ЦС отображается с заданным состоянием "Проверено " на вкладке "Сертификаты " рабочей панели.

Создание сертификата клиента для устройства

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

Сертификат клиента должен иметь значение поля "Общее имя субъекта" (CN), заданное для значения идентификатора устройства, используемого при регистрации соответствующего устройства в Центр Интернета вещей Azure.

Выполните следующие действия.

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

В окне Git Bash убедитесь, что вы все еще находитесь в каталоге subca .
В окне Git Bash выполните следующие команды одновременно. Замените заполнитель именем устройства Интернета вещей, например testdevice. На этом шаге создается закрытый ключ и CSR для сертификата клиента.

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

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

После предоставления сведений о сертификате 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) []:'<DEVICE_NAME>'
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
```
Убедитесь, что CSR-файл присутствует в подчиненном каталоге ЦС. Затем убедитесь, что файл закрытого ключа присутствует в подкаталоге private , прежде чем продолжить. Дополнительные сведения о форматах файлов CSR и закрытых ключей см. в сертификатах X.509.
В окне Git Bash выполните следующую команду, заменив заполнители имени устройства тем же именем, что и в предыдущих шагах.

На этом шаге создается сертификат клиента в подчиненном каталоге ЦС. Команда применяет client_ext расширения файла конфигурации к сертификату. Эти расширения указывают, что сертификат предназначен для сертификата клиента, который нельзя использовать в качестве сертификата ЦС. Сертификат клиента подписан подчиненным сертификатом ЦС.
- Windows
- Linux
```
winpty openssl ca -config subca.conf -in <DEVICE_NAME>.csr -out <DEVICE_NAME>.crt -extensions client_ext
```
```
openssl ca -config subca.conf -in <DEVICE_NAME>.csr -out <DEVICE_NAME>.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:
    {Details omitted from output for clarity}
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
Database updated
```
После обновления базы данных сертификатов OpenSSL убедитесь, что файл сертификата для сертификата клиента присутствует в подчиненном каталоге ЦС. Затем убедитесь, что файл сертификата PEM (PEM) для сертификата клиента присутствует в подкаталоге сертификатов подчиненного каталога ЦС. Имя файла PEM совпадает с серийным номером сертификата клиента.

Следующие шаги

Вы можете зарегистрировать устройство в Центре Интернета вещей для тестирования сертификата клиента, созданного для этого устройства. Дополнительные сведения о регистрации устройства см. в статье Создание и управление идентификациями устройств.

При наличии нескольких связанных устройств для тестирования можно использовать Службу подготовки устройств Azure IoT Hub для назначения нескольких устройств в группе регистрации. Для получения дополнительной информации об использовании групп регистрации в службе подготовки устройств см. учебник подготовка нескольких устройств X.509 с помощью групп регистрации.