Keystore, truststore, JKS, PKCS#12 : les termes
Les applications Java comme Tomcat, Spring Boot, Jira, Keycloak ou Elasticsearch ne stockent pas les certificats en fichiers séparés mais dans un keystore : un fichier protégé par mot de passe avec des entrées nommées (alias).
- Keystore : contient ta propre clé privée avec son certificat et les intermédiaires. Un serveur (ou un client en mTLS) s’identifie avec.
- Truststore : ne contient que des certificats d’AC de confiance. Le truststore de Java s’appelle
cacertset se trouve dans$JAVA_HOME/lib/security/. - JKS est l’ancien format propre à Java. Depuis Java 9, PKCS#12 (.p12, .pfx) est le standard, lisible aussi par OpenSSL, Windows et les navigateurs.
- JCEKS est une variante de JKS avec une meilleure protection des clés, qui peut aussi stocker des clés secrètes (p. ex. AES).
Erreurs typiques et leur signification
- « Keystore was tampered with, or password was incorrect » : le mot de passe est faux. Ici, cela apparaît comme un contrôle d’intégrité échoué.
- « Cannot recover key » / « Given final block not properly padded » : en JKS, la clé a un autre mot de passe que le keystore. L’outil demande alors le mot de passe de clé.
- « PKIX path building failed » côté client : il manque les intermédiaires dans le keystore du serveur ou l’AC racine dans le truststore du client. L’outil montre les deux.
- Le truststore est ignoré alors que le certificat y est : les PKCS#12 créés avec OpenSSL n’ont pas d’attribut de confiance Java, donc Java ne voit pas les certificats comme entrées de confiance. Les truststores créés ici ont l’attribut.
- « Alias name does not identify a key entry » : l’alias de la configuration pointe vers un certificat seul au lieu de la clé.
Convertir JKS en PKCS#12
Ouvre le fichier, choisis « PKCS#12 » en bas, définis un mot de passe et télécharge. Adapte ensuite le type dans la configuration, p. ex. certificateKeystoreType="PKCS12" dans Tomcat ou server.ssl.key-store-type=PKCS12 dans Spring Boot. « PKCS#12 compatible » utilise des méthodes plus anciennes (3DES, SHA-1) pour Windows Server 2016, d’anciennes versions de Java 8 et des appareils qui ne lisent pas l’AES en PKCS#12.
S’il manque des intermédiaires, le convertisseur de certificats les ajoute. La vérification SSL montre ensuite ce que le serveur envoie vraiment, et la correspondance des clés vérifie aussi si clé, certificat et CSR vont ensemble.
FAQ
Mon keystore est-il envoyé quelque part ?
Non. Le fichier est lu et déchiffré dans ton navigateur ; mots de passe et clés ne quittent pas ton appareil. Une fois chargée, la page fonctionne aussi hors ligne.
Quel est le mot de passe de cacerts ?
changeit par défaut. Depuis Java 9, keytool y accède directement avec l’option -cacerts, sans indiquer le chemin.
Puis-je retrouver un mot de passe de keystore oublié ?
Non. En JKS, les certificats s’affichent sans mot de passe, mais pas les clés privées. Il ne reste qu’une nouvelle clé et un nouveau certificat.
Pourquoi PKCS#12 n’a-t-il qu’un mot de passe ?
Pour PKCS#12, Java utilise le même mot de passe pour le fichier et la clé, et beaucoup de programmes comme Tomcat l’exigent. Des mots de passe de clé séparés n’existent en pratique qu’en JKS.
Que deviennent les clés secrètes de JCEKS ?
Elles sont affichées mais pas reprises, car leur contenu est stocké sous forme d’objet Java sérialisé. keytool -importkeystore peut les transférer en PKCS#12.