Tutoriel : Créer et charger des certificats à des fins de test

Vous pouvez utiliser des certificats X.509 pour authentifier des appareils auprès de votre hub IoT. Pour les environnements de production, nous vous recommandons d’acheter un certificat d’autorité de certification X.509 auprès d’un fournisseur de services de certificats professionnels. Vous pouvez ensuite émettre des certificats au sein de votre organisation à partir d’une autorité de certification auto-gérée interne chaînée au certificat d’autorité de certification acheté dans le cadre d’une stratégie complète d’infrastructure à clé publique (PKI). Pour plus d’informations sur l’obtention d’un certificat X.509 auprès d’un fournisseur de services de certificats professionnels, consultez la section Obtenir un certificat d’autorité de certification X.509 de l’article Authentifier des appareils à l’aide de certificats d’autorité de certification X.509.

Toutefois, la création de votre propre autorité de certification privée auto-gérée qui utilise une autorité de certification racine interne comme ancre d’approbation convient pour les environnements de test. Une autorité de certification privée auto-gérée avec au moins une autorité de certification subordonnée chaînée à votre autorité de certification racine interne et avec des certificats clients pour vos appareils signés par vos autorités de certification subordonnées vous permet de simuler un environnement de production recommandé.

Le tutoriel suivant utilise OpenSSL et le guide OpenSSL Cookbook pour décrire comment effectuer les tâches suivantes :

Prérequis

• Un abonnement Azure. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.

• Un hub IoT dans votre abonnement Azure. Si vous n’avez pas encore de hub, vous pouvez suivre les étapes décrites dans Créer un hub IoT.

• La dernière version de Git. Vérifiez que Git est ajouté aux variables d’environnement accessibles à la fenêtre de commande. Consultez Outils clients Git de Software Freedom Conservancy pour accéder à la dernière version des outils git à installer, ce qui inclut Git Bash, l’application en ligne de commande que vous pouvez utiliser pour interagir avec votre dépôt Git local.

• Une installation d’OpenSSL. Sur Windows, votre installation de Git inclut une installation d’OpenSSL. Vous pouvez accéder à OpenSSL à partir de l’invite Git Bash. Pour vérifier qu’OpenSSL est installé, ouvrez une invite Git Bash et entrez openssl version.

  Notes

  À moins que vous ne connaissiez OpenSSL et que vous l’ayez déjà installé sur votre ordinateur Windows, nous vous recommandons d’utiliser OpenSSL à partir de l’invite Git Bash. Vous pouvez également choisir de télécharger le code source et de générer OpenSSL. Pour en savoir plus, consultez la page Téléchargements OpenSSL. Vous pouvez également télécharger OpenSSL prédéfini auprès d’un tiers. Pour en savoir plus, consultez le wiki OpenSSL. Microsoft ne garantit pas la validité des packages téléchargés auprès de tiers. Si vous choisissez de générer ou de télécharger OpenSSL, vérifiez que le binaire OpenSSL est accessible dans votre chemin d’accès et que la variable d’environnement OPENSSL_CNF est définie sur le chemin d’accès de votre fichier openssl.cnf.

Créer une AC racine

Vous devez d’abord créer une autorité de certification racine interne et un certificat d’autorité de certification racine auto-signé pour servir d’ancre d’approbation à partir de laquelle vous pouvez créer d’autres certificats à des fins de test. Les fichiers servant à créer et gérer votre autorité de certification racine interne sont stockés dans une structure de dossiers et initialisés dans le cadre de ce processus. Effectuez les étapes suivantes pour :

1. Démarrez une fenêtre Git Bash et exécutez la commande ci-dessous, en remplaçant {base_dir} par le répertoire dans lequel vous voulez créer les certificats dans ce tutoriel.

   cd {base_dir}
   

2. Dans la fenêtre Git Bash, exécutez les commandes suivantes, une par une. Cette étape crée la structure de répertoires et les fichiers de support suivants pour l’autorité de certification racine.

   Répertoire ou fichier	Description
   rootca	Répertoire racine de l’autorité de certification racine.
   rootca/certs	Répertoire dans lequel les certificats d’autorité de certification pour l’autorité de certification racine sont créés et stockés.
   rootca/db	Répertoire dans lequel la base de données de certificats et les fichiers de support de l’autorité de certification racine sont stockés.
   rootca/db/index	Base de données de certificats pour l’autorité de certification racine. La commande touch crée un fichier sans contenu, pour une utilisation ultérieure. La base de données de certificats est un fichier texte brut géré par OpenSSL qui contient des informations sur les certificats émis. Pour plus d’informations sur la base de données de certificats, consultez la page de manuel openssl-ca.
   rootca/db/serial	Fichier utilisé pour stocker le numéro de série du certificat suivant à créer pour l’autorité de certification racine. La commande openssl crée un nombre aléatoire de 16 octets au format hexadécimal, puis le stocke dans ce fichier pour initialiser le fichier en vue de créer le certificat d’autorité de certification racine.
   rootca/db/crlnumber	Fichier servant à stocker les numéros de série des certificats révoqués émis par l’autorité de certification racine. La commande echo envoie un exemple de numéro de série, 1001, dans le fichier.
   rootca/private	Répertoire dans lequel sont stockés les fichiers privés de l’autorité de certification racine, y compris la clé privée. Les fichiers de ce répertoire doivent être sécurisés et protégés.

   mkdir rootca
   cd rootca
   mkdir certs db private
   chmod 700 private
   touch db/index
   openssl rand -hex 16 > db/serial
   echo 1001 > db/crlnumber
   

3. Créez un fichier texte nommé rootca.conf dans le répertoire rootca créé à l’étape précédente. Ouvrez ce fichier dans un éditeur de texte, puis copiez et enregistrez les paramètres de configuration OpenSSL suivants dans ce fichier.

   Le fichier fournit à OpenSSL les valeurs nécessaires pour configurer votre autorité de certification racine de test. Pour cet exemple, le fichier configure une autorité de certification racine appelée rootca à l’aide des répertoires et fichiers créés aux étapes précédentes. Le fichier fournit également les paramètres de configuration pour :

   • La stratégie d’autorité de certification utilisée par l’autorité de certification racine pour les champs de nom unique (DN) des certificats
   • Les demandes de certificat créées par l’autorité de certification racine
   • Les extensions X.509 appliquées aux certificats d’autorité de certification racine, aux certificats d’autorité de certification subordonnée et aux certificats clients émis par l’autorité de certification racine

   Notes

   Dans home la section, l’attribut ca_default est défini sur ../rootca, car ce fichier de configuration est également utilisé lors de la création du certificat pour votre autorité de certification subordonnée. Le chemin d’accès relatif spécifié permet à OpenSSL de naviguer de votre dossier d’autorité de certification subordonné vers votre dossier d’autorité de certification racine pendant ce processus.

   Pour plus d’informations sur la syntaxe des fichiers de configuration OpenSSL, consultez la page de manuel config dans la documentation 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
   

4. Dans la fenêtre Git Bash, exécutez la commande suivante pour générer une requête de signature de certificat (CSR) dans le répertoire rootca et une clé privée dans le répertoire rootca/private. Pour plus d’informations sur la commande OpenSSL req, consultez la page de manuel openssl-req dans la documentation OpenSSL.

   Notes

   Même si cette autorité de certification racine est utilisée à des fins de test et ne sera pas exposée dans le cadre d’une infrastructure à clé publique (PKI), nous vous recommandons de ne pas copier ou partager la clé privée.

   • Windows
   • Linux

   winpty openssl req -new -config rootca.conf -out rootca.csr -keyout private/rootca.key
   

   Vous êtes invité à entrer une phrase secrète PEM, comme illustré dans l’exemple suivant, pour le fichier de clé privée. Entrez et confirmez une phrase secrète pour générer votre clé privée et votre demande de signature de certificat.

   Enter PEM pass phrase:
   Verifying - Enter PEM pass phrase:
   -----
   

   Avant de continuer, vérifiez que le fichier CSR, rootca.csr, est présent dans le répertoire rootca et que le fichier de clé privée, rootca.key, est présent dans le sous-répertoire private.

5. Dans la fenêtre Git Bash, exécutez la commande suivante pour créer un certificat d’autorité de certification racine auto-signé. La commande applique les extensions de fichier de configuration ca_ext au certificat. Ces extensions indiquent que le certificat est destiné à une AC racine et peut être utilisé pour signer des certificats et des listes de révocation de certificats. Pour plus d’informations sur la commande OpenSSL ca, consultez la page de manuel openssl-ca dans la documentation OpenSSL.

   • Windows
   • Linux

   winpty openssl ca -selfsign -config rootca.conf -in rootca.csr -out rootca.crt -extensions ca_ext
   

   Vous êtes invité à fournir la phrase secrète PEM, comme illustré dans l’exemple suivant, pour le fichier de clé privée. Une fois la phrase secrète fournie, OpenSSL génère un certificat, puis vous invite à signer et à valider le certificat pour votre autorité de certification racine. Spécifiez y pour les deux invites afin de générer le certificat auto-signé pour votre autorité de certification racine.

   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
   

   Après qu’OpenSSL a mis à jour la base de données de certificats, vérifiez que le fichier de certificat, rootca.crt, est présent dans le répertoire rootca et que le fichier de certificat PEM (.pem) du certificat est présent dans le répertoire rootca/certs. Le nom du fichier .pem correspond au numéro de série du certificat d’autorité de certification racine.

Créer une autorité de certification subordonnée

Une fois que vous avez créé votre autorité de certification racine interne, vous devez créer une autorité de certification subordonnée à utiliser comme autorité de certification intermédiaire avec laquelle signer des certificats clients pour vos appareils. En théorie, vous n’avez pas besoin de créer une autorité de certification subordonnée. Vous pouvez charger votre certificat d’autorité de certification racine vers votre hub IoT et signer les certificats clients directement à partir de votre autorité de certification racine. Toutefois, l’utilisation d’une autorité de certification subordonnée comme autorité de certification intermédiaire pour signer les certificats clients simule avec plus de précision un environnement de production recommandé, dans lequel votre autorité de certification racine est mise hors connexion. Vous pouvez également utiliser une autorité de certification subordonnée pour signer une autre autorité de certification subordonnée, qui à son tour peut signer une autre autorité de certification subordonnée, et ainsi de suite. L’utilisation d’autorités de certification subordonnées pour signer d’autres autorités de certification subordonnées crée une hiérarchie d’autorités de certification intermédiaires dans le cadre d’une chaîne de certificats d’approbation. Dans un environnement de production, la chaîne de certificats d’approbation autorise une délégation d’approbation vers la signature d’appareils. Pour plus d’informations sur la signature d’appareils dans une chaîne de certificats d’approbation, consultez l’article Authentifier des appareils à l’aide de certificats d’autorité de certification X.509.

De manière similaire à votre autorité de certification racine, les fichiers servant à créer et à gérer votre autorité de certification subordonnée sont stockés dans une structure de dossiers et initialisés dans le cadre de ce processus. Effectuez les étapes suivantes pour :

1. Revenez au répertoire de base qui contient le répertoire rootca. Pour cet exemple, l’autorité de certification racine et l’autorité de certification subordonnée résident dans le même répertoire de base.

   cd ..
   

2. Dans la fenêtre Git Bash, exécutez les commandes suivantes, une par une.

   Cette étape crée une structure de répertoires et des fichiers de support pour l’autorité de certification subordonnée similaires à la structure de dossiers et aux fichiers créés pour l’autorité de certification racine dans la section précédente.

   mkdir subca
   cd subca
   mkdir certs db private
   chmod 700 private
   touch db/index
   openssl rand -hex 16 > db/serial
   echo 1001 > db/crlnumber
   

3. Créez un fichier texte nommé subca.conf dans le répertoire subca créé à l’étape précédente. Ouvrez ce fichier dans un éditeur de texte, puis copiez et enregistrez les paramètres de configuration OpenSSL suivants dans ce fichier.

   À l’instar du fichier de configuration de votre autorité de certification racine de test, ce fichier fournit à OpenSSL les valeurs nécessaires pour configurer votre autorité de certification subordonnée de test. Vous pouvez créer plusieurs autorités de certification subordonnées pour gérer des scénarios ou des environnements de test.

   Pour plus d’informations sur la syntaxe des fichiers de configuration OpenSSL, consultez la page de manuel principal config dans la documentation 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
   

4. Dans la fenêtre Git Bash, exécutez les commandes suivantes pour générer une clé privée et une demande de signature de certificat (CSR) dans le répertoire de l’autorité de certification subordonnée.

   • Windows
   • Linux

   winpty openssl req -new -config subca.conf -out subca.csr -keyout private/subca.key
   

   Vous êtes invité à entrer une phrase secrète PEM, comme illustré dans l’exemple suivant, pour le fichier de clé privée. Entrez et confirmez une phrase secrète pour générer votre clé privée et votre demande de signature de certificat.

   Enter PEM pass phrase:
   Verifying - Enter PEM pass phrase:
   -----
   

   Avant de continuer, vérifiez que le fichier CSR subca.csr est présent dans le répertoire de l’autorité de certification subordonnée et que le fichier de clé privée subca.key est présent dans le sous-répertoire private.

5. Dans la fenêtre Git Bash, exécutez la commande suivante pour créer un certificat d’autorité de certification subordonnée dans le répertoire de l’autorité de certification subordonnée. La commande applique les extensions de fichier de configuration sub_ca_ext au certificat. Ces extensions indiquent que le certificat est destiné à une autorité de certification subordonnée et peut également servir à signer des certificats et des listes de révocation de certificats. Contrairement au certificat d’autorité de certification racine, ce certificat n’est pas auto-signé. En lieu et place, le certificat d’autorité de certification subordonnée est signé avec le certificat d’autorité de certification racine, ce qui établit une chaîne de certificats similaire à celle que vous utiliseriez pour une infrastructure à clé publique (PKI). Le certificat d’autorité de certification subordonnée est ensuite utilisé pour signer des certificats clients pour tester vos appareils.

   • Windows
   • Linux

   winpty openssl ca -config ../rootca/rootca.conf -in subca.csr -out subca.crt -extensions sub_ca_ext
   

   Vous êtes invité à entrer la phrase secrète, comme illustré dans l’exemple suivant, pour le fichier de clé privée de votre autorité de certification racine. Après que vous avez entré la phrase secrète, OpenSSL génère et affiche les détails du certificat, puis vous invite à signer et à valider le certificat pour votre autorité de certification subordonnée. Spécifiez y pour les deux invites afin de générer le certificat pour votre autorité de certification subordonnée.

   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
   

   Après qu’OpenSSL a mis à jour la base de données de certificats, vérifiez que le fichier de certificat subca.crt est présent dans le répertoire de l’autorité de certification subordonnée et que le fichier de certificat PEM (.pem) du certificat est présent dans le répertoire rootca/certs. Le nom du fichier .pem correspond au numéro de série du certificat d’autorité de certification subordonnée.

Inscrire votre certificat d’autorité de certification subordonnée dans votre hub IoT

Inscrivez le certificat d’autorité de certification subordonnée dans votre hub IoT, qui l’utilise pour authentifier vos appareils lors de l’inscription et de la connexion. Les étapes suivantes décrivent comment charger et vérifier automatiquement votre certificat d’autorité de certification subordonnée sur votre hub IoT.

1. Dans le Portail Azure, accédez à votre hub IoT et sélectionnez Certificats dans le menu de ressources, sous Paramètres de sécurité.

2. Sélectionnez Ajouter dans la barre de commandes pour ajouter un nouveau certificat d’autorité de certification.

3. Entrez un nom d’affichage pour votre certificat d’autorité de certification subordonnée dans le champ Nom du certificat.

4. Sélectionnez le fichier de certificat PEM (.pem) de votre certificat d’autorité de certification subordonnée dans le répertoire rootca/certs pour l’ajouter dans le champ Fichier .pem ou .cer de certificat.

5. Cochez la case en regard de Définir l’état du certificat sur vérifié lors du chargement.

   

6. Sélectionnez Enregistrer.

Le certificat d’autorité de certification subordonnée chargé s’affiche avec l’état Vérifié dans l’onglet Certificats du volet de travail.

Créer un certificat client pour un appareil

Après avoir créé votre autorité de certification subordonnée, vous pouvez créer des certificats clients pour vos appareils. Les fichiers et dossiers créés pour votre autorité de certification subordonnée sont utilisés pour stocker les fichiers CSR, de clé privée et de certificat pour vos certificats clients.

La valeur du champ de nom commun de l’objet du certificat client doit être définie sur la valeur de l’ID d’appareil utilisé lors de l’inscription de l’appareil correspondant dans Azure IoT Hub.

Effectuez les étapes suivantes pour :

1. Dans votre fenêtre Git Bash, vérifiez que vous êtes toujours dans le répertoire subca.

2. Dans la fenêtre Git Bash, exécutez les commandes suivantes, une par une. Remplacez l’espace réservé par un nom pour votre appareil IoT, par exemple testdevice. Cette étape crée la clé privée et la demande de signature de certificat pour votre certificat client.

   Cette étape crée une clé privée RSA 2048 bits pour votre certificat client, puis génère une demande de signature de certificat (CSR) à l’aide de cette clé privée.

   • 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
   

3. Lorsque vous y êtes invité, fournissez les détails du certificat, comme indiqué dans l’exemple suivant.

   La seule invite pour laquelle vous devez fournir une valeur spécifique est Nom commun, qui doit être le même nom d’appareil que celui fourni à l’étape précédente. Vous pouvez ignorer ou fournir des valeurs arbitraires pour le reste des invites.

   Après que vous avez fourni les détails du certificat, OpenSSL génère et affiche les détails du certificat, puis vous invite à signer et à valider le certificat pour votre autorité de certification subordonnée. Spécifiez y pour les deux invites afin de générer le certificat pour votre autorité de certification subordonnée.

   -----
   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 []:
   
   

   Avant de continuer, vérifiez que le fichier CSR est présent dans le répertoire de l’autorité de certification subordonnée et que le fichier de clé privée est présent dans le sous-répertoire private. Pour plus d’informations sur les formats des fichiers CSR et de clé privée, consultez l’article Certificats X.509.

4. Dans la fenêtre Git Bash, exécutez la commande suivante, en remplaçant les espaces réservés du nom de l’appareil par le même nom que celui que vous avez utilisé lors des étapes précédentes.

   Cette étape crée un certificat client dans le répertoire de l’autorité de certification subordonnée. La commande applique les extensions de fichier de configuration client_ext au certificat. Ces extensions indiquent que le certificat est destiné à un certificat client, qui ne peut pas être utilisé comme certificat d’autorité de certification. Le certificat client est signé avec le certificat d’autorité de certification subordonnée.

   • Windows
   • Linux

   winpty openssl ca -config subca.conf -in <DEVICE_NAME>.csr -out <DEVICE_NAME>.crt -extensions client_ext
   

   Vous êtes invité à entrer la phrase secrète, comme illustré dans l’exemple suivant, pour le fichier de clé privée de votre autorité de certification subordonnée. Après que vous avez entré la phrase secrète, OpenSSL génère et affiche les détails du certificat, puis vous invite à signer et à valider le certificat client pour votre appareil. Spécifiez y pour les deux invites afin de générer le certificat client.

   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
   

   Après qu’OpenSSL a mis à jour la base de données de certificats, vérifiez que le fichier de certificat du certificat client est présent dans le répertoire de l’autorité de certification subordonnée et que le fichier de certificat PEM (.pem) du certificat client est présent dans le sous-répertoire certs du répertoire de l’autorité de certification subordonnée. Le nom du fichier .pem correspond au numéro de série du certificat client.

Étapes suivantes

Vous pouvez inscrire votre appareil auprès de votre hub IoT pour tester le certificat client que vous avez créé pour cet appareil. Pour plus d’informations sur l’inscription d’un appareil, consultez Créer et gérer des identités d’appareil.

Si vous avez plusieurs appareils associés à tester, vous pouvez utiliser le service Azure IoT Hub Device Provisioning pour provisionner configurer plusieurs appareils dans un groupe d’inscriptions. Pour plus d’informations sur l’utilisation de groupes d’inscriptions dans le service Device Provisioning, consultez le tutoriel Provisionner plusieurs appareils X.509 à l’aide de groupes d’inscriptions.