Qu'est-ce qu'un certificat X.509?

X.509 est un format standard pour certificats de clé publique, des documents numériques qui associent en toute sécurité des paires de clés cryptographiques à des identités telles que des sites Web, des individus ou des organisations.

Introduit pour la première fois en 1988 parallèlement aux normes X.500 pour les services d'annuaire électronique, X.509 a été adapté pour une utilisation Internet par l'infrastructure à clé publique de l'IETF (X.509) (PKIX) groupe de travail. RFC 5280 décrit le certificat X.509 v3, la liste de révocation de certificats X.509 v2 (CRL) et décrit un algorithme pour la validation du chemin du certificat X.509.

Les applications courantes des certificats X.509 incluent:

• SSL /TLS ainsi que HTTPS pour une navigation Web authentifiée et cryptée
• Courriel signé et chiffré via le S/MIME protocole
• Signature de code
• Signature de documents
• Authentification client
• Pièce d'identité électronique émise par le gouvernement

Paires de clés et signatures

Quelle que soit la ou les applications prévues, chaque certificat X.509 comprend un Clé publique, signature numériqueet des informations sur l'identité associée au certificat et sur sa délivrance autorité de certification (CA):

• La Clé publique fait partie d'un paire de clés qui comprend également un Clé privée. La clé privée est sécurisée et la clé publique est incluse dans le certificat. Cette paire de clés publique / privée:
  • Permet au propriétaire de la clé privée de signer numériquement des documents; ces signatures peuvent être vérifiées par toute personne disposant de la clé publique correspondante.
  • Permet à des tiers d'envoyer des messages chiffrés avec la clé publique que seul le propriétaire de la clé privée peut déchiffrer.
• A signature numérique est un hachage codé (résumé de longueur fixe) d'un document qui a été chiffré avec une clé privée. Lorsqu'un certificat X.509 est signé par un CA de confiance publique, tel que SSL.com, le certificat peut être utilisé par un tiers pour vérifier l'identité de l'entité qui le présente.
  
  Remarque: Toutes les applications de certificats X.509 ne nécessitent pas la confiance du public. Par exemple, une entreprise peut émettre ses propres certificats de confiance privée à usage interne. Pour plus d'informations, veuillez lire notre article sur Privé vs public PKI.
• Chaque certificat X.509 comprend des champs spécifiant le sujet, émission de l'AC, et d'autres informations requises telles que le certificat version ainsi que  période de validité. De plus, les certificats v3 contiennent un ensemble de extensions qui définissent des propriétés telles que des utilisations de clés acceptables et des identités supplémentaires auxquelles lier une paire de clés.

Champs et extensions de certificat

Pour examiner le contenu d'un certificat X.509 typique à l'état sauvage, nous examinerons le SSL /TLS certificat, comme indiqué dans Google Chrome. (Vous pouvez vérifier tout cela dans votre propre navigateur pour n'importe quel site Web HTTPS en cliquant sur le verrou sur le côté gauche de la barre d'adresse.)

• Le premier groupe de détails comprend des informations sur le Sujet, y compris le nom et l'adresse de l'entreprise ainsi que Nom commun (ou nom de domaine complet) du site Web que le certificat est destiné à protéger. (Remarque: le Numéro de série indiqué dans ce champ est un numéro d'identification d'entreprise du Nevada, et non le numéro de série du certificat lui-même.)
  
• En faisant défiler vers le bas, nous rencontrons des informations sur le Emetteur. Pas par hasard, dans ce cas, le Organisation est «SSL Corp» pour le sujet et l'émetteur, mais l'émetteur Nom commun est le nom du certificat CA émetteur plutôt qu'une URL.
  
• Sous l'émetteur, nous voyons le certificat Numéro de série (un entier positif identifiant uniquement le certificat), Version X.509 (3), le Algorithme de signature, et les dates précisant le certificat Période de validité.
  
• Ensuite, nous arrivons au Clé publique, Signatureet informations associées.
  
• En plus des champs ci-dessus, les certificats X.509 v3 incluent un groupe de Extensions qui offrent une flexibilité supplémentaire dans l'utilisation des certificats. Par exemple, le Sujet Nom alternatif l'extension permet au certificat d'être lié à plusieurs identités. (Pour cette raison, les certificats à domaines multiples sont parfois appelés Certificats SAN). Dans l'exemple ci-dessous, nous pouvons voir que le certificat couvre en fait onze sous-domaines SSL.com différents:
  
• La Empreintes ci-dessous, les informations du certificat dans Chrome ne font pas partie du certificat lui-même, mais sont des hachages calculés indépendamment qui peuvent être utilisés pour identifier de manière unique un certificat.
  

Chaînes de certificats

Pour des raisons administratives et de sécurité, les certificats X.509 sont généralement combinés en Chaînes pour validation. Comme le montre la capture d'écran de Google Chrome ci-dessous, le SSL /TLS le certificat pour www.ssl.com est signé par l'un des certificats intermédiaires de SSL.com, SSL.com EV SSL Intermediate CA RSA R3. À son tour, le certificat intermédiaire est signé par la racine EV RSA de SSL.com:

Pour les sites Web de confiance publique, le serveur Web fournira ses propres entité finale certificat, ainsi que tous les intermédiaires requis pour la validation. Le certificat de l'autorité de certification racine avec sa clé publique sera inclus dans le système d'exploitation et / ou dans l'application de navigateur de l'utilisateur final, ce qui entraînera un chaîne de confiance.

Révocation

Certificats X.509 qui doivent être invalidés avant leur Non valide après la date peut être révoqué. Comme mentionné ci-dessus,  RFC 5280 profils listes de révocation de certificats (CRL), listes horodatées de certificats révoqués pouvant être interrogés par les navigateurs et autres logiciels clients.

Sur le Web, les listes de révocation de certificats se sont révélées inefficaces dans la pratique et ont été remplacées par d'autres solutions de vérification de révocation, notamment le protocole OCSP (publié dans RFC 2560), OCSP Stapling (publié au RFC 6066, paragraphe 8, comme «Demande de statut de certificat»), et un assortiment de solutions spécifiques au fournisseur implémentées dans divers navigateurs Web. Pour plus d'informations sur l'histoire épineuse de la vérification de la révocation et sur la manière dont les bowsers actuels vérifient l'état de révocation des certificats, veuillez lire nos articles, Optimisation du chargement des pages: agrafage OCSPet Comment les navigateurs gèrent-ils le SSL révoqué /TLS Des certificats?

Foire aux Questions