Si vous comprenez bien ce qu’est un certificat X509, veuillez lever la main. Maintenant que nous constatons que personne ne lève la main, changeons cela.
Les certificats sont un sujet complexe et souvent mal compris. Ce tutoriel vise à changer cela en vous montrant des exemples de certificats X509, en démontrant des certificats PKI, et bien plus encore.
Dans cet article, vous obtiendrez un bon aperçu des certificats X509. À la fin, vous comprendrez comment ils fonctionnent à un niveau élevé. Vous ne deviendrez pas un expert en lisant un seul article, mais à la fin de cet article, vous serez au moins familiarisé avec la terminologie appropriée.
En relation : Gérer les certificats avec le gestionnaire de certificats Windows et PowerShell
Clés publiques et privées : Protéger les actifs
Toute explication sur les certificats X509 serait incomplète sans mentionner d’abord les clés. Vous avez peut-être entendu parler du concept de clés lorsque des termes comme privée et publique clés sont utilisés. Mais qu’est-ce qu’une clé et en quoi est-elle liée aux certificats?
Pour faciliter la connexion, expliquons le concept de clés en termes de serrure de porte classique.
Lorsque vous achetez une nouvelle serrure de porte, celle-ci est livrée avec une clé. Cette clé est unique à cette serrure, de sorte que personne d’autre ne pourra l’ouvrir.
Pensez à la serrure elle-même comme une clé publique. Lorsqu’elle est installée, vous-même, votre famille ou les passants peuvent voir la serrure sur votre porte. Tout le monde peut la voir et même essayer de la déverrouiller, mais ils n’y arriveront pas. Pour la déverrouiller, il faudrait insérer la clé unique de porte qui était fournie avec la serrure. La clé unique fournie avec la serrure est la clé privée.
La clé privée et la clé publique ensemble sont appelées une paires de clés.
Échange de clés
Lorsque la clé de porte est insérée dans la serrure, vous pouvez considérer cette action comme un échange de clés. La clé privée (clé de porte) doit être échangée avec la clé publique (serrure) pour déverrouiller la porte.
Dans le monde de la cryptographie, vous donnez librement une clé publique et gardez la clé privée pour vous. Après tout, vous ne vous souciez pas de qui voit la serrure, mais vous vous souciez certainement de qui peut la déverrouiller (échanger des clés).
Il existe plusieurs façons d’échanger des clés, appelées algorithmes d’échange de clés. Les algorithmes d’échange de clés se concentrent sur la dérivation et la transmission sécurisée d’un secret partagé unique.
Deux algorithmes d’échange de clés populaires que vous avez peut-être entendus sont Diffie-Hellman (DH) et Elliptic Curve Diffie-Hellman (ECDH).
Confiance en la clé
Si vous avez besoin que quelqu’un entre par la porte, vous lui donneriez la clé (ou une copie de la clé unique d’origine). Vous ne donnez votre clé qu’à ceux en qui vous avez confiance. La personne qui détient la clé privée (clé de porte) a été confiée pour déverrouiller la serrure de porte (clé publique).
Utilisation de la clé
L’utilisation de la clé définit le but du certificat X509, cela correspond aux algorithmes que le certificat utilisera. L’usage étendu de la clé (EKU) définit les objectifs prévus pour la clé publique au-delà de son utilisation.
Certs X509 : « Conteneurs » de clés publiques
Comment les clés privées et publiques sont-elles liées au concept d’un certificat X509 ? Pensez à un certificat comme une simple clé publique. Un certificat est l' »enveloppe » qui contient une clé publique ainsi que quelques autres informations sur la clé, comme à qui la clé publique a été délivrée, qui a signé la clé, etc. Les certificats sont stockés sous forme de fichiers.
Nous aborderons plus tard quelques bons exemples de certificats X509.
Avez-vous déjà vu un fichier avec une extension de certificat PEM ou CER ? Ce sont des certificats (clés publiques). Vous en apprendrez plus sur ces formats un peu plus tard.
La clé publique elle-même n’est pas nécessairement un certificat par définition. C’est la clé publique et les données attributaires associées combinées qui définissent un certificat.
A certificate provides a standardized and secure format to communicate with specific systems along with the attributes to help validate a key pair trust. How certificates are built are defined within the X.509 standards, as you will read about later.
Empreinte digitale : Identifiant unique d’un certificat
Chaque certificat X509 est destiné à fournir l’identification d’un seul sujet. Le certificat doit garantir que chaque clé publique est unique et identifiable.
A certificate thumbprint or fingerprint is a way to identify a certificate, that is shorter than the entire public key. Technically, a serial number is as well but you’ll learn about that when it comes to certification authorities (CAs). The thumbprint is a hash of a DER-encoded certificate in Windows.
Le concept d’identification d’un ensemble de données plus large par un identifiant unique plus petit est le sujet général de l’informatique appelé la création d’empreintes digitales. Le blog de Morgan Simonson plonge plus en profondeur dans la notion d’empreinte digitale.
Sujet : Définition des attributs importants d’un certificat X509
Chaque certificat X509 doit non seulement avoir un identifiant unique, mais aussi répondre aux questions ci-dessous. Le sujet du certificat devrait faire exactement cela.
- Qui devrait utiliser ce certificat ?
- Quelle organisation devrait être considérée comme digne de confiance ?
- Quel utilisateur doit présenter ce certificat ?
Le sujet est sans doute la partie la plus importante d’un certificat. Le sujet doit avoir des attributs, définis par X.500, qui représentent à qui ou à quoi le certificat est délivré. Il est représenté dans un format de nom distinctif (DN).
A certificate subject is a string value that has a corresponding attribute type. For example, the DN for State or Province is st. This attribute type contains the full name of the state or province the subject resides in (e.g. ST=California).
Ces types d’attributs et formats de valeur sont définis par les recommandations ITU-T X.520. Une référence supplémentaire est RFC 4519 pour des recommandations spécifiques sur les types d’attributs et les formats de valeur.
Étant donné que les normes des certificats X509 ne sont pas des règles, mais seulement des suggestions fortes, de nombreuses personnes utilisent leur propre jugement lors de la définition d’un sujet. Le sujet est censé identifier spécifiquement l’entité finale en laquelle vous avez confiance. Si le sujet ne représente pas cela, comment pouvez-vous faire confiance à quoi que ce soit qui utilise la clé publique présentée ?
En d’autres termes, si vous permettez à plusieurs personnes d’utiliser le même nom d’utilisateur pour accéder à un système, vous ne pouvez pas tenir une personne spécifique responsable de ses actions. Cette pratique complique le modèle de confiance auquel les certificats sont censés se conformer.
Vous pouvez voir un exemple de la façon dont Windows représente un certificat X509 et plus précisément le sujet du certificat dans la capture d’écran ci-dessous.
Visualisation des attributs d’un certificat avec Cryptext.dll.
Subject Alternative Name (SAN)
A SAN is a certificate extension that allows you to use one certificate for multiple subjects that’s typically identified with a Subject Key Identifier (SKI). The example below shows some of the SANs Google uses. Adding more domains to a certificate essentially tells the certificate to trust each subject to use the same private key.
A SAN can also have several types other than DNS names called GeneralNames. GeneralNames require the client reading the certificate to support SANs using GeneralNames. Most clients such as web browsers only focus on the DNS name SAN.
Vous pouvez voir le SAN ci-dessous dans cet exemple de certificat X509.
Certains des attributs SAN associés au certificat de Google.
Comprendre le codage
Nous utilisons de nombreuses langues pour communiquer les uns avec les autres, de la même manière les ordinateurs ont leur propre langage. Ce langage est binaire et les différentes méthodes de codage sont la façon dont nous rendons le binaire plus utilisable pour les autres, tout comme nous traduirions l’anglais dans d’autres langues.
Le codage sert un objectif spécifique. Le codage permet de stocker les valeurs d’extension lisibles par l’homme d’une manière que les ordinateurs peuvent également utiliser. Les formats de codage facilitent le stockage et le transfert des certificats X509, mais nous permettent également de lire leur contenu.
Les ordinateurs sont bons pour travailler avec des entiers, le codage vous permet de convertir des valeurs numériques en valeurs alphanumériques ou même en blocs binaires. Cette conversion est essentielle pour travailler avec des ordinateurs, et les certificats se basent sur le codage pour transmettre correctement les informations appropriées aux ordinateurs. Les formats de codage définissent les normes pour effectuer ces conversions.
- ASN.1 – Le standard de notation de syntaxe abstraite est le format de sérialisation pour chacun des champs à l’intérieur des certificats.
- ASCII – Le American Standard Code for Information Interchange (ASCII) définit une valeur binaire pour chaque caractère de contrôle informatique et caractère imprimable utilisé pour la plupart des communications lisibles par l’homme.
- Base64 – Base64 définit un schéma pour encoder du contenu binaire dans l’ensemble de caractères ASCII. Il s’agit des certificats que vous pouvez ouvrir dans un éditeur de texte et voir « BEGIN CERTIFICATE » ou un autre texte de référence.
- DER – Distinguished Encoding Rules (DER) définit un autre schéma d’encodage spécifiquement pour les données ASN.1 sous forme d’octets séquentiels. La considération importante avec DER est que la sortie encodée n’est pas visible en ASCII.
Vous pouvez voir ci-dessous les différences entre les schémas d’encodage. Remarquez que le fichier certificate.crt affiché en premier a un ——-BEGIN CERTIFICATE——-, suivi d’une série de lettres et de chiffres aléatoires et se termine par ——-END CERTIFICATE——-. Tous les caractères sont lisibles par l’homme. Le premier certificat est encodé en Base64.
Maintenant, regardez le deuxième exemple du fichier certificate.cer. Le contenu de ce fichier est très différent du certificat Base64. Ce certificat X509 est encodé en DER.
Différence entre les fichiers encodés en Base64 et DER.
Compréhension des types de fichiers de certificat X509.
N’oubliez pas qu’un certificat n’est rien de plus qu’une clé publique avec des métadonnées représentées sous la forme d’un fichier. Vous trouverez de nombreux types de fichiers représentant différents types de certificats. Chaque type de fichier est différencié par son extension de fichier. Lorsque nous faisons référence à un fichier KEY, par exemple, nous faisons référence à son extension de fichier.
Vous trouverez ci-dessous tous les types courants de certificats définis par leur extension de fichier et leur objectif.
Dans la liste ci-dessous, vous remarquerez diverses références à PKCS. PKCS ou Public Key Cryptography Standards est un ensemble de normes qui définit comment divers certificats sont créés. Pour plus d’informations, consultez cet article informatif sur Wikipedia.
- PFX – On les trouve le plus souvent dans un environnement Windows, mais il s’agit d’un format standard indépendamment du système d’exploitation. Les fichiers PFX contiennent un certificat, la clé publique et les extensions, ainsi qu’une clé privée chiffrée avec un mot de passe. PFX est défini par la norme PKCS #12.
- P12 – Comme PFX, P12 est défini par la norme PKCS #12. Formellement, PKCS #12 est le successeur du format PFX, bien que les deux types de fichiers représentent le même format dans les implémentations cryptographiques modernes.
- P7B – Un conteneur de certificats ASN.1, spécifiquement des clés publiques pour toutes les hiérarchies d’une chaîne d’autorité de certification, comme vous le verrez ci-dessous. Un fichier PKCS #7 fournit un fichier unique pour distribuer plusieurs clés publiques, souvent utilisé pour établir manuellement une confiance avec les autorités de certification dans une PKI privée.
- P7C – Le type de fichier P7C est fonctionnellement identique à P7B, mais il s’agit simplement d’une autre extension couramment utilisée pour représenter un fichier PKCS #7.
- DER – Un fichier DER est une clé publique encodée en DER.
- CER – Une clé publique peut être encodée en DER ou en Base64. Un fichier CER est généralement encodé en DER.
- CRT – Un fichier CRT est généralement encodé en Base64, mais il n’y a aucune garantie.
- KEY – Un fichier KEY est souvent une clé privée encodée en Base64, qu’elle soit chiffrée ou non.
- PEM – Une référence à un certificat encodé en Base64, bien que plusieurs clés puissent se trouver dans un seul fichier PEM, on suppose souvent que le fichier PEM contient une clé privée. Le plus souvent utilisé pour un fichier de clé privée PEM encodé en Base64 – qu’il soit chiffré ou non.
- CSR – Utilisé pour soumettre une clé publique à une autorité de certification (CA) afin qu’elle soit signée et qu’elle reçoive des champs supplémentaires tels qu’un numéro de série. Il est défini par PKCS #10. Dans la plupart des cas, une CSR contient la structure ASN.1 de la demande encodée en Base64.
- REQ – Utilisé sous Windows pour spécifier les paramètres de politique d’inscription utilisés lors de la génération de la CSR.
- CRL – Un fichier CRL est une liste spécifique des certificats révoqués par une CA, leur état de révocation et la raison de leur révocation.
Infrastructure à clé publique (PKI) : L’écosystème des certificats X509
Rappelez-vous plus tôt quand quelqu’un possédait la clé d’une serrure de porte. Dans ce cas, vous aviez juste une seule porte. Mais que se passe-t-il lorsque vous vous retrouvez soudainement propriétaire de dizaines ou de centaines d’appartements ? Gérer toutes ces clés de porte va devenir compliqué !
De plus, les locataires ne restent pas éternellement dans leur appartement. Il y aura des personnes qui gardent la clé ou qui en font des copies non autorisées. Vous devrez changer les serrures pour empêcher l’accès. Vous ne faites plus confiance aux anciens locataires.
Si vous devez gérer des centaines d’appartements avec des locataires qui entrent et sortent constamment, comment gérez-vous tout cela ? La réponse est une Infrastructure à Clé Publique (ICP).
L’ICP est tout un écosystème de rôles, de politiques et de procédures construit autour de la gestion des clés publiques. L’ICP représente un ensemble global de nombreux domaines de concentration différents pour distribuer, utiliser, gérer et supprimer des certificats X509. C’est essentiellement tout ce qu’il faut pour manipuler et gérer correctement des certificats à grande échelle.
Dans les sections à venir, nous allons décortiquer bon nombre des composants les plus courants d’une ICP et expliquer le rôle de chaque composant.
Autorités de certification (AC) : Vos parents
A PKI is primarily built around the concept of managing trust. But since it’s not economical to directly manage hundreds or thousands of trust relationships, you need a mediator.
Vous avez besoin d’un tiers qui a déjà été cautionné par la partie originale. Ces médiateurs tiers sont appelés autorités de certification (AC) identifiées par une extension d’Identifiants de Clé d’Autorité (ICA) dérivée de la clé publique utilisée pour signer le certificat donné.
Pensez à vous en tant qu’enfant comme un certificat X509. Il est probable que vos parents vous aient appris à ne pas faire confiance aux étrangers. Mais que se passe-t-il si vos parents (ceux en qui vous avez confiance) vous présentent un étranger et vous disent qu’il est acceptable de lui faire confiance ? Vous auriez probablement tendance à le suivre et à lui faire confiance. Après tout, si vos parents lui font confiance, vous pouvez aussi.
A CA plays the role of your parents. You trust your parents (a CA) and they introduce you to strangers. They do so by signing the stranger’s public key to let you know that you can trust them.
Le rôle principal d’une autorité de certification est d’agir en tant que médiateur de confiance.
Émission de certificats X509 : établissement de la confiance
En étant une entité de confiance connue, une autorité de certification permet la confiance entre des parties indirectes. Pour permettre la confiance entre les parties, une autorité de certification « émet » des certificats. Lorsque nous parlons d’émission par une autorité de certification, cela signifie en réalité que l’autorité de certification valide les extensions demandées et ajoute des extensions générées par l’autorité de certification pour créer un certificat.
Lorsqu’une autorité de certification émet un certificat X509, elle utilise sa propre clé privée pour signer numériquement la clé publique du certificat. Grâce au processus de signature, une autorité de certification marque le certificat de manière à informer tout le monde qu’elle fait confiance à cette clé publique. DocuSign propose un bon aperçu de ce concept spécifique avec un bon schéma.
Un autre exemple d’extension générée par une autorité de certification est le numéro de série de chaque certificat, et chaque numéro de série doit être unique pour cette autorité de certification donnée selon les spécifications de conception du RFC.
Un exemple de confiance involontaire dans les actualités modernes est l’utilisation malveillante de PKI avec des logiciels malveillants. Les créateurs ont reçu des certificats valides qui sont implicitement approuvés par la plupart des systèmes, ce qui rend plus difficile pour vos systèmes d’identifier les binaires de logiciels malveillants comme étant malveillants.
Révocation des certificats X509 : suppression de la confiance
Le CA est également responsable de la révocation des certificats X509 qui ne doivent plus être approuvés. Ces révocations sont publiées par le CA dans une liste de révocation de certificats (CRL). La révocation est un moyen pour les CA d’invalidité activement un certificat, plutôt que d’attendre l’expiration de la durée de validité.
La confiance est un élément essentiel pour que les certificats fonctionnent de la manière prévue. Les points de distribution aident à assurer la confiance en fournissant un point de référence où le certificat et les listes de révocation peuvent être téléchargés par l’émetteur, et utilisés pour les comparer avec le certificat que vous utilisez.
A CRL Distribution Point (CDP) supplies the protocols and locations to obtain CRLs. Updating CRLs is a passive revocation validation method, with pulling updates at scheduled intervals. Online Certificate Status Protocol (OCSP) actively requests the revocation status of a specific certificate by maintaining caches of the CRLs.
Bien que la validation de la révocation par le biais de CRL ou d’OCSP soit disponible, elle doit être prise en charge et appliquée par le client, ce qui n’est pas toujours le cas.
Hiérarchisation
A PKI can be made up of multiple CAs or a single CA, these are commonly referred to as tiers.
Chaînage des certificats X509
Comme vous l’avez appris ci-dessus, la confiance est un point central majeur lors de l’utilisation des certificats. Les parties impliquées doivent être en mesure de faire confiance ou de valider un certificat qui a été délivré par une AC de confiance.
A great example of how this scales is the The United States Federal PKI public documents. These provide a great reference into maintaining an inter-organization trust relationship using CAs.
Signature des certificats X509
Vous entendrez souvent parler d’un concept appelé « signature de certificat », mais que signifie exactement cela ? Comme vous l’avez déjà appris, les certificats sont une question de confiance. Pour établir cette confiance, un certificat X509 est signé par une autorité de certification (CA). La signature d’un certificat attribue un condensé cryptographique unique à un certificat, indiquant à toutes les parties qui le lisent qu’elles peuvent lui faire confiance. Il a été signé par une CA de confiance.
Dans une hiérarchie PKI, les certificats sont signés par des CAs, mais leur utilisation dépend du type de CA qui les signe.
Lorsqu’il n’y a qu’une seule CA dans une PKI, cette CA est la racine. Étant donné qu’aucune autre CA n’existe, cette CA doit générer son propre certificat auto-signé. Cette CA émet ensuite des certificats signés par son propre certificat.
Si une PKI comporte plus d’une CA, toutes les CAs sont signées par une CA racine ou une CA intermédiaire qui remonte à la CA racine.
Typiquement, lorsqu’un appareil utilise la même clé privée correspondant à la clé publique lors de la génération d’un certificat X509, on parle de certificat auto-signé. Cependant, vous pouvez également demander à une CA d’utiliser sa propre clé privée pour signer votre certificat.
Algorithmes de signature
Les algorithmes de signature se concentrent sur la validation de l’authenticité d’un message provenant d’un pair distant. Une signature numérique est un condensé de message provenant d’une fonction de hachage, crypté avec la clé privée de l’expéditeur. Le destinataire déchiffre la signature numérique à l’aide d’une copie de la clé publique de l’expéditeur. Le destinataire peut ensuite comparer le condensé du message reçu avec celui déchiffré à partir de la signature numérique. Lorsque les condensés correspondent, l’authenticité du message est valide.
Le chiffrement asymétrique est la capacité de générer un texte chiffré sans utiliser de secret préalablement connu. La combinaison d’un algorithme d’échange de clés avec un algorithme de signature est la base du chiffrement asymétrique.
Voici les principaux algorithmes utilisés pour les signatures numériques.
- Rivest–Shamir–Adleman (RSA)
- Algorithme de signature numérique (DSA)
- DSA avec courbes elliptiques (ECDSA)
Requêtes de signature de certificat (CSR)
Les autorités de certification utilisent des requêtes de signature de certificat (CSR) qui permettent aux clients de soumettre des clés publiques aux autorités de certification pour l’émission. Une autorité de certification accepte une CSR et émettra des certificats X509 signés en fonction des politiques d’émission configurées. Cela signifie que chaque autorité de certification en laquelle vous avez confiance implique également une confiance pour les clés publiques qu’elle signe.
Hashage
Le hachage est un sujet complexe et je ne vais même pas essayer de l’expliquer en détail dans cet article. L’équipe de Computerphile propose une bonne présentation sur leur chaîne YouTube. Le hachage consiste à prendre un objet en entrée et à créer un hachage de sortie unique pour cette entrée unique. Le hachage de sortie est appelé une empreinte. Cela signifie que le moindre changement de l’objet en entrée créera une empreinte différente unique et non liée.
Les implémentations modernes se concentrent sur les algorithmes de hachage de l’Algorithme de hachage sécurisé (SHA) 2. À noter que SHA 256, SHA 384 et SHA 512 sont connus sous le nom de SHA 2.
Voici une liste des algorithmes de hachage courants que vous verrez.
- SHA 256
- SHA 384
- SHA 512
- Résumé de message (MD) 5
Politiques de certificat
L’extension de politique de certificat (CP) fournit la référence à l’organisation qui gère l’AC, documentant leurs politiques réelles pour la PKI donnée et devrait être alignée en tant que déclaration de pratique de certification (CPS) fournissant la politique de l’organisation pour maintenir la PKI donnée.
Points de distribution
Un autre type de point de distribution identifié dans les certificats est l’Accès aux informations d’autorité (AIA). Ces AIA fournissent les protocoles et les emplacements pour obtenir des copies des informations des émetteurs de certificats, le plus souvent cela signifie la clé publique de l’AC émettrice.
Résumé
Espérons maintenant, lorsque vous êtes interrogé comme au début de cet article, vous vous sentez plus à l’aise de lever la main, lentement. En toute honnêteté, espérons que cet article vous a aidé à comprendre les complexités des certificats X509 et de leur mise en œuvre dans Windows. Tout en vous aidant à comprendre certains des composants de base qui vous aideront à l’avenir dans votre travail avec les certificats.
Au moins maintenant, lorsque quelqu’un demande une clé publique de votre certificat, vous pouvez confirmer qu’il souhaite soit un encodage DER, soit un encodage Base64, et ils ne le sauront pas donc vous leur enverrez quand même les deux.