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

Сведения об использовании сертификатов в Azure IoT Edge

  • Статья

Область применения: Флажок IoT Edge 1.5 IoT Edge 1.5 Флажок IoT Edge 1.4 IoT Edge 1.4

Внимание

Поддерживаются выпуски IoT Edge 1.5 LTS и IoT Edge 1.4 LTS. IoT Edge 1.4 LTS заканчивается жизнью 12 ноября 2024 года. Если вы используете более ранний выпуск, см. статью Обновление IoT Edge.

IoT Edge использует разные типы сертификатов для разных целей. В этой статье описаны различные способы использования сертификатов IoT Edge с сценариями шлюза Центр Интернета вещей Azure и IoT Edge.

Внимание

Для краткости эта статья относится к IoT Edge версии 1.2 или более поздней. Основные понятия сертификата для версии 1.1 аналогичны, но существуют некоторые различия.

  • Сертификат ЦС устройства версии 1.1 был переименован в сертификат ЦС Edge.
  • Сертификат ЦС рабочей нагрузки версии 1.1 был снят. В версии 1.2 или более поздней среда выполнения модуля IoT Edge создает все сертификаты сервера непосредственно из сертификата ЦС Edge без сертификата ЦС промежуточной рабочей нагрузки между ними в цепочке сертификатов.

Итоги

Это основные сценарии, в которых IoT Edge использует сертификаты. Воспользуйтесь ссылками, чтобы больше узнать о каждом сценарии.

Субъект Характер использования Сертификат
IoT Edge Обеспечивает взаимодействие с правильным Центром Интернета вещей Сертификат сервера Центра Интернета вещей
Центр Интернета вещей Обеспечивает поступление запроса от достоверного устройства IoT Edge Сертификат удостоверения для IoT Edge
Подчиненное устройство Интернета вещей Обеспечивает взаимодействие с правильным шлюзом IoT Edge Сертификат модуля сервера edgeHub центра IoT Edge, выданный пограничным ЦС
IoT Edge Подписывает новые сертификаты сервера модуля. Например, edgeHub Сертификат ЦС для пограничного устройства
IoT Edge Обеспечивает поступление запроса от достоверного подчиненного устройства Сертификат удостоверения для устройства Интернета вещей

Необходимые компоненты

Сценарий одного устройства

Чтобы понять основные понятия сертификатов IoT Edge, представьте сценарий, в котором устройство IoT Edge с именем EdgeGateway подключается к Центр Интернета вещей Azure с именем ContosoIotHub. В этом примере все проверки подлинности выполняются с проверкой подлинности сертификата X.509, а не с симметричными ключами. Чтобы установить доверие в этом сценарии, необходимо гарантировать подлинность устройства Центр Интернета вещей и IoT Edge: "Является ли это устройство подлинным и допустимым?" и "Правильно ли удостоверение Центр Интернета вещей?". Сценарий можно проиллюстрировать следующим образом:

Схема состояния доверия, показывающая подключение между устройством IoT Edge и Центр Интернета вещей.

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

Устройство проверяет удостоверение Центр Интернета вещей

Как EdgeGateway проверяет, что он взаимодействует с подлинным ContosoIotHub? Когда EdgeGateway хочет взаимодействовать с облаком, он подключается к конечной точке ContosoIoTHub.Azure-devices.NET. Чтобы убедиться, что конечная точка является аутентичной, IoT Edge требует ContosoIoTHub для отображения идентификации (идентификатора). Идентификатор должен быть выдан центром, которому доверяет EdgeGateway . Чтобы проверить удостоверение Центр Интернета вещей, IoT Edge и Центр Интернета вещей использовать протокол подтверждения TLS для проверки удостоверения сервера Центр Интернета вещей. Подтверждение TLS показано на следующей схеме. Чтобы сохранить пример простым, некоторые сведения были опущены. Дополнительные сведения о протоколе подтверждения TLS см. в разделе подтверждения TLS в Википедии.

Примечание.

В этом примере ContosoIoTHub представляет Центр Интернета вещей имя узла ContosoIotHub.Azure-devices.NET.

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

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

В нашем сценарии ContosoIotHub отображает следующую цепочку сертификатов:

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

Корневой центр сертификации (ЦС) — это корневой сертификат Baltimore CyberTrust. Этот корневой сертификат подписан DigiCert и широко является доверенным и хранящимся во многих операционных системах. Например, Ubuntu и Windows включают его в хранилище сертификатов по умолчанию.

Хранилище сертификатов Windows:

Снимок экрана: корневой сертификат Baltimore CyberTrust, указанный в хранилище сертификатов Windows.

Хранилище сертификатов Ubuntu:

Снимок экрана: корневой сертификат Baltimore CyberTrust, указанный в хранилище сертификатов Ubuntu.

Когда устройство проверяет корневой сертификат Балтимора CyberTrust , он предварительно установлен в ОС. С точки зрения EdgeGateway , так как цепочка сертификатов, представленная ContosoIotHub , подписана корневым ЦС, который доверяет ОС, сертификат считается надежным. Сертификат называется Центр Интернета вещей сертификатом сервера. Дополнительные сведения о сертификате сервера Центр Интернета вещей см. в статье о поддержке tls в Центр Интернета вещей.

В итоге EdgeGateway может проверить и доверять удостоверению ContosoIotHub, так как:

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

Центр Интернета вещей проверяет удостоверение устройства IoT Edge

Как ContosoIotHub проверяет, что он взаимодействует с EdgeGateway? Так как Центр Интернета вещей поддерживает взаимное подтверждение TLS (mTLS), он проверяет сертификат EdgeGateway во время подтверждения TLS, прошедшего проверку подлинности клиента. Для простоты мы пропустим некоторые шаги на следующей схеме.

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

В этом случае EdgeGateway предоставляет свой сертификат удостоверения устройства IoT Edge. С точки зрения ContosoIotHub он проверяет, совпадает ли отпечаток предоставленного сертификата, и EdgeGateway имеет закрытый ключ, связанный с предоставленным сертификатом. При подготовке устройства IoT Edge в Центр Интернета вещей вы предоставляете отпечаток. Отпечаток — это то, что Центр Интернета вещей используется для проверки сертификата.

Совет

Центр Интернета вещей требуется два отпечатка при регистрации устройства IoT Edge. Рекомендуется подготовить два разных сертификата удостоверения устройства с разными датами окончания срока действия. Таким образом, если срок действия одного сертификата истекает, другой по-прежнему действителен и дает время сменить истекший срок действия сертификата. Однако для регистрации также можно использовать только один сертификат. Используйте один сертификат, задав один и тот же отпечаток сертификата для первичных и вторичных отпечатков при регистрации устройства.

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

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

Команда выводит отпечаток сертификата SHA256:

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

Если мы видим значение отпечатка SHA256 для устройства EdgeGateway, зарегистрированного в Центр Интернета вещей, мы видим, что он соответствует отпечатку на EdgeGateway:

Снимок экрана: портал Azure отпечатка устройства EdgeGateway в ContosoIotHub.

В итоге ContosoIotHub может доверять EdgeGateway, так как EdgeGateway представляет действительный сертификат удостоверения устройства IoT Edge, отпечаток которого соответствует одному, зарегистрированным в Центр Интернета вещей.

Дополнительные сведения о процессе создания сертификатов см. в статье "Создание и подготовка устройства IoT Edge в Linux с помощью сертификатов X.509".

Примечание.

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

На портале Azure DPS отображает отпечаток SHA1 для сертификата, а не отпечаток SHA256.

DPS регистрирует или обновляет отпечаток SHA256 на Центр Интернета вещей. С помощью команды openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256можно проверить отпечаток. После регистрации Iot Edge использует проверку подлинности отпечатка с Центр Интернета вещей. Если устройство перепроиздается и выдается новый сертификат, DPS обновляет Центр Интернета вещей с новым отпечатком.

Центр Интернета вещей в настоящее время не поддерживает проверку подлинности ЦС X.509 непосредственно с помощью IoT Edge.

Использование сертификата для операций идентификации модуля

На схемах проверки сертификатов может отображаться, что IoT Edge использует только сертификат для взаимодействия с Центр Интернета вещей. IoT Edge состоит из нескольких модулей. В результате IoT Edge использует сертификат для управления удостоверениями модулей для модулей, отправляющих сообщения. Модули не используют сертификат для проверки подлинности для Центр Интернета вещей, а вместо использования ключей SAS, производных от закрытого ключа, созданного средой выполнения модуля IoT Edge. Эти ключи SAS не изменяются, даже если срок действия сертификата удостоверения устройства истекает. Если срок действия сертификата истек, edgeHub, например, продолжает выполняться, а операции удостоверения модуля завершаются сбоем.

Взаимодействие между модулями и Центр Интернета вещей безопасно, так как ключ SAS является производным от секрета, и IoT Edge управляет ключом без риска вмешательства человека.

Сценарий иерархии вложенных устройств с IoT Edge в качестве шлюза

Теперь у вас есть хорошее представление о простом взаимодействии IoT Edge между и Центр Интернета вещей. Но IoT Edge также может выступать в качестве шлюза для подчиненных устройств или других устройств IoT Edge. Эти каналы связи также должны быть зашифрованы и доверенны. Из-за добавленной сложности мы должны расширить наш пример сценария для включения нижестоящего устройства.

Мы добавим обычное устройство IoT с именем TempSensor, которое подключается к родительскому устройству IoT Edge EdgeGateway, которое подключается к Центр Интернета вещей ContosoIotHub. Как и раньше, все проверки подлинности выполняются с проверкой подлинности сертификата X.509. Наш новый сценарий вызывает два новых вопроса: "Является ли устройство TempSensor допустимым?" и "Правильно ли удостоверение EdgeGateway?". Сценарий можно проиллюстрировать следующим образом:

Схема состояния доверия, показывающая подключение между устройством IoT Edge, шлюзом IoT Edge и Центр Интернета вещей.

Совет

TempSensor — это устройство Интернета вещей в сценарии. Концепция сертификата одинакова, если TempSensor является подчиненным устройством IoT Edge родительского EdgeGateway.

Устройство проверяет удостоверение шлюза

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

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

Поток совпадает с тем, что при подключении EdgeGateway к ContosoIotHub. TempSensor и EdgeGateway используют протокол подтверждения TLS для проверки удостоверения EdgeGateway. Существует две важные детали:

  • Специфика имени узла: сертификат, представленный EdgeGateway, должен быть выдан одному имени узла (домену или IP-адресу), который TempSensor использует для подключения к EdgeGateway.
  • Специфика самозаверяющего корневого ЦС: цепочка сертификатов, представленная EdgeGateway , скорее всего, не находится в доверенном корневом хранилище ОС по умолчанию.

Чтобы понять детали, давайте сначала рассмотрим цепочку сертификатов, представленную EdgeGateway.

Схема потока, показывающая цепочку центров сертификации для шлюза IoT Edge.

Специфика имени узла

Общее имя сертификата CN = edgegateway.local отображается в верхней части цепочки. edgegateway.local — это общее имя сертификата сервера edgeHub. edgegateway.local также является именем узла для EdgeGateway в локальной сети (локальной сети или виртуальной сети), где подключены TempSensor и EdgeGateway . Это может быть частный IP-адрес, например 192.168.1.23 или полное доменное имя (FQDN), как схема. Сертификат сервера edgeHub создается с помощью параметра имени узла, определенного в файле config.toml IoT Edge. Не путайте сертификат сервера EdgeHub с сертификатом ЦС Edge. Дополнительные сведения об управлении сертификатом ЦС Edge см. в статье "Управление сертификатами IoT Edge".

Когда TempSensor подключается к EdgeGateway, TempSensor использует имя узла edgegateway.local для подключения к EdgeGateway. TempSensor проверяет сертификат, представленный EdgeGateway, и проверяет, что общее имя сертификата — edgegateway.local. Если общее имя сертификата отличается, TempSensor отклоняет подключение.

Примечание.

Для простоты в примере показано общее имя сертификата субъекта (CN) в качестве проверенного свойства. На практике, если сертификат имеет альтернативное имя субъекта (SAN), san проверяется вместо CN. Как правило, поскольку SAN может содержать несколько значений, он имеет имя основного домена или узла для владельца сертификата, а также любые альтернативные домены.

Почему EdgeGateway нужно рассказать о своем собственном имени узла?

EdgeGateway не имеет надежного способа узнать, как другие клиенты в сети могут подключаться к нему. Например, в частной сети могут быть DHCP-серверы или службы mDNS, которые перечисляют EdgeGateway как 10.0.0.2 или example-mdns-hostname.local. Но некоторые сети могут иметь DNS-серверы, сопоставленные edgegateway.local с IP-адресом 10.0.0.2EdgeGateway.

Для решения этой проблемы IoT Edge использует настроенное значение config.toml имени узла и создает для него сертификат сервера. Когда запрос поступает в модуль edgeHub , он представляет сертификат с правильным именем сертификата (CN).

Почему IoT Edge создает сертификаты?

В примере обратите внимание, что в цепочке сертификатов есть iotedged workload ca edgegateway . Это центр сертификации (ЦС), который существует на устройстве IoT Edge, известном как Пограничный ЦС (ранее известный как ЦС устройства в версии 1.1). Как и корневой ЦС Балтимора CyberTrust в предыдущем примере, ЦС Edge может выдавать другие сертификаты. Самое главное, а также в этом примере он выдает сертификат сервера модулю EdgeHub . Но он также может выдавать сертификаты другим модулям, работающим на устройстве IoT Edge.

Внимание

По умолчанию без настройки ЦС Edge автоматически создается средой выполнения модуля IoT Edge при первом запуске, известном как краткое руководство по пограничным ЦС, а затем выдает сертификат модулю Edge. Этот процесс ускоряет подключение нижестоящего устройства, позволяя edgeHub представить действительный сертификат, подписанный. Без этой функции вам придется получить ЦС для выдачи сертификата для модуля EdgeHub . Использование автоматически созданного ЦС Edge для быстрого запуска не поддерживается для использования в рабочей среде. Дополнительные сведения о кратком руководстве по ЦС Edge см . в кратком руководстве по ЦС Edge.

Не опасно ли иметь сертификат издателя на устройстве?

Пограничный ЦС предназначен для включения решений с ограниченными, ненадежными, дорогостоящими или отсутствующими подключениями, но в то же время имеют строгие правила или политики для продления сертификатов. Без пограничного ЦС, IoT Edge - и в частности edgeHub - не может функционировать.

Чтобы защитить пограничный ЦС в рабочей среде:

  • Поместите закрытый ключ EdgeCA в доверенном модуле платформы (TPM), желательно таким образом, чтобы закрытый ключ был эфемерно создан и никогда не покидает TPM.
  • Используйте инфраструктуру открытых ключей (PKI), к которой выполняется свертка ЦС Edge. Это обеспечивает возможность отключения или отказа от продления скомпрометированных сертификатов. PKI можно управлять ИТ-отделом клиента, если у них есть сведения о том, как (низкая стоимость) или через коммерческий поставщик PKI.

Специфика самозаверяющего корневого ЦС

Модуль EdgeHub является важным компонентом, который создает IoT Edge, обрабатывая весь входящий трафик. В этом примере используется сертификат, выданный центром сертификации Edge, который, в свою очередь, выдан самозаверяющий корневой ЦС. Так как корневой ЦС не является доверенным ос, единственным способом TempSensor будет доверять это установка сертификата ЦС на устройство. Это также называется сценарием пакета доверия, где необходимо распределить корневой каталог клиентам, которым необходимо доверять цепочке. Сценарий пакета доверия может быть проблемным, так как вам нужен доступ к устройству и установка сертификата. Установка сертификата требует планирования. Это можно сделать с помощью скриптов, добавленных во время производства или предварительно установленного в образе ОС.

Примечание.

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

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

Чтобы проверить цепочку сертификатов, можно использовать openssl на устройстве TempSensor . В этом примере обратите внимание, что имя узла для подключения соответствует CN сертификата глубины 0 и соответствует корневому ЦС.

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

Дополнительные сведения о команде см. в openssl документации по OpenSSL.

Вы также можете проверить сертификаты, в которых они хранятся по умолчанию /var/lib/aziot/certd/certs. В каталоге можно найти сертификаты ЦС Edge, сертификаты удостоверения устройства и сертификаты модулей. Для проверки сертификатов можно использовать openssl x509 команды. Например:

sudo ls -l /var/lib/aziot/certd/certs

total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

В итоге TempSensor может доверять EdgeGateway, так как:

  • Модуль EdgeHub показал действительный сертификат сервера модуля IoT Edge для edgegateway.local
  • Сертификат выдан центром сертификации Edge, выданным my_private_root_CA
  • Этот закрытый корневой ЦС также хранится в TempSensor как доверенный корневой ЦС ранее
  • Криптографические алгоритмы проверяют, можно ли доверять цепочке владения и выдачи.

Сертификаты для других модулей

Другие модули могут получать сертификаты сервера, выданные центром сертификации Edge. Например, модуль Grafana с веб-интерфейсом. Он также может получить сертификат из пограничного ЦС. Модули обрабатываются как подчиненные устройства, размещенные в контейнере. Однако возможность получения сертификата из среды выполнения модуля IoT Edge является особым привилегием. Модули вызывают API рабочей нагрузки для получения сертификата сервера, цепочки с настроенным центром сертификации Edge.

Шлюз проверяет удостоверение устройства

Как EdgeGateway проверяет, что он взаимодействует с TempSensor? EdgeGateway использует проверку подлинности клиента TLS для проверки подлинности TempSensor.

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

Последовательность аналогична проверке устройства ContosoIotHub . Однако в сценарии шлюза EdgeGateway использует ContosoIotHub в качестве источника истины для записи сертификатов. EdgeGateway также сохраняет автономную копию или кэш в случае отсутствия подключения к облаку.

Совет

В отличие от устройств IoT Edge, подчиненные устройства Интернета вещей не ограничиваются проверкой подлинности X.509. Проверка подлинности ЦС X.509 также является вариантом. Вместо того чтобы просто искать совпадение на отпечатке, EdgeGateway также может проверить, является ли сертификат TempSensor корневым в ЦС, который был отправлен в ContosoIotHub.

В итоге EdgeGateway может доверять TempSensor, так как:

  • TempSensor представил допустимый сертификат удостоверения устройства Интернета вещей для его имени.
  • Отпечаток сертификата удостоверения соответствует отпечатку, отправленной в ContosoIotHub.
  • Криптографические алгоритмы проверяют, можно ли доверять цепочке владения и выдачи.

Где получить сертификаты и управление

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

Однако рекомендуется настроить устройства для использования сервера регистрации по протоколу Secure Transport (EST) для управления сертификатами x509. С помощью сервера EST вы можете вручную обрабатывать сертификаты и устанавливать их на устройствах. Дополнительные сведения об использовании сервера EST см. в статье "Настройка регистрации по протоколу Secure Transport Server для Azure IoT Edge".

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

Если вы не можете использовать сервер EST, необходимо запросить сертификаты от поставщика PKI. Файлы сертификатов можно управлять вручную в Центр Интернета вещей и устройствах IoT Edge. Дополнительные сведения см . в разделе "Управление сертификатами" на устройстве IoT Edge.

Для подтверждения разработки концепции можно создать тестовые сертификаты. Дополнительные сведения см. в разделе "Создание демонстрационных сертификатов" для тестирования функций устройств IoT Edge.

Сертификаты в IoT

Центр сертификации

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

Корневой сертификат ЦС

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

Промежуточные сертификаты

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

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

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

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