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

Статья
04/11/2024

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

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

Внимание

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

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

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

Примечание.

Корпорация Майкрософт предоставляет скрипты 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 что переменная среды задана в пути к файлу opensl.cnf .

Создание корневого ЦС

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

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

Запустите окно Git Bash и выполните следующую команду, заменив {base_dir} нужный каталог, в котором необходимо создать сертификаты в этом руководстве.
```
cd {base_dir}
```

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

Каталог или файл	Description
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 см. на странице конфигурации вручную в документации 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 см. на странице "OpenSSSL-req manual" req в документации по 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). Дополнительные сведения о команде OpenSSSL см. на странице руководства openSSL 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
Data Base 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
Data Base Updated
```
После обновления базы данных сертификатов OpenSSL убедитесь, что файл subca.crt сертификата присутствует в подчиненном каталоге ЦС и что файл сертификата PEM (PEM) для сертификата присутствует в каталоге rootca/certs . Имя файла PEM совпадает с серийным номером подчиненного сертификата ЦС.

Регистрация подчиненного сертификата ЦС в Центре Интернета вещей

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

В портал Azure перейдите в центр Интернета вещей и выберите "Сертификаты" в меню ресурсов в разделе "Параметры безопасности".
Выберите " Добавить" на панели команд, чтобы добавить новый сертификат ЦС.
Введите отображаемое имя для подчиненного сертификата ЦС в поле "Имя сертификата".
Выберите файл сертификата PEM (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
Data Base Updated
```
После обновления базы данных сертификатов OpenSSL убедитесь, что файл сертификата для сертификата клиента присутствует в подчиненном каталоге ЦС, а файл сертификата PEM (PEM) для сертификата клиента присутствует в подкаталоге сертификатов подчиненного каталога ЦС. Имя файла PEM совпадает с серийным номером сертификата клиента.

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

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

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

Поделиться через