Comment créer et configurer des clés SSL et des magasins de confiance

Cet article sera le premier d'une série en plusieurs parties traitant de la configuration de divers magasins de clés et magasins de confiance IBM MQ et IBM Integration Bus et de leur remplissage avec des certificats.

Informations générales

Les magasins de clés et magasins de confiance sont fichiers dans un format propriétaire. Les magasins de clés conservent les certificats envoyés par une application lors de l'établissement de la liaison SSL. C’est le «passeport» de l’application, si vous voulez. C'est ce qu'on appelle un «magasin de clés» car parfois les certificats sont appelés des clés. Les termes sont très proches mais pas interchangeables.

Lorsque votre application envoie un certificat pour s'identifier à l'application réceptrice, on parle d'authentification à sens unique ou d'authentification client seulement (car votre application est le client dans cet exemple). . Lorsque l’application destinataire renvoie son certificat, elle est appelée authentification bidirectionnelle ou authentification mutuelle.

Quand une application reçoit un certificat, comment sait-elle qu’elle doit lui faire confiance? Il peut s’agir d’un certificat auto-signé, c’est-à-dire qu’il a été signé par l’application qui l’a envoyé et qu’il vous est demandé de faire confiance à l’ordinateur qui l’a envoyé. Un autre type de certificat est un certificat délivré par une autorité de certification (en l’occurrence, CA), une entreprise qui émet des certificats et met leur réputation et leur bien-être financier au cœur de leur existence. Il existe plusieurs autorités de certification et si vous souhaitez utiliser leurs certificats, vous devez acheter leurs services via un contrat et soumettre des demandes de certificats via leur interface. Les CA offrent également d'autres services. Par exemple. OCSP (protocole de statut de certificat en ligne) est un service auquel vous pouvez envoyer tous les certificats émis par cette autorité de certification. Ils vous répondront que le certificat ait été révoqué ou non. La révocation est une action entreprise par une autorité de certification lorsqu'un système informatique devient compromis et, semble-t-il, que leurs certificats (et leurs clés privées à l'intérieur de ceux-ci) ont peut-être été rendus publics.

Après avoir soumis votre demande de certificat à une autorité de certification, ils vous enverront un certificat suivi d'une série de certificats liés (vous obtiendrez généralement vos certificats par courrier électronique et il y aura généralement trois autres certificats avec l'option de les télécharger séparément). Le tout dernier est le certificat racine de l'autorité de certification (car tous les autres certificats commencent à partir de celui-ci). Les certificats liés au certificat racine sont appelés une chaîne. Comme vous utilisez la chaîne pour approuver le premier certificat, son nom complet est une chaîne de confiance. La chaîne de confiance est uniquement associée à l'autorité de certification et le tout premier certificat est associé au système qui a demandé un certificat. Pour cette raison, il s’agit d’un certificat personnel.

Répondant à notre propre question, il s’agit de la chaîne de confiance que l’application destinataire utilise pour valider ou «faire confiance» au certificat personnel. Il compare la chaîne de confiance envoyée par l'autre application à ce qu'elle a stocké. Vous pouvez télécharger et stocker toutes les chaînes de confiance des autorités de certification avec lesquelles votre entreprise travaille et les utiliser pour la validation. Le magasin de certificats qui stocke les chaînes de confiance s'appelle un magasin de confiance. Le magasin de certificats qui stocke les certificats personnels s'appelle un magasin de clés.

Outils du commerce

Les magasins de clés configurés et les magasins d'approbation sont des fichiers pouvant être déplacés entre plates-formes. Par exemple, vous pouvez utiliser des outils graphiques sous Windows pour configurer un magasin de clés pour un hôte Linux, puis déplacez le fichier dans la zone Linux. Certains types de magasins (.kdb, .jks) génèrent plusieurs fichiers. Par conséquent, si vous les déplacez, veillez à déplacer tous leurs fichiers correspondants.

Nous utiliserons IBM Key Management (en abrégé, ikeyman). un utilitaire gratuit fourni avec plusieurs de leurs produits (MQ, WAS, etc.). C'est un excellent outil que vous pouvez trouver dans dans c: program files ibm mq bin strmqikm ou / opt / mqm / bin / strmqikm si vous avez installé MQ dans le emplacement par défaut.

Nous allons protéger notre magasin de clés avec un bon mot de passe. Vous pouvez utiliser un autre outil fourni par IBM pour générer un mot de passe conforme à FIPS. Vous pouvez le trouver à c: program files ibm mq bin runmqakm ou / opt / mqm / bin / runmqakm si vous avez installé MQ à l'emplacement par défaut. La commande à exécuter est la suivante:

runmqakm –random –create –length 14 –strong –fips

Consultez les captures d'écran pour obtenir des exemples de mots de passe générés par cet outil.

]

Je vais également donner des exemples utilisant un autre utilitaire payant runmqckm fourni avec MQ.

Il existe d'autres formats, qui existent aussi pour les fichiers de clés et de confiance, ainsi que pour différents outils fonctionnant uniquement avec ces formats ou universels. La prise en charge des fournisseurs pour divers formats et extensions varie. Il est courant que vous deviez convertir un magasin de clés d’un format à un autre pour le faire fonctionner avec un autre produit sur le même hôte.

CMS – Services de gestion de certificats, format utilisé par IBM MQ. Les fichiers ont une extension .kdb. Assez inutile en dehors de MQ. Peut être accédé avec ikeyman, runmqakm, runmqckm, openssl.

JKS – Java Key Store, format universel dans le monde Oracle / Java. En règle générale, une application Java ne prend en charge que les magasins de clés / de confiance au format JKS. MQ Explore, par exemple, est basé sur Eclipse, une application Java prenant uniquement en charge JKS. Les fichiers ont des extensions .jks. Peut être consulté avec ikeyman, runmqckm, openssl, keytool.

PKCS # 12 – un standard introduit qui vise à être un anneau pour les gouverner tous. L'assistance varie d'un fournisseur à l'autre. Parfois pris en charge par les applications Java. Les fichiers contenant des certificats PKCS # 12 ont une extension .p12. Peut être consulté avec ikeyman, runmqakm, runmqckm, openssl.

Nous avons maintenant terminé la terminologie et sommes prêts à commencer à travailler sur nos magasins.

Étapes techniques

Ces étapes ont été testées sur MQ v8 et v9

Lancez l'outil Ikeyman et sélectionnez l'option "créer un nouveau fichier de base de données de clés" .

Ensuite, sélectionnez le type de clé. stockez vous allez créer. Cela dépendra de ce dont vous avez besoin. L'avantage est que vous pouvez demander un certificat pour un seul d'entre eux, puis copier ce certificat dans d'autres magasins de clés.

• Classic MQ ne prend en charge que le type CMS. Nous sélectionnons CMS pour «type de base de données clé», le nom de fichier par tradition est «key.kdb».
• L’interface Web sécurisée IIB et ses nombreuses autres connexions nécessitent le type JKS, donc choisissez JKS pour «type de base de données clé». Le nom de fichier peut être «key.jks».
• Les connexions de base de données sécurisées IIB (dans odbc.ini) nécessitent le type PKCS # 12, choisissez donc PKCS12 pour «type de base de données». Le nom du fichier peut être «key.p12».

Choisissez un emplacement pour stocker le fichier dans lequel vous pourrez le trouver facilement.

Remplissez le champ mot de passe avec le mot de passe créé avec la commande runmqakm ci-dessus. Si vous cochez la case "mot de passe caché dans un fichier", un fichier caché sera créé et vous pourrez accéder au fichier au niveau du système de fichiers sans saisir le mot de passe.

[Entrée

Vous pouvez également exécuter une commande pour créer un magasin de clés:

runmqckm -keydb -create -db /var/mqm/qmgrs/QM1/ssl/key.kdb -pw mot_de_passe –Stash

La dernière option utilisée (–stash) stocke le mot de passe dans un fichier au même emplacement que le magasin de clés créé. Si vous souhaitez accéder à votre magasin de clés ultérieurement, par exemple, pour lister les certificats à l'intérieur, vous pouvez taper l'option –stashed à la place du mot de passe et la commande prendra le mot de passe de ce fichier. Exemple:

runmqakm -cert -list -db /var/mqm/qmgrs/QM1/ssl/key.kdb –stashed

Vous pouvez également placer le magasin de clés sur le emplacement du disque partagé si vous configurez TLS pour les gestionnaires de files d'attente multi-instance.

La création de magasins de confiance est similaire.

• MQ n'utilise pas de magasin de confiance.
• IIB a besoin d'un Magasin de clés JKS et magasin de clés PKCS12. Choisissez «créer un nouveau fichier de base de données de clés» dans le menu ci-dessus, choisissez le type approprié dans le menu déroulant et entrez un nom. Les noms pourraient être "trust.jks" et "trust.p12". Vous devez les stocker dans les magasins de clés correspondants.

Restez à l’écoute

Dans le prochain message, nous parlerons de la création d’une demande de certificat, de sa soumission à l’autorité de certification, de la réception d’un certificat et de son installation dans vos magasins de clés, puis magasins de confiance.