Certificat

Besoin

Garantir qu'une signature (clé publique) correspond bien à une identité donnée.

Analyse

De la même manière que la signature sur votre carte d'identité est certifiée par la mairie qui vous l'a remise, et que le tampon de la mairie est certifié par l'état, etc. un certificat contient une clé publique certifiée par quelqu'un d'autre, lui-même certifié par un autre, etc. jusqu'à parvenir à la clé publique d'un auteur dont l'identité est incontestable : une CA.

Implémentation

Dans Java, la manipulation des certificats relève du package java.security.cert [1.2+]. Ce package définit la classe abstraite Certificate, dont doivent dériver les classes représentant des types particuliers de certificats (par exemple java.security.cert.X509Certificate). On pourra par alors demander à la fabrique de certificats (java.security.cert.CertificateFactory) d'un fournisseur donné d'instancier un certificat à partir :

• de flux (fichiers, certificats téléchargés) que lira la fabrique de certificats afin de générer (maFabrique.generateCertificate (telInputStream)) un objet de type java.security.cert.Certificate, que l'on pourra interpréter (cast) selon les cas comme des java.security.cert.X509Certificate ou autre.
• d'une base de clés, qui peut fournir une instance de certificat à partir de son alias.

Le package des certificats définit également une classe CRL permettant de représenter les listes de certificats révoqués.

X.509

En l'occurrence Java ne définit qu'un type particulier de certificat, le X.509, largement utilisé par la plupart des protocoles. Il est représenté par la classe java.security.cert.X509Certificate. Cette classe n'est cependant pas jamais instanciée, et dérivable par différents fournisseurs souhaitant fournir une implémentation de certificats X.509.

Afin de pouvoir valider d'autres certificats, la plate-forme Java [1.2+] (JDK ou JRE/plugin) inclut — comme les navigateurs — une liste de certificats identifiant au moins une CA, en l'occurence Verisign.

Cette base de certificats "racines" se trouve dans une base de clés (KeyStore) de nom cacerts, située dans le sous-répertoire lib/security/ de la plate-forme. Dans un premier temps, il est peu probable que vous ayez a accéder à cette base. Cependant, il est recommandé de changer son mot de passe par défaut (changeit) afin d'éviter que quelqu'un ne remplace à votre insu les certificats de confiance installés sur votre machine.

La génération d'un tel certificat s'effectue via l'option -genkey de keytool. Sont alors stockées dans la base de clés (%HOME%\.keystore par défaut) une nouvelle clé privée et une nouvelle clé publique associée, ainsi qu'un certificat (X.509 v1 uniquement pour l'instant) auto-signé certifiant la valeur de sa propre clé-publique. A chacune de ces identités générées est associé un alias qui peut être spécifié à keytool (mykey par défaut). Par exemple :

keytool -genkey -alias javarome

Cette génération nécessite diverses informations fournies par le certifié (nom, prénom, localité, compagnie, département, état, pays) nécessaire à la définition X.500 du nom du certifié (Distinguished Name).

Exemples

Des exemples de formats de certificats sont :

• X.509

Notes

• Lorsqu'un acteur désire être certifié (obtenir un certificat) par une Autorité de Certification, il lui transmet une CSR.
• ASN définit un format standard de certificat.
• On peut récupérer la version codée (à écrire dans un fichier, à télécharger...) d'un certificat sous forme d'un tableau d'octets. Cette méthode abstraite (getEncoded()) sera donc implémentée différemment par les différents types de certificats (un certificat X.509 retournera un ensemble d'octets au format ASN.1/DER par exemple).
• On peut vérifier si un certificat a bien été signé par une identité donnée si l'on dispose de la clé publique l'identité à vérifier (telCertificat.verify(telleClePublique) lèvera une exception si ce n'est pas le cas).
• Un certificat auto-signé (self-signed certificate) n'est garantit que par l'identité certifiée elle-même, et non par une CA supérieure. Les certificats auto-signés sont normalement l'apanage des CA, ou uniquement utilisé à des fins de tests.
• Les CRL (Certificate Revocation List) sont des listes de certificats révoqués (invalidés). Un certificat peut en effet être révoqué si son propriétaire a signalé s'être fait voler sa clé privée par exemple. Les CRL sont datées et signées par une CA et généralement accessible à tous. Chacun peut ainsi demander à une CRL si un certificat donné est toujours valide ou non.
• Un realm (domaine) est un moyen d'associer des informations émises par le client (certificat, login/mot de passe) à une identité connue du serveur. WLS ou d'autres serveurs applicatifs définissent généralement parmi leurs realms (UnixPasswordRealm, NTPasswordRealm, DatabaseRealm) un CertificateRealm.
• Verisign est une CA commerciale délivrant des certificats.