X.509

X.509 est une norme spécifiant les formats pour les certificats à clé publique, les listes de révocation de certificat, les attributs de certificat, et un algorithme de validation du chemin de certification, définie par l'Union internationale des télécommunications (UIT). X.509 établit entre autres un format standard de certificat électronique et un algorithme pour la validation de chemin de certification. X.509 fait également l'objet de nombreuses RFC de l'IETF.

X.509 a été créée en 1988 dans le cadre de la norme X.500. Elle repose sur un système hiérarchique d'autorités de certification, à l'inverse des réseaux de confiance (telle la toile de confiance OpenPGP), où n'importe qui peut signer les certificats d'autrui.

Certificats

Dans le système X.509, une autorité de certification attribue un certificat liant une clé publique à un nom distinctif (Distinguished Name) dont le format est défini par la recommandation X.500, ou encore à un nom alternatif (Alternative Name) tel qu'une adresse électronique ou un enregistrement DNS.

Ce certificat place la signature d'une autorité de certification dans le dernier champ. Concrètement cette signature est réalisée par un condensat de tous les champs précédents du certificat et un chiffrement de ce condensat par la clé privée de l'autorité de certification. N'importe qui possédant la clé publique de cette autorité de certification peut déchiffrer le condensat et le comparer au calcul de son propre condensat du certificat. Si les deux condensats sont identiques cela garantit que le certificat est intègre, il n'a pas été modifié. Le certificat de l'autorité de certification qui contient sa clé publique peut à son tour être signé par un autre certificat de plus haut niveau, formant ainsi une chaîne. Tout en haut de la chaîne on trouve les certificats les plus importants : les certificats racines.

Les certificats racines sont des clés publiques non signées, ou auto-signées, dans lesquelles repose la confiance. Les logiciels, comme les navigateurs web ou les clients de messagerie détiennent des certificats racines de nombreuses autorités de certification commerciales ou gouvernementales. Quand un navigateur ouvre une connexion sécurisée (TLS/SSL) vers un site possédant un certificat émis par une autorité connue, il considère le site comme sûr dans la mesure où le chemin de certification est validé. Le passage en mode sécurisé est alors transparent.

Si le logiciel (navigateur ou autre) ne connaît pas l'autorité de certification (certificat généré et auto-signé par un particulier ou autorité de certification pas encore connue ou volontairement retirée de liste des autorités acceptées), le navigateur propose d'examiner le certificat, puis de l'accepter ou de le refuser selon la confiance qu'on lui accorde.

X.509 peut être utilisé avec S/MIME, TLS/SSL, SET et IPsec.

Structure d'un certificat

La définition originelle est disponible dans la RFC 2459 (section 4) ou dans la dernière version (RFC 5280), qui contient une spécialisation de X.509 pour les applications Internet. La partie authentifiée contient les champs suivants :

• Version
• Numéro de série
• Algorithme de signature du certificat
• DN (Distinguished Name) du délivreur (autorité de certification)
• Validité (dates limites)
  • Pas avant
  • Pas après
• DN de l'objet du certificat
• Informations sur la clé publique
  • Algorithme de la clé publique
  • Clé publique proprement dite
• Identifiant unique du signataire (optionnel, X.509v2)
• Identifiant unique du détenteur du certificat (optionnel, X.509v2)
• Extensions (optionnel, à partir de X.509v3)
  • Liste des extensions
• Signature des informations ci-dessus par l'autorité de certification

Les noms de l'émetteur (également signataire) comme du titulaire sont des noms X.501, que l'on retrouve également dans les annuaires ISO et LDAP. Le contenu ci-dessus est suivi par une répétition de l'algorithme de signature et de la signature proprement dite.

Rien parmi les champs obligatoires ne permet de distinguer une autorité de certification (une organisation émettrice de certificats) d'un simple titulaire. L'extension basicConstraints définie dans X.509 version 3 comble cette limitation. Une autre imperfection du même type est que seul le nom permet de lier un certificat à celui de son émetteur alors que l'on ne peut pas garantir l'unicité des noms.

Extensions à la norme et usage spécifique d’un certificat

La RFC 5280 définit une somme d’extensions indiquant l’usage auquel est destiné le certificat. Voici les extensions les plus communes :

• Basic Constraints, sont utilisées pour indiquer si le certificat est celui d’une autorité de certification.
• KeyUsage, spécifie les usages cryptographiques possibles à l’aide de la clé publique du certificat; par exemple la clé publique peut être utilisée pour des signatures cryptographiques mais pas pour chiffrer des données.
• Extended Key Usage, est généralement utilisé pour les certificats en bout de chaîne (certificat feuille), et indique les fonctionnalités qu’offre la clé publique. Il contient une liste d’objets permettant chacun une fonctionnalité particulière de la clé. Par exemple l’objet { id-pkix 3 1 } indique que la clé peut être utilisée pour chiffrer une session SSL/TLS ; {id-pkix 3 4 } indique que la clé peut être utilisée pour chiffrer des emails.

De façon générale, si un certificat possède plusieurs extensions contraignant son usage, toutes les conditions doivent être remplies pour que l’usage soit approprié. La RFC 5280 donne l’exemple spécifique d’un certificat contenant à la fois keyUsage et extendedKeyUsage, dans ce cas les 2 contraintes doivent être satisfaites pour que le certificat puisse être utilisé conformément aux usages prévus.

Noms de fichiers pour les certificats

Voici les extensions de fichiers communes pour les certificats au format X.509 :

• .pem– (Privacy-enhancedElectronic Mail) certificat DER encodé en Base64, encadré par les mentions "-----BEGIN CERTIFICATE-----" et "-----END CERTIFICATE-----"
• .cer, .crt, .der– certificat DER au format binaire
• .p7b,.p7c– PKCS#7, contient plusieurs certificats ou CRL(s)
• .p12– PKCS#12, contient un bloc clé privée et certificat (protégé par mot de passe)
• .pfx– PFX, prédécesseur de PKCS#12, contient également un bloc clé privée et certificat

Certification en chaîne

Une chaîne de certificats est une liste de certificats (commençant par une entité à certifier comme un serveur) comprenant une ou plusieurs autorités de certifications (la dernière étant signée par elle-même), ayant les propriétés suivantes :

1. Le signataire de chaque certificat (sauf le dernier) est l’autorité qui lui succède dans la chaîne
2. Chaque certificat (excepté le dernier) a été signé par la clé privée de l’autorité suivante dans la chaîne (la signature d’un certificat peut être vérifiée à l’aide de la clé publique de l’autorité)
3. Le dernier certificat de la liste est le point d’entrée de la chaîne de confiance, considéré comme délivré de manière légitime

Les chaînes de certificat sont utilisées pour s’assurer que la clé publique et les données du certificat (le 1^er de la chaîne) correspondent bien au possesseur de celui-ci. Pour s’en assurer, la signature numérique est vérifiée à l’aide de la clé publique de l’entité suivante dans la chaîne, elle-même vérifiée par la clé publique de l’entité suivante jusqu’à arriver à la dernière entité de la chaîne. Comme le dernier certificat est considéré comme étant de confiance, remonter jusqu’à celui-ci revient finalement à authentifier le 1^er certificat.

Liste de révocation

Un certificat peut devenir invalide pour de nombreuses raisons telles que l'expiration naturelle (dépassement de la date de validité), la perte ou la compromission de la clé privée associée au certificat, le changement d'au moins un champ inclus dans le nom du titulaire / détenteur du certificat et cas extrême la perte ou la compromission de la clé privée de l'autorité de certification ayant signé le certificat en question.

C'est pourquoi la norme définit le format d'une liste indiquant les certificats devenus invalides pour une autorité de certification donnée. Cette liste est signée par l'autorité de certification pour en empêcher toute modification par une personne non autorisée.

Elle comprend une date d'émission, une date de mise à jour (toutes deux optionnelles) et la liste proprement dite sous la forme de paires (numéro de série du certificat révoqué ; motif éventuel de révocation). Le motif ne peut être présent que dans les CRL au format version 2.

Une limitation parfois gênante des CRL est le délai de propagation des informations de révocation. Pour le réduire, le protocole OCSP de validation de certificat a été développé. Défini initialement dans la RFC 2560 puis de nouveau dans la RFC 6960, ce protocole donne à peu près les mêmes informations que les CRL, mais potentiellement plus à jour.

Sécurité

À la suite de la publication d'une attaque de recherche de collisions complètes contre MD5 en 2004, Arjen Lenstra, Wang Xiaoyun et Benne de Weger s'intéressèrent au X.509 utilisant MD5 pour l'authentification du certificat. Leur attaque a permis de forger deux certificats avec des signatures identiques.
L'utilisation de la fonction de hachage cryptographique SHA-1 ne résout que partiellement le problème car une attaque similaire est possible en théorie, même si la complexité de la recherche de collisions sur SHA-1 est bien plus grande que sur MD5.

Voir aussi

Articles connexes

• Infrastructure à clés publiques
• EJBCA (solution logicielle)
• IDnomic (éditeur de solutions logicielles)
• Certificat électronique
• Cryptographie asymétrique
• Authentification forte

Liens externes

Solutions :

• EJBCA - PKI Open Source
• CertEurope

Autorités de certification :

• Certinomis
• ChamberSign France
• CertEurope
• Keynectis (OpenTrust)
• CAcert : certificat personnel gratuit
• Thawte
• Certigna
• VeriSign
• Firmaprofesional
• ANCE
• Signexpert, Signature électronique des experts comptables
• Let’s Encrypt (autorité de certification : automatique, libre et gratuite)

Outils (gratuits) :

• X509 Builder