Comment générer un CSR sur les serveurs JBoss

Ce tutoriel vous montre comment générer un CSR (Certificate Signing Request) sur JBoss EAP et WildFly à l’aide de l’utilitaire Java keytool. Le processus se compose de deux commandes : d’abord keytool -genkeypair crée un keystore et une clé privée sous un alias choisi, puis keytool -certreq exporte le CSR correspondant avec les Subject Alternative Names que la CA émettra. Le même alias est réutilisé plus tard lorsque vous importez le certificat signé, de sorte que la clé, le CSR et le certificat final se trouvent tous au même endroit.

Remarque sur les versions : la version moderne de JBoss est Red Hat JBoss Enterprise Application Platform (EAP) 8, sortie en février 2024 et basée sur le projet amont WildFly (WildFly 41, sorti en juillet 2026, est la version communautaire actuelle). Les deux gèrent HTTPS via le sous-système elytron et le https-listener d’Undertow ; l’ancienne configuration de connecteur Tomcat ou Jetty présentée dans les guides obsolètes ne s’applique plus. L’étape du CSR elle-même est cependant identique dans toutes les versions récentes, car il s’agit d’une simple opération Java keytool.

Ce dont vous aurez besoin

• Une installation Java (JDK ou JRE) pour que la commande keytool soit disponible. JBoss EAP 8.0 fonctionne sur Java 11 (déprécié) ou 17, EAP 8.1 ajoute Java 21, et WildFly 41 fonctionne sur Java 17, 21 ou 25 (Java 11 n’est plus pris en charge en amont). Vérifiez avec keytool -help.
• Un accès shell ou terminal sur le serveur JBoss qui hébergera la clé privée. La clé privée doit rester sur ce serveur.
• Le nom de domaine complet (FQDN) exact que vous souhaitez sécuriser, par exemple www.votredomaine.com, ainsi que tout autre nom d’hôte supplémentaire que vous souhaitez couvrir dans le champ SAN.
• Les informations légales de votre organisation (pays, état, localité, nom de l’organisation) pour le Distinguished Name du CSR.

Étape 1 : Créer le keystore et la clé privée

Si vous avez déjà généré votre CSR, passez directement à l’envoi du CSR, puis à l’installation de votre certificat SSL sur JBoss.

Ouvrez un terminal sur le serveur JBoss et créez un nouveau keystore au format PKCS12. PKCS12 est la norme moderne et portable (RFC 7292) et constitue le format de keystore par défaut dans Java depuis JDK 9 ; l’ancien format propriétaire JKS est déprécié. Exécutez :

keytool -genkeypair 
  -alias jboss 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yourdomain.p12 
  -validity 825

Signification des options :

• -alias jboss : le nom de l’entrée dans le keystore. Choisissez une étiquette que vous reconnaîtrez (souvent jboss, server, ou votre domaine). Notez-le. Vous devez réutiliser cet alias exact lorsque vous générez le CSR et à nouveau lorsque vous importez le certificat signé. Utiliser un alias différent lors de l’importation est l’erreur keytool la plus courante.
• -keyalg RSA -keysize 2048 : une clé RSA de 2048 bits est le minimum public actuel. Pour les nouveaux keystores que vous comptez conserver plusieurs années, 3072 bits est une mise à niveau raisonnable. La plupart des CA publiques acceptent également ECDSA (-keyalg EC -groupname secp256r1) si vous préférez une clé plus petite et plus rapide. L’option -groupname nécessite JDK 13 ou ultérieur ; sur Java 11, utilisez plutôt -keyalg EC -keysize 256, qui sélectionne la même courbe secp256r1. keytool refuse d’utiliser les deux options dans la même commande.
• -storetype PKCS12 : impose le format moderne PKCS12. L’extension correspondante est .p12 (ou .pfx).
• -keystore yourdomain.p12 : le fichier keystore à créer. Remplacez le nom par quelque chose que vous reconnaîtrez, et conservez ce fichier en sécurité ; il contient votre clé privée.
• -validity 825 : la durée de validité du certificat provisoire autosigné à l’intérieur du keystore. Le certificat signé par la CA le remplace ensuite, donc la valeur exacte n’affecte pas la durée de vie en production.

keytool demande ensuite un mot de passe du keystore. Choisissez un mot de passe fort et stockez-le dans votre gestionnaire de secrets : vous en aurez besoin pour chaque commande keytool ultérieure et pour le credential-reference Elytron que vous configurerez dans JBoss. Avec les keystores PKCS12, le mot de passe de la clé est identique au mot de passe du keystore, il n’y a donc qu’un seul mot de passe à retenir.

Étape 2 : Saisir les informations de votre organisation (DN)

keytool demande maintenant le Distinguished Name (DN) : les champs d’identité qui figurent dans le CSR. Répondez à chaque invite avec la valeur exacte et légale de votre organisation. La ponctuation et l’exactitude sont importantes, car une CA rejettera toute divergence par rapport aux registres publics de l’entreprise.

• First and last name (CN) : c’est la formulation de keytool, mais il s’agit bien du champ Common Name. Saisissez le FQDN exact que vous sécurisez, par exemple www.votredomaine.com, ou un wildcard tel que *.votredomaine.com. Ne saisissez pas le nom d’une personne.
• Organizational unit (OU) : ce champ n’est plus émis par les CA publiques et il est préférable de le laisser vide. Notez qu’appuyer sur Entrée ne le laisse pas vide : keytool substitue sa propre valeur par défaut, de sorte que le DN finit par contenir OU=Unknown, qui se retrouve ensuite dans le CSR. Pour omettre réellement ce champ, utilisez la forme non interactive -dname ci-dessous et n’incluez pas l’OU dans la chaîne.
• Organization (O) : le nom légal complet de votre entreprise, par exemple Your Company LLC. Les certificats OV et EV l’exigent ; pour les certificats DV, de nombreuses CA l’acceptent à titre informatif, il est donc plus sûr de le renseigner plutôt que de le laisser vide.
• City or locality (L) : le nom complet de la ville, par exemple San Jose. N’abrégez pas.
• State or province (ST) : le nom complet de l’état ou de la province, par exemple California. N’utilisez pas de code à deux lettres.
• Country code (C) : le code pays ISO à deux lettres, par exemple US, GB, DE.

Après la dernière invite, keytool affiche un résumé du type CN=www.votredomaine.com, OU=Unknown, O=Your Company LLC, L=San Jose, ST=California, C=US. Tapez yes pour confirmer. Le fichier keystore existe désormais avec une entrée : votre alias, contenant la clé privée et un certificat provisoire autosigné.

Si vous préférez une commande non interactive, indiquez le DN directement et évitez les invites :

keytool -genkeypair 
  -alias jboss 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yourdomain.p12 
  -dname "CN=www.yourdomain.com, O=Your Company LLC, L=San Jose, ST=California, C=US" 
  -validity 825

Étape 3 : Générer le CSR avec les SAN

Les navigateurs modernes et les clients TLS valident les certificats par rapport à l’extension Subject Alternative Name (SAN), et non uniquement par rapport au Common Name. Demandez les SAN directement dans le CSR afin que la CA les inclue dans le certificat émis. Utilisez le même alias et le même keystore que ceux de l’étape 1 :

keytool -certreq 
  -alias jboss 
  -keystore yourdomain.p12 
  -file yourdomain.csr 
  -ext san=dns:yourdomain.com,dns:www.yourdomain.com

Signification des options :

• -alias jboss : doit correspondre à l’alias de l’étape 1. C’est l’alias dont la clé privée signe la demande.
• -keystore yourdomain.p12 : doit correspondre au keystore de l’étape 1.
• -file yourdomain.csr : le nom du fichier de sortie pour le CSR.
• -ext san=dns:… : l’extension Subject Alternative Name. Listez chaque nom d’hôte que le certificat doit couvrir, y compris à la fois le domaine racine (yourdomain.com) et le sous-domaine www. Ajoutez d’autres entrées séparées par des virgules, par exemple dns:api.yourdomain.com.

keytool demande le mot de passe du keystore et écrit le CSR dans yourdomain.csr dans le répertoire courant.

Important : conservez votre alias et votre keystore

L’erreur keytool la plus courante sur JBoss consiste à importer le certificat signé sous un nouvel alias. Cela stocke le certificat comme une entrée de confiance autonome sans clé privée associée, et le gestionnaire de clés Elytron échouera à démarrer une session TLS. Importez toujours la réponse signée dans le même alias qui contient la clé privée (l’alias de l’étape 1).

Notez ces trois valeurs dès maintenant, avant de fermer le terminal :

• L’alias (dans ce guide, jboss).
• Le chemin du fichier keystore (par exemple yourdomain.p12 ; sur JBoss, il se trouve généralement dans $JBOSS_HOME/standalone/configuration/).
• Le mot de passe du keystore.

Si vous n’êtes pas sûr de savoir quel alias contient votre clé, listez le contenu du keystore et recherchez l’entrée dont le type est PrivateKeyEntry :

keytool -list -v -keystore yourdomain.p12

Étape 4 : Vérifier le CSR avant de le soumettre

Repérez les fautes de frappe dans le DN ou les SAN manquants avant que la CA ne les valide. Affichez le CSR avec keytool :

keytool -printcertreq -file yourdomain.csr

Ou, si OpenSSL est installé, vous pouvez l’utiliser à la place :

openssl req -noout -text -in yourdomain.csr

Vérifiez trois éléments dans le résultat : le Subject affiche votre DN exact, le Subject Alternative Name liste chaque nom d’hôte requis, et la taille de la Public-Key correspond à ce que vous avez demandé (RSA 2048 bits, ou ce que vous avez choisi). Vous pouvez également coller le CSR dans notre Décodeur CSR pour effectuer la même vérification dans un navigateur.

Étape 5 : Soumettre le CSR à votre autorité de certification

Ouvrez yourdomain.csr dans n’importe quel éditeur de texte. Le fichier est en texte brut, commençant par -----BEGIN NEW CERTIFICATE REQUEST----- et se terminant par -----END NEW CERTIFICATE REQUEST-----. Le mot NEW est ce que keytool écrit, et c’est normal : le contenu est une demande PKCS#10 standard que toute CA accepte. Copiez le bloc entier, y compris ces lignes d’en-tête et de pied de page, et collez-le dans le champ CSR lors de la commande auprès de votre CA. Sous Windows, utilisez Ctrl + A puis Ctrl + C pour saisir le texte complet ; sous macOS, utilisez Cmd + A puis Cmd + C.

Sauvegardez le fichier keystore avant de faire quoi que ce soit d’autre. Si vous perdez yourdomain.p12, vous perdez également la clé privée, ce qui signifie que le certificat signé renvoyé par la CA sera inutilisable et que vous devrez recommencer avec un nouveau CSR.

Une fois que la CA a validé votre demande et émis le certificat, poursuivez avec comment installer votre certificat SSL sur JBoss. Vous importerez le certificat signé dans le même alias du même keystore, puis vous référencerez ce keystore à partir d’un key-store, d’un key-manager et d’un server-ssl-context Elytron connectés au https-listener d’Undertow.

Puis-je réutiliser un CSR pour un renouvellement ?

Vous le pouvez, mais la bonne pratique de sécurité consiste à générer un nouveau keystore, une nouvelle clé privée et un nouveau CSR pour chaque certificat. Une nouvelle clé à chaque renouvellement limite l’impact si l’ancienne clé venait à être compromise, et le processus est le même : exécutez keytool -genkeypair et keytool -certreq sur un nouveau fichier keystore. Les durées de vie des certificats TLS publics diminuent en vertu des règles du CA/Browser Forum (200 jours à partir du 15 mars 2026, réduits à 100 jours en 2027 et à 47 jours en 2029), planifiez donc des cycles de CSR plus fréquents, ou automatisez l’émission via ACME lorsque votre CA le prend en charge.