Comprendre Azure IoT Edge utilise les certificats

S’applique à : IoT Edge 1.5 IoT Edge 1.4

Important

IoT Edge 1.5 LTS et IoT Edge 1.4 LTS sont des versions prises en charge. IoT Edge 1.4 LTS sera en fin de vie 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 vous guide à travers les différentes façons dont 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 quelques différences :

• Le certificat d’autorité de certification d’appareil dans la version 1.1 a été renommé certificat d’autorité de certification Edge.
• Le certificat d’autorité de certification de charge de travail dans la version 1.1 a été supprimé. Dans la version 1.2 ou ultérieure, le runtime du module IoT Edge génère tous les certificats de serveur directement à partir du certificat d’autorité de certification Edge, sans le certificat d’autorité de certification de charge de travail intermédiaire entre eux dans la chaîne de certificats.

Résumé

C’est dans ces scénarios de base qu’IoT Edge utilise des certificats. 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 devez avoir 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 devez avoir une compréhension de base de la façon dont IoT Edge est lié à 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 à comprendre les concepts des certificats IoT Edge, imaginez un scénario où un appareil IoT Edge nommé EdgeGateway se connecte à un hub Azure IoT Hub nommé ContosoIotHub. Dans cet exemple, toute l’authentification est effectuée avec 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 ? ». Le scénario peut être illustré comme suit :

Nous allons expliquer les réponses à chacune des questions, puis développer l’exemple dans les sections ultérieures de l’article.

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

Comment EdgeGateway vérifie-t-il qu’il communique avec le hub ContosoIotHub authentique ? Quand EdgeGateway veut communiquer 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é du hub IoT, IoT Edge et IoT Hub utilisent le protocole de négociation TLS pour vérifier l’identité du serveur d’IoT Hub. Une négociation TLS est illustrée dans le diagramme suivant. Pour que l’exemple reste simple, certains détails ont été omis. Pour plus d’informations sur le protocole de négociation TLS, consultez 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. Il est important de comprendre que l’algorithme garantit que le serveur possède la clé privée qui est appairée à sa clé publique. Il vérifie que la personne présentant le certificat ne l’a pas copié ou volé. Si nous utilisons une pièce d’identité avec photo comme exemple, votre visage correspond à la photo sur la pièce d’identité. Si une personne vole votre pièce d’identité, elle ne peut pas l’utiliser pour une identification, car votre visage est unique et difficile à reproduire. Pour les clés de chiffrement, la paire de clés est associée et unique. Au lieu de faire correspondre un visage à une pièce d’identité avec 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. Ce certificat racine est signé par DigiCert, et ils 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 :

Quand un appareil recherche le certificat racine Baltimore CyberTrust, il le trouve préinstallé dans le système d’exploitation. Du point de vue de EdgeGateway, comme la chaîne de certificats présentée par ContosoIotHub est signée par une autorité de certification racine approuvée par le système d’exploitation, le certificat est considéré comme fiable. Le certificat est appelé certificat de serveur IoT Hub. Pour plus d’informations sur le certificat de serveur IoT Hub, consultez 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 TLS mutuel (mTLS), il vérifie le certificat de EdgeGateway pendant l’établissement d’une liaison TLS authentifiée par le client. Par souci de simplicité, nous allons passer 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 qu’EdgeGateway a la clé privée associée au certificat présenté. Quand vous provisionnez un appareil IoT Edge dans IoT Hub, vous fournissez une empreinte. L’empreinte est ce que IoT Hub utilise pour vérifier le certificat.

Conseil

IoT Hub nécessite deux empreintes lors de l’inscription d’un appareil IoT Edge. Une bonne pratique consiste à préparer deux certificats d’identité d’appareil différents avec des dates d’expiration différentes. De cette façon, si un certificat expire, l’autre est toujours valide et vous laisse le temps d’effectuer la rotation du certificat expiré. Cependant, il est également possible d’utiliser un seul certificat pour l’inscription. Utilisez un seul certificat en définissant l’empreinte du certificat pour les empreintes primaires et secondaires lors de l’inscription de l’appareil.

Par exemple, nous pouvons utiliser la commande suivante pour obtenir l’empreinte 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 nous visualisons la valeur de l’empreinte SHA256 pour l’appareil EdgeGateway enregistré dans IoT Hub, nous pouvons voir qu’elle correspond à l’empreinte sur EdgeGateway :

En résumé, ContosoIotHub peut approuver EdgeGateway, car EdgeGateway présente un certificat d’identité d’appareil IoT Edge valide dont l’empreinte 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 concerne pas Azure IoT Hub DPS (Device Provisioning Service), qui prend en charge l’authentification d’autorité de certification X.509 avec IoT Edge quand il est provisionné avec un groupe d’inscriptions. En utilisant 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 provisionné. Pour plus d’informations, consultez Attestation de certificat DPS X.509.

Dans le portail Azure, DPS affiche l’empreinte SHA-1 du certificat plutôt que l’empreinte SHA256.

DPS inscrit ou met à jour l’empreinte SHA256 pour IoT Hub. Vous pouvez vérifier l’empreinte en utilisant la commande openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256. Une fois inscrit, IoT Edge utilise l’authentification par empreinte avec IoT Hub. Si l’appareil est reprovisionné et qu’un nouveau certificat est émis, DPS met à jour IoT Hub avec la nouvelle empreinte.

IoT Hub ne prend actuellement pas en charge l’authentification d’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 apparaître qu’IoT Edge utilise le certificat seulement pour communiquer avec IoT Hub. IoT Edge se compose de plusieurs modules. Par conséquent, 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 à la place des clés SAS dérivées de la clé privée qui sont générées 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 continue par exemple de s’exécuter et seules les opérations d’identité de module échouent.

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

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

Vous avez maintenant une bonne compréhension d’une interaction simple entre IoT Edge et IoT Hub. Cependant, IoT Edge peut également agir en tant que passerelle pour les appareils en aval ou pour d’autres appareils IoT Edge. Ces canaux de communication doivent également être chiffrés et approuvés. En raison de la complexité supplémentaire, nous devons étendre notre exemple de scénario pour y 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 auparavant, toute l’authentification est effectuée avec l’authentification par certificat X.509. Notre nouveau scénario soulève deux nouvelles questions : « L’appareil TempSensor est-il légitime ? » et « L’identité de EdgeGateway est-elle correcte ? ». Le scénario peut être illustré comme suit :

Conseil

TempSensor est un appareil IoT dans le 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 10.0.0.2 de EdgeGateway.

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. Cependant, dans un scénario de passerelle, EdgeGateway s’appuie sur ContosoIotHub comme source de vérité pour l’enregistrement des certificats. EdgeGateway conserve également une copie ou un cache hors connexion en cas d’absence de connexion au cloud.

Conseil

Contrairement aux appareils IoT Edge, les appareils IoT en aval ne sont pas limités à l’authentification X.509 par empreinte. 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 qui a été chargée sur ContosoIotHub.

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

• TempSensor a présenté 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 pouvez fournir vos propres certificats ou utiliser des certificats générés automatiquement. Par exemple, l’autorité de certification Edge et le certificat edgeHub sont générés automatiquement.

Cependant, la bonne pratique est de configurer vos appareils pour qu’ils utilisent un serveur EST (Enrollment over Secure Transport) pour gérer les certificats X.509. L’utilisation d’un serveur EST vous permet de ne pas gérer manuellement les certificats et de ne pas les installer sur les 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 sont utilisés pour s’authentifier auprès des serveurs EST afin d’é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. Après l’authentification initiale, le service de certificat demande au serveur EST d’émettre un certificat d’identité. Ce certificat d’identité est utilisé dans les demandes EST futures adressées au même serveur.

Si vous ne pouvez pas utiliser un serveur EST, vous devez demander des certificats à votre fournisseur d’infrastructure à clé publique. Vous pouvez gérer manuellement les fichiers de certificat dans IoT Hub et sur vos appareils IoT Edge. Pour plus d’informations, consultez Gérer des certificats sur un appareil IoT Edge.

Pour le développement de la preuve de concept, vous pouvez créer 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

L’autorité de certification est une entité qui émet des certificats numériques. Une autorité de certification agit comme un tiers de confiance entre le propriétaire et le destinataire du certificat. Un certificat numérique certifie que le destinataire du certificat détient une clé publique. La chaîne d’approbation de confiance fonctionne en émettant initialement un certificat racine, qui sert de base pour tous les certificats émis par l’autorité. 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 source de confiance de l’ensemble du processus. Dans les scénarios de production, ce certificat d’autorité de certification est acheté auprès d’une autorité de certification de confiance du marché, comme Baltimore, Verisign ou DigiCert. Si vous avez un contrôle complet sur les dispositifs qui se connectent à vos appareils IoT Edge, il est possible d’utiliser une autorité de certification au niveau de l’entreprise. Dans les deux cas, l’ensemble de la chaîne de certificats d’IoT Edge à IoT Hub l’utilise. 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é de certification racine de confiance, ou fournir les détails du certificat dans le code de votre application.

Certificats intermédiaires

Dans un processus de fabrication standard d’appareils sécurisés, les certificats d’autorité de certification racine sont rarement utilisés directement, essentiellement 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 n’y en avoir qu’un, ou il peut y avoir une chaîne de certificats intermédiaires. Les scénarios qui nécessitent 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 qu’il fabrique pour le compte de ce client

Dans tous les cas, 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. Ces certificats intermédiaires sont conservés en sécurité à l’usine de fabrication. Ils sont soumis à des processus rigoureux, physiques et électroniques, pour 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 traite des certificats utilisés pour sécuriser les connexions entre les différents composants d’un appareil IoT Edge, ou entre un appareil IoT Edge et des 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.