Comment générer un CSR sur IBM HTTP Server

Ce guide vous montre comment générer une CSR (Certificate Signing Request) sur IBM HTTP Server (IHS), et comment effectuer la même opération sur HCL Domino (anciennement IBM Domino).

IBM HTTP Server stocke les clés et les certificats dans une base de données de clés CMS (un fichier .kdb plus un fichier de « stash » .sth), que vous gérez avec l’outil graphique IKEYMAN ou l’utilitaire en ligne de commande gskcapicmd de l’IBM Global Security Kit (GSKit) livré avec IHS.

Les étapes ci-dessous couvrent les deux méthodes sur IHS 9.0.5.x (la version actuellement prise en charge), puis les deux flux de CSR pour HCL Domino : la base de données classique Server Certificate Administration (conservée pour les installations existantes) et la tâche moderne Certificate Manager avec certstore.nsf, que HCL recommande sur Domino 12 et versions ultérieures.

Générer une CSR sur IBM HTTP Server

Si vous avez déjà généré votre CSR, passez directement à comment installer un certificat SSL sur IBM HTTP Server.

Vous pouvez créer la demande de deux façons sur IHS : via l’interface graphique IKEYMAN (l’utilitaire classique à points-et-clics), ou avec gskcapicmd en ligne de commande. Les deux écrivent la clé privée dans la même base de données de clés CMS et produisent une demande PKCS #10 sous forme de fichier .arm que vous soumettez à votre autorité de certification. Choisissez l’interface graphique sur un poste de travail ou un serveur avec écran ; choisissez la CLI sur une machine sans interface graphique ou lorsque vous voulez un script reproductible.

Prérequis : IBM HTTP Server est installé, GSKit est présent sur le système (il est livré dans le package IHS), et le répertoire bin d’IHS figure dans votre PATH ou vous connaissez son chemin complet (généralement /opt/IBM/HTTPServer/bin/ sous Linux/AIX, ou C:Program FilesIBMHTTPServerbin sous Windows). Vous avez également besoin d’un répertoire de travail où écrire la nouvelle base de données de clés et le fichier CSR, ainsi que d’un endroit pour noter le mot de passe de la base de données de clés.

Méthode 1. Générer une CSR avec IKEYMAN (interface graphique)

Étape 1. Créer une nouvelle base de données de clés CMS (.kdb)

• Démarrez IKEYMAN. Sous Windows, ouvrez Démarrer > IBM HTTP Server > Start Key Management Utility. Sous Linux, AIX ou autre UNIX, exécutez ikeyman depuis le répertoire bin d’IHS (par exemple /opt/IBM/HTTPServer/bin/ikeyman) ; vous avez besoin d’un affichage X11 fonctionnel.
• Dans le menu, choisissez Key Database File > New.
• Dans la liste déroulante Key database type, sélectionnez CMS. C’est le format qu’IBM HTTP Server lit.
• Dans File Name, saisissez un nom pour la nouvelle base de données (par exemple key.kdb).
• Dans Location, indiquez un dossier que vous pourrez retrouver (par exemple /opt/IBM/HTTPServer/ssl/ sous Linux, ou C:IBMHTTPServerssl sous Windows). Cliquez sur OK.
• Définissez un mot de passe fort, puis cochez Stash password to a file pour qu’IKEYMAN écrive un fichier de « stash » .sth correspondant à côté du fichier .kdb. IHS lit ce fichier au démarrage afin que vous n’ayez pas à saisir le mot de passe à chaque démarrage du serveur. Cliquez sur OK.

IKEYMAN crée deux fichiers dans ce dossier : la base de données elle-même (key.kdb) et le fichier de stash (key.sth). Traitez les deux comme des éléments confidentiels. Restreignez fortement leurs permissions de fichiers (lisibles uniquement par l’utilisateur IHS) et sauvegardez-les dans un emplacement sûr, car vous ne pourrez pas récupérer la clé privée sans eux.

Étape 2. Créer la demande de certificat

• Avec la nouvelle base de données ouverte, trouvez la liste déroulante Key database content et changez-la en Personal Certificate Requests.
• Cliquez sur New. La boîte de dialogue Create New Key and Certificate Request s’ouvre.

Remplissez les champs uniquement avec des caractères ASCII standards ; les lettres non latines invalident la demande :

• Key Label : un identifiant court pour ce certificat dans la base de données de clés, par exemple www.example.com. Vous référencerez ce libellé plus tard dans httpd.conf avec la directive SSLServerCert.
• Key Size : sélectionnez 2048. C’est le minimum actuel accepté par toutes les autorités de certification publiques. Choisissez 3072 ou 4096 uniquement si votre politique exige une clé plus grande ; le compromis est une poignée de main TLS légèrement plus lente.
• Signature Algorithm : choisissez SHA256WithRSA (ou plus fort, comme SHA384WithRSA). Évitez tout ce qui utilise SHA-1 ; les autorités de certification publiques ne délivreront pas de certificat basé dessus.
• Common Name : le nom de domaine pleinement qualifié que vous souhaitez sécuriser, par exemple www.example.com. Pour un certificat wildcard, placez un astérisque devant le domaine racine, par exemple *.example.com.
• Organization : le nom légal complet de votre entreprise, exactement tel qu’enregistré. Requis pour les certificats OV et EV ; ignoré pour les DV.
• Organizational Unit : cet attribut est obsolète pour les certificats publics (le CA/Browser Forum l’a supprimé progressivement). Laissez-le vide ou saisissez un court libellé comme IT.
• Locality : le nom complet de la ville (par exemple Seattle, pas SEA).
• State/Province : le nom complet de l’État ou de la province (par exemple Washington, pas WA).
• Country : le code pays ISO à deux lettres, par exemple US, GB ou DE.
• Subject Alternative Names (SAN) : ajoutez tous les noms d’hôte qui doivent apparaître sur le certificat, y compris la valeur saisie dans Common Name. Les navigateurs modernes ignorent le Common Name et valident uniquement à partir de la liste SAN ; un certificat multi-noms nécessite donc des entrées ici.
• Enter the name of a file in which to store the certificate request : un chemin et un nom se terminant par .arm, par exemple /opt/IBM/HTTPServer/ssl/www_example_com.arm. Enregistrez-le dans le même dossier que la base de données de clés pour qu’ils restent liés.

Cliquez sur OK. IKEYMAN génère la paire de clés dans la base de données de clés, enregistre la demande comme entrée en attente, et écrit la CSR PKCS #10 dans le fichier .arm que vous avez nommé.

Étape 3. Copier la CSR et la soumettre à l’autorité de certification

Ouvrez le fichier .arm dans un éditeur de texte quelconque (Notepad, vi, nano). Vous verrez un bloc comme celui-ci :

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIDXjCCAkYCAQAwgZQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApXYXNoaW5ndG9u
... (many lines of base64) ...
-----END NEW CERTIFICATE REQUEST-----

Sélectionnez le bloc entier, y compris les lignes BEGIN et END, copiez-le, et collez-le dans le champ CSR de votre formulaire de commande. La clé privée reste dans la base de données de clés sur le serveur ; seul le texte de la CSR quitte la machine.

Méthode 2. Générer une CSR avec gskcapicmd (CLI)

L’utilitaire gskcapicmd (parfois répertorié comme gskcmd pour l’enveloppe Java, ou gsk8capicmd_64 sur les installations GSKit 64 bits) effectue le même travail qu’IKEYMAN sans session graphique. Exécutez-le depuis le répertoire bin d’IHS.

Étape 1. Créer la base de données de clés CMS et le fichier de stash

Choisissez un dossier pour la base de données de clés, puis exécutez :

gskcapicmd -keydb -create 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -type cms 
  -stash

Détail des arguments :

• -db : le chemin complet vers le nouveau fichier .kdb.
• -pw : le mot de passe qui protège la base de données de clés.
• -type cms : le format qu’IHS lit.
• -stash : écrit un fichier de stash .sth correspondant à côté de la base de données afin qu’IHS puisse le lire sans invite au démarrage.

En ligne de commande, le mot de passe est visible dans les listes de processus et l’historique du shell. Une fois la base de données créée, changez le mot de passe pour un mot de passe non enregistré dans l’historique avec gskcapicmd -keydb -changepw, ou transmettez le mot de passe via une variable d’environnement puis annulez-la.

Étape 2. Créer la demande de certificat

Générez la paire de clés et la CSR PKCS #10 en une seule étape, avec des entrées SAN pour chaque nom d’hôte que vous souhaitez inclure sur le certificat :

gskcapicmd -certreq -create 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -label www.example.com 
  -dn "CN=www.example.com,O=Example Inc,L=Seattle,ST=Washington,C=US" 
  -size 2048 
  -sigalg SHA256WithRSA 
  -san_dnsname "www.example.com,example.com" 
  -file /opt/IBM/HTTPServer/ssl/www_example_com.arm

Détail des arguments :

• -label : l’identifiant de ce certificat dans la base de données de clés. Référencez-le plus tard depuis httpd.conf avec la directive SSLServerCert.
• -dn : le nom distinctif (Distinguished Name), écrit comme une chaîne unique avec des attributs séparés par des virgules. Utilisez CN= pour le FQDN et le code ISO à deux lettres dans C=.
• -size : 2048 est le minimum. Utilisez 3072 ou 4096 uniquement si votre politique l’exige.
• -sigalg : SHA256WithRSA (ou SHA384WithRSA). N’utilisez pas SHA-1.
• -san_dnsname : une liste séparée par des virgules de chaque nom d’hôte devant apparaître sur le certificat. Incluez la valeur du Common Name dans cette liste. Les navigateurs et la plupart des bibliothèques TLS valident uniquement le SAN, pas le CN.
• -file : le chemin où gskcapicmd écrit le fichier CSR .arm.

Si vous avez besoin d’une clé ECDSA au lieu de RSA, remplacez -sigalg SHA256WithRSA par -sigalg SHA256WithECDSA et modifiez -size pour correspondre à votre courbe cible (-size 256 pour P-256, -size 384 pour P-384). Les courbes prises en charge sont secp256r1 (P-256), secp384r1 (P-384) et secp521r1 (P-521). Le support ECDSA dans IHS n’est pleinement exposé que via gskcapicmd ; IKEYMAN ne permet pas de choisir ECDSA sur les anciennes versions d’IHS. Pour ECDSA sur une version spécifique d’IHS, suivez les indications d’IBM sur la gestion des certificats.

Étape 3. Lister et vérifier la demande

Confirmez que la demande a été ajoutée à la base de données de clés :

gskcapicmd -certreq -list 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password

Pour relire la CSR et vérifier le Common Name, les entrées SAN, la taille de la clé et l’algorithme de signature :

gskcapicmd -certreq -details 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -label www.example.com

Ouvrez ensuite le fichier .arm dans un éditeur de texte, copiez le bloc complet allant de BEGIN NEW CERTIFICATE REQUEST à END NEW CERTIFICATE REQUEST, et soumettez-le sur le formulaire de commande de votre autorité de certification.

Vérifier la CSR avant de la soumettre (facultatif)

Si vous avez OpenSSL installé, exécutez ceci sur la même machine pour confirmer le sujet, la liste SAN et la taille de la clé :

openssl req -noout -text -in www_example_com.arm

Vous préférez un outil en ligne ? Collez le contenu de la demande dans le Décodeur de CSR de SSL Dragon pour relire les mêmes détails. Confirmez que le Common Name correspond au nom d’hôte que les clients utiliseront et que chaque nom d’hôte requis apparaît sous Subject Alternative Name.

Après la délivrance de votre certificat par l’autorité de certification

Le certificat signé doit revenir dans la même base de données de clés qui a produit la CSR, sous le même libellé. Recevez-le avec la CLI :

gskcapicmd -cert -receive 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -file www_example_com.crt

Ou faites de même dans IKEYMAN sous Personal Certificates > Receive. Ajoutez d’abord les certificats racine et intermédiaires en tant que certificats de signataires, puis mettez à jour httpd.conf avec les directives KeyFile et SSLServerCert, et redémarrez IHS. La procédure complète est décrite dans comment installer un certificat SSL sur IBM HTTP Server.

Générer une CSR sur HCL Domino

Remarque : IBM Domino s’appelle désormais HCL Domino. HCL a finalisé l’acquisition du portefeuille de collaboration d’IBM (y compris Notes/Domino) le 1er juillet 2019. Sur Domino 12 et versions ultérieures, HCL recommande la tâche Certificate Manager (avec certstore.nsf et les documents TLS Credentials) pour tous les nouveaux travaux TLS. La base de données classique Server Certificate Administration (CERTSRV.NSF) fonctionne toujours pour les installations existantes et est documentée ci-dessous, mais les nouveaux déploiements devraient utiliser Certificate Manager.

Méthode A. Créer une CSR avec Certificate Manager (Domino 12+ / 14.x)

• Ajoutez la tâche CertMgr sur votre serveur Certificate Manager désigné afin qu’il crée certstore.nsf. Sur chaque serveur Domino qui doit lire les clés TLS, exécutez également CertMgr pour que la base de données se réplique.
• Ouvrez certstore.nsf, allez dans TLS Credentials, et cliquez sur Add TLS Credentials.
• Host names : saisissez le FQDN exact que les clients utiliseront, et ajoutez chaque nom d’hôte supplémentaire en tant que Subject Alternative Name.
• Servers with access : sélectionnez les serveurs Domino qui doivent pouvoir lire la clé privée.
• Certificate Provider : choisissez Manual pour toute autorité de certification tierce. (Choisissez Let’s Encrypt uniquement si vous souhaitez que CertMgr obtienne automatiquement un certificat gratuit délivré via ACME.)
• Key type : choisissez RSA ou ECDSA.
• RSA : sélectionnez 2048 bits (ou plus si votre politique l’exige).
• ECDSA : choisissez une courbe (P-256 ou P-384 ; P-384 est la valeur par défaut indiquée).
• Cliquez sur Submit Request. CertMgr génère la paire de clés, signe la CSR, et le document passe à Status = Waiting.
• Ouvrez le document, copiez la valeur de Certificate signing request (CSR) (ou utilisez l’action Copy CSR qui apparaît après le traitement), et collez le bloc PEM dans le formulaire de commande de votre autorité de certification.

La clé privée reste dans certstore.nsf, chiffrée pour les serveurs que vous avez autorisés. Vous ne l’exportez jamais. Lorsque l’autorité de certification délivre votre certificat, collez le certificat signé (ainsi que la chaîne émettrice) dans le même document TLS Credentials, et CertMgr l’installe pour vous. La référence complète se trouve dans la documentation de Certificate Manager de HCL.

Méthode B. Server Certificate Administration classique (Domino existant)

N’utilisez cette méthode que sur les versions de Domino qui reposent encore sur des fichiers de trousseau de clés (.kyr + .sth). HCL la marque comme obsolète sur Domino 12 et versions ultérieures.

• Dans le client Domino Administrator, ouvrez Server Certificate Administration.
• Choisissez Create Key Ring. Saisissez un nom de trousseau de clés et un mot de passe fort.
• Key Size : sélectionnez 2048 bits.
• Remplissez le nom distinctif :
• Common Name : le FQDN que vous souhaitez sécuriser, par exemple www.example.com.
• Organization : le nom légal complet de votre entreprise.
• Organizational Unit : laissez vide ou saisissez un court libellé comme IT (l’attribut est obsolète pour les certificats publics).
• City or Locality : le nom complet de la ville, par exemple Seattle.
• State or Province : le nom complet de l’État, par exemple Washington.
• Country : le code ISO à deux lettres, par exemple US.
• Vérifiez les détails et cliquez sur Continue. Domino crée le fichier de trousseau de clés.
• Choisissez Create Certificate Request. Sous Method, choisissez Paste into form on CA’s site. Domino affiche le texte de la CSR.
• Copiez le bloc CSR entier (y compris les lignes BEGIN et END) et collez-le dans le formulaire de commande de votre autorité de certification.

Les fichiers de trousseau de clés classiques ne prennent pas en charge les entrées SAN via cette boîte de dialogue. Si vous avez besoin d’un certificat multi-noms, passez à Certificate Manager (méthode A) ou générez la CSR en dehors du serveur.

Questions fréquemment posées