Certificats X.509

Article
04/30/2023

Les certificats X.509 sont des documents numériques qui représentent un utilisateur, un ordinateur, un service ou un appareil. Une autorité de certification, une autorité de certification subordonnée ou une autorité d’inscription émet des certificats X.509. Les certificats contiennent la clé publique de l’objet du certificat. Ils ne contiennent pas la clé privée du sujet, qui doit être stockée de manière sécurisée. RFC 5280 documente les certificats de clé publique, y compris leurs champs et extensions. Les certificats de clé publique sont signés numériquement et contiennent généralement les informations suivantes :

Informations sur le sujet du certificat
Clé publique correspondant à la clé privée du sujet
Informations sur l’autorité de certification émettrice
Algorithmes de chiffrement et/ou de signature numérique pris en charge
Informations pour déterminer l’état de révocation et de validité du certificat

Champs Certificat

Il existe trois versions incrémentielles de la norme de certificat X.509, et chaque version ultérieure a ajouté des champs de certificat à la norme :

La version 1 (v1), publiée en 1988, suit la norme X.509 initiale pour les certificats.
La version 2 (v2), publiée en 1993, ajoute deux champs aux champs inclus dans la version 1.
La version 3 (v3), publiée en 2008, représente la version actuelle de la norme X.509. Cette version ajoute la prise en charge des extensions de certificat.

Cette section est destinée à servir de référence générale pour les champs de certificat et les extensions de certificat disponibles dans les certificats X.509. Pour plus d’informations sur les champs de certificat et les extensions de certificat, notamment les types de données, les contraintes et d’autres détails, consultez la spécification RFC 5280.

Champs version 1

Le tableau suivant décrit les champs de certificat version 1 pour les certificats X.509. Tous les champs inclus dans ce tableau sont disponibles dans les versions de certificat X.509 suivantes.

Nom	Description
Version	Entier qui identifie le numéro de version du certificat.
Numéro de série	Entier qui représente le numéro unique de chaque certificat émis par une autorité de certification.
Signature	Identificateur de l’algorithme de chiffrement utilisé par l’autorité de certification pour signer le certificat. La valeur inclut à la fois l’identificateur de l’algorithme et tous les paramètres facultatifs utilisés par cet algorithme, le cas échéant.
Émetteur	Nom unique de l’autorité de certification émettrice du certificat.
Validité	Période de temps inclusif pendant laquelle le certificat est valide.
Subject	Nom unique (DN) de l’objet du certificat.
Informations sur la clé publique de l’objet	Clé publique appartenant à l’objet du certificat.

Champs version 2

Le tableau suivant décrit les champs ajoutés pour la version 2, contenant des informations sur l’émetteur de certificat. Toutefois, ces champs sont rarement utilisés. Tous les champs inclus dans ce tableau sont disponibles dans les versions de certificat X.509 suivantes.

Nom	Description
ID unique de l’émetteur	Identificateur unique qui représente l’autorité de certification émettrice, tel que défini par l’autorité de certification émettrice.
ID unique de l’objet	Identificateur unique qui représente le sujet du certificat tel que défini par l’autorité de certification émettrice

Champs version 3

Le tableau suivant décrit le champ ajouté pour la version 3, représentant une collection d’extensions de certificat X.509.

Nom	Description
Extensions	Collection d’extensions de certificat standard et spécifiques à Internet. Pour plus d’informations sur les extensions de certificat disponibles pour les certificats X.509 v3, consultez Extensions de certificat.

Extensions de certificat

Les extensions de certificat, introduites avec la version 3, fournissent des méthodes permettant d’associer davantage d’attributs à des utilisateurs ou à des clés publiques et de gérer les relations entre les autorités de certification. Pour plus d’informations sur les extensions de certificat, consultez la section Extensions de certificat de la spécification RFC 5280.

Extensions standard

La norme X.509 définit les extensions incluses dans cette section, pour une utilisation dans l’infrastructure à clé publique Internet.

Nom	Description
Identificateur de clé d’autorité	Identificateur qui représente le sujet du certificat et le numéro de série du certificat d’autorité de certification qui a émis ce certificat, ou un hachage de la clé publique de l’autorité de certification émettrice.
Identificateur de la clé du sujet	Hachage de la clé publique du certificat actuel.
Utilisation de la clé	Valeur bitmap qui définit les services pour lesquels un certificat peut être utilisé.
Durée de l’utilisation de la clé privée	Période de validité de la partie clé privée d’une paire de clés.
Stratégies du certificat	Collection d’informations de stratégie, utilisée pour valider le sujet du certificat.
Mappages de stratégie	Collection de mappages de stratégies, chacun d’entre eux mappant une stratégie d’une organisation à une stratégie d’une autre organisation.
Autre nom de l’objet	Collection de noms de remplacement pour l’objet.
Autre nom de l’émetteur	Collection de noms de remplacement pour l’autorité de certification émettrice.
Attributs d’annuaire du sujet	Collection d’attributs d’un répertoire X.500 ou LDAP.
Contraintes de base	Collection de contraintes qui permettent au certificat d’indiquer s’il est délivré à une autorité de certification ou à un utilisateur, un ordinateur, un appareil ou un service. Cette extension comprend également une contrainte de longueur de chemin qui limite le nombre d’autorités de certification secondaires qui peuvent exister.
Contraintes de nom	Collection de contraintes qui désignent les espaces de noms autorisés dans un certificat émis par l’autorité de certification.
Contraintes de stratégie	Collection de contraintes qui peuvent être utilisées pour interdire les mappages de stratégie entre autorités de certification.
Utilisation améliorée de la clé	Collection de valeurs d’objectifs clés qui indiquent comment la clé publique d’un certificat peut être utilisée au-delà des finalités identifiées dans l’extension Utilisation de clé.
Points de distribution de la liste de révocation de certificats	Collection d’URL dans laquelle la liste de révocation de certificats de base (CRL) est publiée.
Empêcher anyPolicy	Empêche l’utilisation de l’OID All Issuance Policies (Toutes les stratégies d’émission) (2.5.29.32.0) dans les certificats d’autorité de certification secondaires
Liste de révocation de certificats la plus récente	Cette extension, également appelée Point de distribution delta CRL, contient une ou plusieurs URL où la liste de révocation de certificats delta de l’autorité de certification émettrice est publiée.

Extensions Internet privées

Les extensions incluses dans cette section sont similaires aux extensions standard et peuvent être utilisées pour diriger les applications vers des informations en ligne sur l’autorité de certification ou le sujet du certificat émetteur.

Nom	Description
Accès aux informations de l’autorité	Collection d’entrées qui décrivent le format et l’emplacement des informations supplémentaires fournies par l’autorité de certification émettrice.
Accès aux informations du sujet	Collection d’entrées qui décrivent le format et l’emplacement des informations supplémentaires fournies par le sujet du certificat.

Formats de certificat

Les certificats peuvent être enregistrés dans divers formats. L’authentification Azure IoT Hub utilise généralement les formats Privacy-Enhanced Mail (PEM) et PFX (Personal Information Exchange). Le tableau suivant décrit les fichiers et formats couramment utilisés pour représenter les certificats.

Format	Description
Certificat binaire	Certificat binaire de forme brute utilisant un encodage ASN.1 DER (Distinguished Encoding Rules).
Format PEM ASCII	Un fichier de certificat PEM (.pem) contient un certificat encodé en Base64 commençant par `-----BEGIN CERTIFICATE-----` et se terminant par `-----END CERTIFICATE-----`. Le format PEM, l’un des plus courants pour les certificats X.509, est exigé par IoT Hub lors du chargement de certains certificats, tels que des certificats d’appareils.
Clé PEM ASCII	Contient une clé DER encodée en Base64 contenant éventuellement d’autres métadonnées sur l’algorithme utilisé pour la protection par mot de passe.
Certificat PKCS #7	Format conçu pour le transport des données signées ou chiffrées. Il peut inclure la totalité de la chaîne de certificats. RFC 2315 définit ce format.
Clé PKCS #8	Format d’un magasin de clés privées. RFC 5208 définit ce format.
Clé et certificat PKCS #12	Format complexe qui peut stocker et protéger une clé et la totalité de la chaîne de certificats. Il est couramment utilisé avec une extension .p12 ou .pfx. PKCS #12 est synonyme de format PFX. RFC 7292 définit ce format.

Certificats auto-signés

Vous pouvez authentifier un appareil auprès de votre hub IoT en utilisant deux certificats d’appareil auto-signés. Ce type d’authentification est parfois appelé authentification par empreinte numérique, car les certificats sont identifiés par des valeurs de hachage calculées appelées empreintes digitales ou empreintes. Ces valeurs de hachage calculées sont utilisées par IoT Hub pour authentifier vos appareils.

Important

Nous vous recommandons d’utiliser des certificats signés par une autorité de certification émettrice, même à des fins de test. N’utilisez jamais de certificat auto-signé en production.

Créer un certificat auto-signé

Vous pouvez utiliser OpenSSL pour créer des certificats auto-signés. Les étapes suivantes vous montrent comment exécuter des commandes OpenSSL dans un interpréteur de commandes bash pour créer un certificat auto-signé et récupérer une empreinte de certificat qui peut être utilisée pour l’authentification de votre appareil dans IoT Hub.

Notes

Si vous souhaitez utiliser des certificats auto-signés à des fins de test, vous devez créer deux certificats pour chaque appareil.

Exécutez la commande suivante pour générer une clé privée et créer un fichier de clé privée codée PEM (.key), en remplaçant les espaces réservés suivants par leurs valeurs correspondantes. La clé privée générée par la commande suivante utilise l’algorithme RSA avec un chiffrement 2 048 bits.

{KeyFile}. Nom de votre fichier de clé privée.
```
openssl genpkey -out {KeyFile} -algorithm RSA -pkeyopt rsa_keygen_bits:2048
```

Exécutez la commande suivante pour générer une demande de signature de certificat PKCS #10 et créer un fichier CSR (.csr), en remplaçant les espaces réservés suivants par leurs valeurs correspondantes. Veillez à spécifier l’ID de l’appareil IoT pour votre certificat auto-signé lorsque vous y êtes invité.

{KeyFile}. Nom de votre fichier de clé privée.

{CsrFile}. Nom de votre fichier CSR.

{DeviceID}. Nom de votre appareil IoT.

openssl req -new -key {KeyFile} -out {CsrFile}

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) []:{DeviceID}
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:.
An optional company name []:.

Exécutez la commande suivante pour examiner et vérifier votre CSR, en remplaçant les espaces réservés suivants par leurs valeurs correspondantes.

{CsrFile}. Nom de votre fichier de certificat.
```
openssl req -text -in {CsrFile} -verify -noout
```
Exécutez la commande suivante pour générer un certificat auto-signé et créer un fichier de certificat codé PEM (.crt), en remplaçant les espaces réservés suivants par leurs valeurs correspondantes. La commande convertit et signe votre CSR avec votre clé privée, générant un certificat auto-signé qui expire dans 365 jours.

{KeyFile}. Nom de votre fichier de clé privée.

{CsrFile}. Nom de votre fichier CSR.

{CrtFile}. Nom de votre fichier de certificat.
```
openssl x509 -req -days 365 -in {CsrFile} -signkey {KeyFile} -out {CrtFile}
```
Exécutez la commande suivante pour récupérer l’empreinte digitale du certificat, en remplaçant les espaces réservés suivants par leurs valeurs correspondantes. L’empreinte digitale d’un certificat est une valeur de hachage calculée qui est unique à ce certificat. Vous avez besoin de l’empreinte digitale pour configurer votre appareil IoT dans IoT Hub à des fins de test.

{CrtFile}. Nom de votre fichier de certificat.
```
openssl x509 -in {CrtFile} -noout -fingerprint
```

Vérifier manuellement le certificat après le chargement

Après avoir chargé votre certificat d’autorité de certification racine ou votre certificat d’autorité de certification subordonnée sur votre hub IoT, vous pouvez choisir de vérifier automatiquement le certificat. Si vous n’avez pas choisi de vérifier automatiquement votre certificat lors du chargement, son état est défini sur Non vérifié. Vous devez effectuer les étapes suivantes pour vérifier manuellement votre certificat.

Sélectionnez le certificat pour afficher la boîte de dialogue Détails du certificat.
Sélectionnez Générer un code de vérification dans la boîte de dialogue.
Copiez le code de vérification dans le Presse-papiers. Vous devez utiliser ce code de vérification comme sujet du certificat dans les étapes suivantes. Par exemple, si le code de vérification est 75B86466DA34D2B04C0C4C9557A119687ADAE7D4732BDDB3, ajoutez-le en tant qu’objet de votre certificat, comme indiqué à l’étape suivante.
Un certificat de vérification peut être généré de trois façons :
- Si vous utilisez le script PowerShell fourni par Microsoft, exécutez New-CACertsVerificationCert "<verification code>" pour créer un certificat nommé VerifyCert4.cer, en remplaçant <verification code> par le code de vérification généré précédemment. 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.
- Si vous utilisez le script Bash fourni par Microsoft, exécutez ./certGen.sh create_verification_certificate "<verification code>" pour créer un certificat nommé verification-code.cert.pem, en remplaçant <verification code> par le code de vérification généré précédemment. Pour plus d’informations, consultez Gestion des certificats d’autorité de certification 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.
- Si vous utilisez OpenSSL pour générer vos certificats, vous devez d’abord générer une clé privée, puis générer un fichier de demande de signature de certificat. Dans l’exemple suivant, remplacez <verification code> par le code de vérification généré précédemment :
```
openssl genpkey -out pop.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048

openssl req -new -key pop.key -out pop.csr

-----
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) []:<verification code>
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
```
Ensuite, créez un certificat en utilisant le fichier de configuration approprié pour l’autorité de certification racine ou l’autorité de certification subordonnée, et le fichier de demande de signature de certificat. L’exemple suivant montre comment utiliser OpenSSL pour créer le certificat à partir d’un fichier de configuration d’autorité de certification racine et du fichier de demande de signature de certificat.
```
openssl ca -config rootca.conf -in pop.csr -out pop.crt -extensions client_ext
```
Pour plus d’informations, consultez le Tutoriel : Créer et charger des certificats à des fins de test.
Sélectionnez le nouveau certificat dans l'affichage Détails du certificat.
Une fois le certificat chargé, sélectionnez Vérifier. L’état du certificat doit passer à Vérifié.

Informations supplémentaires

Pour plus d’informations sur les certificats X.509 et leur utilisation dans IoT Hub, consultez les articles suivants :

Partage via