X.509

La définition originelle est disponible dans la RFC 2459[3] (section 4) ou dans la dernière version (RFC 5280[4]), 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.

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.

Voici les extensions communes des 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

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.

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

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