|
|
||
| Date de création : | mars 2003 | |
| Dernière modification : | 6 avril 2004 | |
| Diffusion : | internet | |
Un keystore est un fichier protégé par mot de passe, qui peut contenir différentes clés et certificats.
Par défaut, le JDK est livré avec un keystore qui contient le
certificats de différentes Autorités de Certification 'de confiance'
; ce keystore se trouve à : $JAVA_HOME/jre/lib/security/cacerts
Si on connait le mot de passe, on peut importer/exporter ou lister le contenu du keystore avec l'utilitaire java keytool (dans /usr/java/j2sdk1.4.1_02, accessible directement en ligne de commande grâce à /etc/profile.d/java.sh et /etc/java/java.conf).
Par exemple, pour lister le contenu du magasin de certificats du JDK :
% keytool -list [-v] -keystore $JAVA_HOME/jre/lib/security/cacerts
Enter keystore password: [vide]
***************** WARNING WARNING WARNING *****************
* The integrity of the information stored in your keystore *
* has NOT been verified! In order to verify its integrity, *
* you must provide your keystore password. *
***************** WARNING WARNING WARNING *****************
Keystore type: jks
Keystore provider: SUN
Your keystore contains 15 entries
thawtepersonalfreemailca, Feb 12, 1999, trustedCertEntry,
Certificate fingerprint (MD5): 1E:74:C3:86:3C:0C:35:C5:3E:C2:7F:EF:3C:AA:3C:D9
baltimorecodesigningca, May 10, 2002, trustedCertEntry,
Certificate fingerprint (MD5): 90:F5:28:49:56:D1:5D:2C:B0:53:D4:4B:EF:6F:90:22
[...]
verisignclass2ca, Jun 29, 1998, trustedCertEntry,
Certificate fingerprint (MD5): EC:40:7D:2B:76:52:67:05:2C:EA:F2:3A:4F:65:F0:D8
Chaque entrée est identifiée par un alias (thawtepersonalfreemailca par exemple).
Le format de keystore propriétaire de SUN est JKS.
Un utilitaire GUI est fourni avec le jdk pour gérer les keystores : policytool.
$JAVA_HOME/jre/lib/security/cacerts est le magasin de clé global de Java, mais keytool peut manipuler n'importe quel magasin.
Le mot de passe du magasin global est par défaut changeit.
% keytool -genkey -alias CAS -keyalg RSA -dname "CN=cas.univ-xxx.fr/Email=reseau@univ-xxx.fr,O=01234567W,C=FR" -keypass KeyPass -storepass StorePass -keystore CAS.keystore
Cela génère une paire de clé dans un certificat X509 auto-signé (CAS.keystore). On a spécifié un mot de passe pour protéger la clé (KeyPass), et un mot de passe pour protéger le keyStore (StorePass).
Si on ne précise pas le paramètre dname, les différents paramètres sont demandées par keytool de manière interactive.
On peut vérifier ce certificat :
% keytool -list [-v] -keystore CAS.keystore
On peut exporter le certificat vers la console :
% keytool -export -keystore CAS.keystore -alias CAS -storepass StorePass -rfc
Pour exporter la clé publique du certificat précédemment généré et stocké dans le magasin CAS.keystore :
% keytool -export -keystore CAS.keystore -alias CAS -storepass StorePass -file CAS.bin.export
Le fichier CAS.bin.export contient ainsi le certificat contenant la clé publique générée. C'est un fichier qu'on peut communiquer au monde entier.
Contrôle :
% keytool -printcert -file CAS.bin.export
Dans l'exemple suivant, on va importer dans le magasin CAS.keystore le certificat public d'un serveur avec lequel on désire communiquer (ici uportal.bin.export par exemple).
% keytool -import -alias uportal -file uportal.bin.export -keystore CAS.keystore -storepass StorePass
Contrôle :
% keytool -list -v -keystore CAS.keystore
Dans ce cas, ce ne sont plus des certificats autosignés. On va utiliser openSSL. On suppose que le certificat de l'autorité de certification est auto-signé.
On génère la paire de clés non signée comme auparavant, avec keytool. Cette fois-ci, one ne précise pas l'option -dname, la création sera interactive :
% keytool -genkey -alias CAS -keyalg RSA -storepass PassKeystore -keystore CAS2.keystore
On génère une requête de certificat :
% keytool -certreq -alias CAS -storepass PassKeystore -keystore CAS2.keystore -file CAS2.csr
On signe cette requête de certification avec l'autorité de CA locale (on peut également utiliser sign.sh CAS2.csr ou CA.pl -sign) :
% openssl ca -in CAS2.csr -out CAS2.pem -keyfile ca.key
On concatène le certificat généré et celui de notre CA (Les 2 doivent être en format pem, donc lisibles), afin d'avoir la chaine de certification au complet. Attention, l'ordre a de l'importance :
% (cat CAS2.pem ; echo ; cat cacert.pem) > cas-chain.pem
On édite à ce moment le fichier cas-chain.pem afin de supprimer tout ce qui ne serait pas entre des lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----. Le résultat doit être comme suit, avec un retour chariot en dernière ligne :
% -----BEGIN CERTIFICATE-----
MIIEBzCCAu+gAwIBAgICANcwDQYJKoZIhvcNAQEEBQAwUDELMAkGA1UEBhMCRlIx
... certificat de serveur
Qi5LxBjyiK5xCvkUge/2+oCyB4bxsikWf1sz
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIID1zCCAr+gAwIBAgIBAzANBgkqhkiG9w0BAQQFADBPMQswCQYDVQQGEwJGUjEM
... certificat de CA
6cKi0FjWaBYjBOH6/ULalf1g4P38vbUAT4A=
-----END CERTIFICATE-----
On peut contrôler la validité de ce fichier :
% keytool -printcert -file cas-chain.pem
Et ensuite, on importe la chaine de certification complète dans le keystore :
% keytool -import -alias CAS -file cas-chain.crt -trustcacerts -keystore CAS2.keystore
Maintenant, le fichier CAS2.keystore contient le couple de clés, le
certificat public et la chaine de certification.
Voir la FAQ de l'IGC du CRU, en particulier, les documents keystore1 et keystore2
On procède comme dans le paragraphe précédent pour générer le bi-clé et la requête de certification :
% keytool -genkey -alias CAS -keyalg RSA -dname "CN=cas.univ-xxx.fr/Email=reseau@univ-xxx.fr,O=01234567W,C=FR" -keystore CAS2.keystore % keytool -certreq -alias CAS -keystore CAS2.keystore -file CAS2.csr
Contrôle de la requête générée :
% openssl req -noout -text -in CAS2.csr
On transmet la demande de certification (CAS2.csr) à son autorité de certification, qui va la signer et vous retourner le certificat correspondant.
Différents cas peuvent se produire :
Appelons ce fichier cas-chain.crt
C'est le cas le plus favorable. Pour vous en assurer :
%keytool -printcert -file cas-chain.crt
S'il n'y a pas d'erreur, on peut passer à l'étape finale d'import de la chaine de certification dans le keystore.
Ce format est un format 'lisible'. keytool est capable de le lire, à condition de supprimer tout ce qui ne serait pas entre des lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----
Il faut également respecter un ordre : d'abord le certificat du serveur, puis celui de l'AC immédiatement supérieure, et ainsi de suite
Vérifier ensuite à l'aide de la même commande que précédemment.
Voir la FAQ de l'IGC du CRU
% keytool -import -alias CAS -file ca-chain.crt -trustcacerts -keystore CAS2.keystore -storepass StorePass
Controle :
% keytool -list -v -keystore CAS2.keystore
% keytool -delete -keystore <keystore> -alias <alias>
| Création : mars 2003 - Vincent Mathieu & Julien Marchal (Université de Nancy 2) | |
|
Modifications : |