Java KeyStore (JKS) : fichier .jks

Le JKS regroupe certificats et clés privées dans un conteneur propriétaire propre à la plateforme Java, généré et manipulé via l’outil en ligne de commande keytool fourni avec le kit de développement Java ; il joue un rôle central pour configurer le TLS d’un serveur d’applications Java (Tomcat, WildFly…).

Sa signature numérique 0xFEEDFEED identifie le format sans ambiguïté connue. Oracle recommande désormais PKCS#12 (le même format que les fichiers .p12/.pfx) comme type de KeyStore par défaut, plus standardisé et interopérable en dehors de l’écosystème Java, réduisant progressivement l’usage du JKS aux configurations existantes.

Un même fichier JKS peut regrouper plusieurs entrées distinctes (couples clé privée/certificat, ou simples certificats de confiance), chacune identifiée par un alias : c’est cet alias, précisé en argument de keytool, qui permet de cibler une entrée précise sans manipuler tout le conteneur.

La migration recommandée d’un ancien KeyStore JKS vers PKCS#12 s’effectue directement avec keytool -importkeystore, sans devoir régénérer les certificats ou les clés existants, ce qui limite l’impact opérationnel du changement de format sur une infrastructure en production.

La signature des applications Android a longtemps reposé sur un JKS manipulé via jarsigner, avant que Google ne pousse vers le format PKCS#12 et son propre schéma de signature d’application (APK Signature Scheme v2/v3), une évolution parallèle à celle observée côté serveurs Java, où PKCS#12 remplace également le JKS.

Un serveur d’applications Java comme Tomcat qui souhaite utiliser un certificat gratuit délivré par Let’s Encrypt via ACME doit généralement passer par une étape de conversion manuelle, le client ACME produisant nativement des fichiers PEM qu’il faut ensuite importer dans un KeyStore JKS ou PKCS#12 avec keytool avant que le serveur Java ne puisse les exploiter directement.