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

Article
04/16/2024

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é.

Important

Nous déconseillons d’utiliser des certificats auto-signés pour les environnements de production. Ce tutoriel est fourni à des fins de démonstration uniquement.

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

Créer une autorité de certification racine interne et un certificat d’autorité de certification racine
Créer une autorité de certification subordonnée interne et un certificat d’autorité de certification subordonnée, signé par votre certificat d’autorité de certification racine interne
Charger votre certificat d’autorité de certification subordonnée vers votre hub IoT à des fins de test
Utiliser l’autorité de certification subordonnée pour créer des certificats clients pour les appareils IoT à tester avec votre hub IoT

Notes

Microsoft fournit des scripts PowerShell et Bash pour vous aider à créer vos propres certificats X.509 et à les authentifier auprès d'un hub IoT. Les scripts sont inclus dans le kit de développement logiciel (SDK) d’appareil Azure IoT Hub pour C. Les scripts sont fournis à des fins de démonstration uniquement. Les certificats créés par ces scripts ne doivent pas être utilisés pour la production. Les certificats contiennent des mots de passe codés en dur (« 1234 ») et expirent au bout de 30 jours. Vous devez appliquer vos propres meilleures pratiques en matière de création de certificats et de gestion de leur durée de vie dans un environnement de production. Pour plus d’informations, consultez Gestion des certificats AC de test pour échantillons et didacticiels dans le référentiel GitHub pour le Kit de développement logiciel (SDK) d’appareil Azure IoT Hub pour C.

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 :

Créer et initialiser les dossiers et fichiers utilisés par votre autorité de certification racine
Créer un fichier de configuration utilisé par OpenSSL pour configurer votre autorité de certification racine et les certificats créés avec votre autorité de certification racine
Demander et créer un certificat d’autorité de certification auto-signé qui fait office de certificat d’autorité de certification racine

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}
```

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

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

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
```
```
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.
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
```
```
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 :

Créer et initialiser les dossiers et fichiers utilisés par votre autorité de certification subordonnée
Créer un fichier de configuration utilisé par OpenSSL pour configurer votre autorité de certification subordonnée et les certificats créés avec votre autorité de certification subordonnée
Demander et créer un certificat d’autorité de certification signé par votre autorité de certification racine qui sert de certificat d’autorité de certification subordonnée

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 ..
```
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
```

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

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
```
```
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.
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
```
```
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.

Dans le Portail Azure, accédez à votre hub IoT et sélectionnez Certificats dans le menu de ressources, sous Paramètres de sécurité.
Sélectionnez Ajouter dans la barre de commandes pour ajouter un nouveau certificat d’autorité de certification.
Entrez un nom d’affichage pour votre certificat d’autorité de certification subordonnée dans le champ Nom du certificat.
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.
Cochez la case en regard de Définir l’état du certificat sur vérifié lors du chargement.
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 :

Créer une clé privée et une demande de signature de certificat (CSR) pour un certificat client
Créer un certificat client signé par votre certificat d’autorité de certification subordonnée

Dans votre fenêtre Git Bash, vérifiez que vous êtes toujours dans le répertoire subca.
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
```
```
openssl genpkey -out private/<DEVICE_NAME>.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048
openssl req -new -key private/<DEVICE_NAME>.key -out <DEVICE_NAME>.csr
```
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.
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
```
```
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 la section Inscrire un nouvel appareil dans le hub IoT de l’article Créer un hub IoT à l’aide du portail Azure.

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.

Pour plus d’informations sur les formats des fichiers de certificat, consultez l’article Certificats X.509.