Comprendre Azure IoT Edge utilise les certificats

S’applique à : IoT Edge 1.5

Important

IoT Edge 1.5 LTS est la version prise en charge. IoT Edge 1.4 LTS est en fin de vie depuis le 12 novembre 2024. Si vous utilisez une version antérieure, consultez l’article Mettre à jour IoT Edge.

IoT Edge utilise différents types de certificats à des fins différentes. Cet article explique comment IoT Edge utilise des certificats avec des scénarios de passerelle Azure IoT Hub et IoT Edge.

Important

Par souci de concision, cet article s’applique à IoT Edge version 1.2 ou ultérieure. Les concepts de certificat pour la version 1.1 sont similaires, mais il existe des différences :

• Le certificat CA de l’appareil dans la version 1.1 est maintenant appelé certificat CA Edge.
• Le certificat d’autorité de certification de charge de travail dans la version 1.1 est mis hors service. Dans la version 1.2 ou ultérieure, le module runtime IoT Edge génère tous les certificats de serveur directement à partir du certificat CA Edge, sans le certificat CA intermédiaire de charge de travail dans la chaîne de certificats.

Résumé

IoT Edge utilise des certificats dans ces scénarios de base. Utilisez les liens pour en savoir plus sur chaque scénario.

Acteur	Objectif	Certificat
IoT Edge	Garantit qu’il communique avec le bon hub IoT	Certificat de serveur IoT Hub
IoT Hub	Garantit que la demande provient d’un appareil IoT Edge légitime	Certificat d’identité IoT Edge
Appareil IoT en aval	Garantit qu’il communique avec la bonne passerelle IoT Edge	Certificat de serveur de module edgeHub IoT Edge Hub, émis par l’autorité de certification Edge
IoT Edge	Signe de nouveaux certificats de serveur de modules. Par exemple, edgeHub	Certificat d'autorité de certification Edge
IoT Edge	Garantit que la demande provient d’un appareil en aval légitime	Certificat d’identité d’appareil IoT

Prérequis

• Vous avez besoin d’une compréhension de base du chiffrement à clé publique, des paires de clés et de la façon dont une clé publique et une clé privée peuvent chiffrer ou déchiffrer des données. Pour plus d’informations sur la façon dont IoT Edge utilise le chiffrement à clé publique, consultez Présentation du chiffrement à clé publique et de l’infrastructure de clé publique X.509.
• Vous avez besoin d’une compréhension de base de la façon dont IoT Edge se rapporte à IoT Hub. Pour plus d’informations, consultez Présentation du runtime Azure IoT Edge et de son architecture.

Scénario avec un seul appareil

Pour vous aider à découvrir les concepts de certificat IoT Edge, imaginez un scénario dans lequel un appareil IoT Edge nommé EdgeGateway se connecte à un hub Azure IoT nommé ContosoIotHub. Dans cet exemple, toutes les authentifications utilisent l’authentification par certificat X.509 au lieu de clés symétriques. Pour établir la confiance dans ce scénario, nous devons garantir que le hub IoT et l’appareil IoT Edge sont authentiques : « Cet appareil est-il authentique et valide ? » et « L’identité du hub IoT est-elle correcte ? ». Voici une illustration du scénario :

Cet article explique les réponses à chaque question, puis développe l’exemple dans les sections ultérieures.

L’appareil vérifie l’identité du hub IoT

Comment vérifie EdgeGateway qu’il parle au vrai ContosoIotHub ? Lorsque EdgeGateway communique avec le cloud, il se connecte au point de terminaison ContosoIoTHub.Azure-devices.NET. Pour vérifier que le point de terminaison est authentique, IoT Edge a besoin que ContosoIoTHub montre son identification (ID). L’ID doit être émis par une autorité approuvée par EdgeGateway. Pour vérifier l’identité de l’IoT Hub, IoT Edge et IoT Hub utilisent le protocole de poignée de main TLS pour vérifier l'identité du serveur de l'IoT Hub. Le diagramme suivant montre un établissement d’une liaison TLS. Certains détails sont laissés pour le garder simple. Pour plus d’informations sur le protocole de négociation TLS , consultez la négociation TLS sur Wikipédia.

Remarque

Dans cet exemple, ContosoIoTHub représente le nom de l’hôte IoT Hub ContosoIotHub.Azure-devices.NET.

Dans ce contexte, vous n’avez pas besoin de connaître les détails exacts de l’algorithme de chiffrement. L’élément clé est que l’algorithme vérifie que le serveur possède la clé privée associée à sa clé publique. Cette vérification prouve que le présentateur de certificat ne l’a pas copié ou volé. Pensez à un ID de photo où votre visage correspond à la photo. Si quelqu’un vole votre ID, il ne peut pas l’utiliser, car votre visage est unique. Pour les clés de chiffrement, la paire de clés est associée et unique. Au lieu de faire correspondre un visage à un ID photo, l’algorithme de chiffrement utilise la paire de clés pour vérifier l’identité.

Dans notre scénario, ContosoIotHub affiche la chaîne de certificats suivante :

L’autorité de certification racine est le certificat racine Baltimore CyberTrust. DigiCert signe ce certificat racine, et il est largement approuvé et stocké dans de nombreux systèmes d’exploitation. Par exemple, Ubuntu et Windows l’incluent dans le magasin de certificats par défaut.

Magasin de certificats Windows :

Magasin de certificats Ubuntu :

Lorsqu’un appareil recherche le certificat Baltimore CyberTrust Root , il est déjà dans le système d’exploitation. Du point de vue de EdgeGateway , étant donné que la chaîne de certificats de ContosoIotHub est signée par une autorité de certification racine approuvée par le système d’exploitation, le certificat est fiable. Ce certificat est appelé certificat de serveur IoT Hub. Pour plus d’informations sur le certificat de serveur IoT Hub, consultez la prise en charge du protocole TLS (Transport Layer Security) dans IoT Hub.

En résumé, EdgeGateway peut vérifier et approuver l’identité de ContosoIotHub pour les raisons suivantes :

• ContosoIotHub présente son certificat de serveur IoT Hub
• Le certificat de serveur est approuvé dans le magasin de certificats du système d’exploitation
• Les données chiffrées avec la clé publique de ContosoIotHub peuvent être déchiffrées par ContosoIotHub, ce qui prouve qu’il possède la clé privée

IoT Hub vérifie l’identité de l’appareil IoT Edge

Comment ContosoIotHub vérifie-t-il qu’il communique avec EdgeGateway ? Étant donné que IoT Hub prend en charge le protocole TLS mutuel (mTLS), il vérifie le certificat de EdgeGateway lors d’une négociation TLS authentifiée par le client. Par souci de simplicité, nous allons ignorer certaines étapes du diagramme suivant.

Dans le cas présent, EdgeGateway fournit son certificat d’identité d’appareil IoT Edge. Du point de vue de ContosoIotHub, il vérifie que l’empreinte numérique du certificat fourni correspond à son enregistrement et que EdgeGateway a la clé privée associée au certificat qu’il présente. Quand vous provisionnez un appareil IoT Edge dans IoT Hub, vous fournissez une empreinte. IoT Hub utilise l’empreinte numérique pour vérifier le certificat.

Conseil

IoT Hub nécessite deux empreintes lorsque vous inscrivez un appareil IoT Edge. Il est préférable de préparer deux certificats d’identité d’appareil différents avec des dates d’expiration différentes. Si un certificat expire, l’autre est toujours valide et vous laisse le temps d’effectuer la rotation du certificat expiré. Mais vous ne pouvez utiliser qu’un seul certificat pour l’inscription. Utilisez un certificat unique en définissant l’empreinte numérique du certificat pour les empreintes primaires et secondaires lorsque vous inscrivez l’appareil.

Par exemple, utilisez la commande suivante pour obtenir l’empreinte numérique du certificat d’identité sur EdgeGateway :

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

La commande affiche l’empreinte SHA256 du certificat :

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

Si vous affichez la valeur d’empreinte SHA256 de l’appareil EdgeGateway inscrit dans IoT Hub, vous voyez qu’il correspond à l’empreinte numérique sur EdgeGateway :

En résumé, ContosoIotHub approuve EdgeGateway, car EdgeGateway présente un certificat d’identité d’appareil IoT Edge valide avec une empreinte numérique qui correspond à celle inscrite dans IoT Hub.

Pour plus d’informations sur le processus de génération de certificats, consultez Créer et approvisionner un appareil IoT Edge sur Linux avec des certificats X.509.

Remarque

Cet exemple ne couvre pas le service de provisionnement des appareils (DPS) Azure IoT Hub, qui prend en charge l’authentification par autorité de certification X.509 avec IoT Edge lorsqu’il est approvisionné via un groupe d’enregistrement. Avec DPS, vous chargez le certificat d’autorité de certification ou un certificat intermédiaire, la chaîne de certificats est vérifiée, puis l’appareil est approvisionné. Pour plus d’informations, consultez Attestation de certificat DPS X.509.

Dans le portail Azure, DPS affiche l’empreinte SHA1 du certificat au lieu de l’empreinte SHA256.

DPS inscrit ou met à jour l’empreinte SHA256 dans IoT Hub. Vous pouvez vérifier l’empreinte numérique à l’aide de la commande openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256. Après l’inscription, IoT Edge utilise l’authentification par empreinte numérique avec IoT Hub. Si l’appareil est reprovisionné et qu’un nouveau certificat est émis, DPS met à jour IoT Hub avec la nouvelle empreinte.

Actuellement, IoT Hub ne prend pas en charge l’authentification par autorité de certification X.509 directement avec IoT Edge.

Utilisation de certificats pour les opérations d’identité de module

Dans les diagrammes de vérification de certificat, il peut sembler qu'IoT Edge utilise uniquement le certificat pour communiquer avec IoT Hub. IoT Edge a plusieurs modules. IoT Edge utilise le certificat pour gérer les identités de module pour les modules qui envoient des messages. Les modules n’utilisent pas le certificat pour s’authentifier auprès d’IoT Hub, mais utilisent des clés SAP dérivées de la clé privée générée par le runtime de module IoT Edge. Ces clés SAS ne changent pas même si le certificat d’identité de l’appareil expire. Si le certificat expire, edgeHub s’exécute toujours, mais seules les opérations d’identité de module échouent.

L’interaction entre les modules et IoT Hub est sécurisée, car la clé SAP est dérivée d’un secret, et IoT Edge gère la clé sans risque d’intervention humaine.

Scénario de hiérarchie d’appareils imbriquée avec IoT Edge comme passerelle

Vous comprenez maintenant une interaction simple entre IoT Edge et IoT Hub. Mais IoT Edge peut également servir de passerelle pour les appareils en aval ou d’autres appareils IoT Edge. Ces canaux de communication doivent être chiffrés et approuvés. En raison de la complexité ajoutée, nous allons développer l’exemple de scénario pour inclure un appareil en aval.

Nous ajoutons un appareil IoT standard nommé TempSensor, qui se connecte à son appareil EdgeGateway IoT Edge parent, qui se connecte au hub IoT ContosoIotHub. Comme précédemment, toutes les authentifications utilisent l’authentification par certificat X.509. Ce scénario soulève deux questions : « L’appareil TempSensor est-il légitime ? » et « L’identité du EdgeGateway est-elle correcte ? ». Le scénario est illustré ici :

Conseil

TempSensor est un appareil IoT dans ce scénario. Le concept de certificat est le même si TempSensor est un appareil IoT Edge en aval ayant comme parent EdgeGateway.

L’appareil vérifie l’identité de la passerelle

Comment TempSensor vérifie-t-il qu’il communique avec la passerelle EdgeGateway authentique ? Quand TempSensor veut communiquer avec EdgeGateway, TempSensor a besoin que EdgeGateway montre un ID. L’ID doit être émis par une autorité approuvée par TempSensor.

Le flux est le même que quand EdgeGateway communique avec ContosoIotHub. TempSensor et EdgeGateway utilisent le protocole de négociation TLS pour vérifier l’identité de EdgeGateway. Deux détails sont importants :

• Spécificité du nom d’hôte : le certificat présenté par EdgeGateway doit être émis avec le même nom d’hôte (domaine ou adresse IP) que celui utilisé par TempSensor pour se connecter à EdgeGateway.
• Spécificité de l’autorité de certification racine auto-signée : la chaîne de certificats présentée par EdgeGateway n’est probablement pas dans le magasin racine approuvé par défaut du système d’exploitation.

Pour comprendre les détails, examinons d’abord la chaîne de certificats présentée par EdgeGateway.

Spécificité du nom d’hôte

Le nom commun du certificat CN = edgegateway.local apparaît en haut de la chaîne. edgegateway.local est le nom commun du certificat de serveur de edgeHub. edgegateway.local est également le nom d’hôte pour EdgeGateway sur le réseau local (réseau local ou VNet) où TempSensor et EdgeGateway sont connectés. Il peut s’agir d’une adresse IP privée comme 192.168.1.23 ou d’un nom de domaine complet (FQDN) comme le diagramme. Le certificat de serveur edgeHub est généré à l’aide du paramètre hostname défini dans le fichier config.toml d’IoT Edge. Ne confondez pas le certificat de serveur edgeHub avec le certificat d’autorité de certification Edge. Pour plus d’informations sur la gestion du certificat d’autorité de certification Edge, consultez Gérer les certificats IoT Edge.

Lorsque TempSensor se connecte à EdgeGateway, TempSensor utilise le nom d’hôte edgegateway.local pour se connecter à EdgeGateway. TempSensor vérifie le certificat présenté par EdgeGateway et vérifie que le nom commun du certificat est edgegateway.local. Si le nom commun du certificat est différent, TempSensor rejette la connexion.

Remarque

Par souci de simplicité, l’exemple montre le nom commun du certificat d’objet (CN) en tant que propriété validée. Dans la pratique, si un certificat a un autre nom d’objet, celui-ci est validé au lieu de CN. En règle générale, comme l’autre nom d’objet peut contenir plusieurs valeurs, il a à la fois le domaine/nom d’hôte principal pour le titulaire du certificat et tous les autres domaines.

Pourquoi EdgeGateway doit-il être informé de son propre nom d’hôte ?

EdgeGateway ne dispose pas d’un moyen fiable de savoir comment les autres clients sur le réseau peuvent s’y connecter. Par exemple, sur un réseau privé, il peut y avoir des serveurs DHCP ou des services mDNS qui répertorient EdgeGateway sous la forme 10.0.0.2 ou example-mdns-hostname.local. Cependant, certains réseaux peuvent avoir des serveurs DNS qui mappent edgegateway.local à l’adresse IP de 10.0.0.2.

Pour résoudre le problème, IoT Edge utilise la valeur de nom d’hôte configurée dans config.toml et crée un certificat de serveur pour celui-ci. Quand une demande arrive au module edgeHub, elle présente le certificat avec le bon nom commun de certificat (CN).

Pourquoi IoT Edge crée-t-il des certificats ?

Dans l’exemple, notez qu’il existe un élément iotedged workload ca edgegateway dans la chaîne de certificats. C’est l’autorité de certification qui existe sur l’appareil IoT Edge, connue sous le nom de Autorité de certification Edge (auparavant appelée Autorité de certification d’appareil dans la version 1.1). Comme l’autorité de certification racine Baltimore CyberTrust dans l’exemple précédent, l’Autorité de certification Edge peut émettre d’autres certificats. Plus important encore, et également dans cet exemple, il émet le certificat de serveur pour le module edgeHub. Cependant, il peut également émettre des certificats pour d’autres modules s’exécutant sur l’appareil IoT Edge.

Important

Par défaut sans configuration, l’Autorité de certification Edge est générée automatiquement par le runtime de module IoT Edge quand il démarre pour la première fois, connu sous le nom de Autorité de certification Edge de démarrage rapide, puis émet un certificat pour le module edgeHub. Ce processus accélère la connexion de l’appareil en aval en permettant à edgeHub de présenter un certificat valide qui est signé. Sans cette fonctionnalité, vous devriez demander à votre autorité de certification d’émettre un certificat pour le module edgeHub. L’utilisation d’une autorité de certification Edge de démarrage rapide générée automatiquement n’est pas prise en charge pour une utilisation en production. Pour plus d’informations sur l’autorité de certification Edge de démarrage rapide, consultez Autorité de certification Edge de démarrage rapide.

N’est-il pas dangereux d’avoir un certificat d’émetteur sur l’appareil ?

L’autorité de certification Edge est conçue pour permettre des solutions avec une connectivité limitée, peu fiable, coûteuse ou absente, mais elle a en même temps des réglementations ou des stratégies strictes sur les renouvellements des certificats. Sans l’autorité de certification Edge, IoT Edge - et en particulier edgeHub - ne peuvent pas fonctionner.

Pour sécuriser l’autorité de certification Edge en production :

• Placez la clé privée EdgeCA dans un module de plateforme sécurisée (TPM), de préférence d’une manière où la clé privée est générée de façon éphémère et ne quitte jamais le module de plateforme sécurisée.
• Utilisez une infrastructure à clé publique (PKI) à laquelle l’autorité de certification Edge s’associe. Cela permet de désactiver ou de refuser le renouvellement des certificats compromis. L’infrastructure à clé publique peut être gérée par le service informatique du client s’il a le savoir-faire (coût inférieur) ou via un fournisseur d’infrastructure à clé publique du marché.

Spécificité de l’autorité de certification racine autosigné

Le module edgeHub est un composant important qui participe à IoT Edge en gérant tout le trafic entrant. Dans cet exemple, il utilise un certificat émis par l’autorité de certification Edge, qui est à son tour émis par une autorité de certification racine auto-signée. Comme l’autorité de certification racine n’est pas approuvée par le système d’exploitation, la seule façon pour TempSensor de l’approuver est d’installer le certificat d’autorité de certification sur l’appareil. Ceci porte aussi le nom de « scénario de bundle d’approbations », où vous devez distribuer la racine aux clients qui doivent approuver la chaîne. Le scénario de bundle d’approbations peut être problématique, car vous devez accéder à l’appareil et installer le certificat. L’installation du certificat nécessite une planification. Elle peut être effectuée avec des scripts, ajoutés lors de la fabrication ou préinstallés dans l’image du système d’exploitation.

Remarque

Certains clients et certains SDK n’utilisent pas le magasin racine approuvé du système d’exploitation, et vous devez passer directement le fichier de l’autorité de certification racine.

En appliquant tous ces concepts, TempSensor peut vérifier qu’il communique avec la passerelle EdgeGateway authentique, car il a présenté un certificat correspondant à l’adresse et le certificat est signé par une racine approuvée.

Pour vérifier la chaîne de certificats, vous pouvez utiliser openssl sur l’appareil TempSensor. Dans cet exemple, notez que le nom d’hôte pour la connexion correspond au CN du certificat de profondeur 0 et que l’autorité de certification racine correspond.

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

Pour plus d’informations sur la commande openssl, consultez la documentation OpenSSL.

Vous pouvez également inspecter les certificats là où ils sont stockés par défaut, dans /var/lib/aziot/certd/certs. Vous trouverez des certificats d’autorité de certification Edge, des certificats d’identité d’appareil et des certificats de module dans le répertoire. Vous pouvez utiliser des commandes openssl x509 pour inspecter les certificats. Par exemple :

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

En résumé, TempSensor peut approuver EdgeGateway pour les raisons suivantes :

• Le module edgeHub a montré un certificat de serveur de module IoT Edge valide pour edgegateway.local
• Le certificat est émis par l’autorité de certification Edge qui est émise par my_private_root_CA
• Cette autorité de certification racine privée est également stockée dans TempSensor en tant qu’autorité de certification racine précédemment approuvée
• Les algorithmes de chiffrement vérifient que la chaîne de propriété et d’émission peut être approuvée

Certificats pour d’autres modules

D’autres modules peuvent obtenir des certificats de serveur émis par l’autorité de certification Edge. Par exemple, un module Grafana qui a une interface web. Il peut également obtenir un certificat auprès de l’autorité de certification Edge. Les modules sont traités comme des appareils en aval hébergés dans le conteneur. Cependant, la possibilité d’obtenir un certificat à partir du runtime de module IoT Edge est un privilège spécial. Les modules appellent l’API de charge de travail pour recevoir le certificat de serveur chaîné à l’autorité de certification Edge configurée.

La passerelle vérifie l’identité de l’appareil

Comment EdgeGateway vérifie-t-il qu’il communique avec TempSensor ? EdgeGateway utilise l’authentification du client TLS pour authentifier TempSensor.

La séquence est similaire à ContosoIotHub vérifiant un appareil. Toutefois, dans un scénario de passerelle, EdgeGateway s’appuie sur ContosoIotHub comme source de vérité pour l’enregistrement de certificat. EdgeGateway conserve également une copie ou un cache hors connexion s’il n’existe aucune connexion au cloud.

Conseil

Contrairement aux appareils IoT Edge, les appareils IoT en aval ne sont pas limités à l’authentification X.509 d’empreinte numérique. L’authentification de l’autorité de certification X.509 est également une option. Au lieu de simplement rechercher une correspondance sur l’empreinte, EdgeGateway peut également vérifier si le certificat de TempSensor a sa racine dans une autorité de certification chargée sur ContosoIotHub.

En résumé, EdgeGateway peut approuver TempSensor pour les raisons suivantes :

• TempSensor présente un certificat d’identité d’appareil IoT valide pour son nom
• L’empreinte du certificat d’identité correspond à celle chargée sur ContosoIotHub
• Les algorithmes de chiffrement vérifient que la chaîne de propriété et d’émission peut être approuvée

Où obtenir les certificats et la gestion

Dans la plupart des cas, vous fournissez vos propres certificats ou utilisez des certificats générés automatiquement. Par exemple, l’autorité de certification Edge et le certificat edgeHub sont générés automatiquement.

Toutefois, la meilleure pratique consiste à configurer vos appareils pour utiliser un serveur d’inscription sur un serveur de transport sécurisé (EST) pour gérer les certificats x509. Un serveur EST vous permet d’éviter de gérer et d’installer manuellement des certificats sur des appareils. Pour plus d’informations sur l’utilisation d’un serveur EST, consultez Configurer un serveur EST pour Azure IoT Edge.

Vous pouvez également utiliser des certificats pour vous authentifier auprès du serveur EST. Ces certificats s’authentifient auprès des serveurs EST pour émettre d’autres certificats. Le service de certificat utilise un certificat de d’amorçage pour s’authentifier auprès d’un serveur EST. Le certificat d’amorçage a une durée de vie longue. Lorsqu’il s’authentifie pour la première fois, le service de certificats demande un certificat d’identité auprès du serveur EST. Le certificat d’identité est utilisé dans les futures requêtes EST sur le même serveur.

Si vous ne pouvez pas utiliser un serveur EST, demandez des certificats à votre fournisseur PKI. Gérez manuellement les fichiers de certificat dans IoT Hub et vos appareils IoT Edge. Pour plus d’informations, consultez Gérer les certificats sur un appareil IoT Edge.

Pour le développement de preuve de concept, créez des certificats de test. Pour plus d’informations, consultez Créer des certificats de démonstration pour tester les fonctionnalités des appareils IoT Edge.

Certificats dans IoT

Autorité de certification

Une autorité de certification émet des certificats numériques. L’autorité de certification agit en tant que tiers approuvé entre le propriétaire du certificat et le destinataire du certificat. Un certificat numérique prouve que le récepteur possède une clé publique. La chaîne de certificats d’approbation commence par un certificat racine, qui est la base de l’approbation dans tous les certificats que l’autorité émet. Le propriétaire du certificat racine peut émettre des certificats intermédiaires supplémentaires (certificats d’appareil en aval).

Certificat d’autorité de certification racine

Un certificat d’autorité de certification racine est la racine de confiance pour le processus. En production, vous achetez généralement ce certificat CA auprès d’une autorité de certification commerciale approuvée comme Baltimore, Verisign ou DigiCert. Si vous contrôlez tous les appareils qui se connectent à vos appareils IoT Edge, vous pouvez utiliser une autorité de certification d’entreprise. Dans les deux cas, la chaîne de certificats d’IoT Edge à IoT Hub utilise le certificat d’autorité de certification racine. Les appareils IoT en aval doivent approuver le certificat racine. Vous pouvez stocker le certificat d’autorité de certification racine dans le magasin d’autorités de certification racines de confiance ou fournir les détails du certificat dans le code de votre application.

Certificats intermédiaires

Dans un processus de fabrication classique pour des appareils sécurisés, les fabricants utilisent rarement des certificats d’autorité de certification racine directement, en raison du risque de fuite ou d’exposition. Le certificat d’autorité de certification racine crée et signe numériquement un ou plusieurs certificats d’autorité de certification intermédiaires. Il peut y avoir une ou une chaîne de certificats intermédiaires. Les scénarios nécessitant une chaîne de certificats intermédiaires sont les suivants :

• Une hiérarchie de départements au sein d’un fabricant
• Plusieurs entreprises impliquées successivement dans la production d’un appareil
• Un client achetant une autorité de certification racine et en dérivant un certificat de signature permettant au fabricant de signer les appareils pour le compte de ce client

Le fabricant utilise un certificat d’autorité de certification intermédiaire à la fin de cette chaîne pour signer le certificat d’autorité de certification Edge placé sur l’appareil final. L’usine de fabrication protège étroitement ces certificats intermédiaires. Les processus physiques et électroniques stricts contrôlent leur utilisation.

Étapes suivantes

• Pour savoir comment installer des certificats sur un appareil IoT Edge et y faire référence dans le fichier config, consultez Gérer un certificat sur un appareil IoT Edge.
• Présentation des modules Azure IoT Edge
• Configurer un appareil IoT Edge en tant que passerelle transparente
• Cet article explique comment les certificats sont utilisés pour sécuriser les connexions entre les différents composants d’un appareil IoT Edge ou entre un appareil IoT Edge et tous les appareils en aval. Vous pouvez également utiliser des certificats pour authentifier votre appareil IoT Edge pour IoT Hub. Ces certificats d’authentification sont différents et ne sont pas abordés dans cet article. Pour plus d’informations sur l’authentification de votre appareil avec des certificats, consultez Créer et provisionner un appareil IoT Edge à l’aide de certificats X.509.