La connexion à WebSphere MQ 7.0 à l'aide de JMS par SSL

L'erreur que vous voyez est parce que votre fichier de clés n'a pas la signature de l'autorité de certification racine et/ou l'intermédiaire de certificats de signataire. Lorsque vous obtenez un certificat signé de retour de l'Autorité de certification, il doit être validé avant de l'ajouter au fichier de stockage des clés. Presque tout le monde pourrait avoir intercepté votre demande de signature et signé le certificat. L'étape de la validation lors de la réception assure qu'il a été signé par une autorité de certification qui vous fait confiance et non l'anonymat d'un man-in-the-middle).

La façon dont le cert s'agit de la validation par vérification de la signature de la CA à l'encontre de la clé publique de l'autorité de certification qui est dans votre KDB. Pour que le certificat de la CA doit déjà être dans la KDB, lorsque vous essayez de recevoir votre signée cert. Si l'autorité de certification utilise un intermédiaire certificat du signataire (et pour une variété de raisons commerciales, CA sera utilisation de certificats intermédiaires), alors vous devez également avoir importé l'intermédiaire cert et la racine cert. Cela forme une chaîne de certificat ou chemin d'accès du certificat de l'AC racine cert à travers toute certificats intermédiaires de votre certificat signé. Chaque chose dans la chaîne est authentifié par la chose au-dessus d'elle jusqu'à ce que vous obtenir à la racine. Votre KDB doit, l'ensemble de la chaîne et parce que chaque cert est validée par l'un au-dessus de cela, vous doit importer ces commençant par la racine et de travailler votre chemin vers le bas.

Généralement votre autorité de certification ont posté leur signataire certs sur leur site web où vous les récupérer à l'aide de SSL. Extraction de ceux-ci et de les importer et vous serez en mesure de recevoir votre signée cert.

Comme il arrive, La Sphère Journal en Ligne vient de publier un article qui vous guide à travers ce processus à l'aide de Verisign comme un exemple, et avec des captures d'écran de l'importation de la racine et intermédiaires signataire certs. L'article est à propos de Le renouvellement de WebSphere MQ Certificats mais la première partie de l'article crée un fichier kdb et une demande de signature, puis importe le CA certs et l'signé cert.

Nous allons également vous rendre à la bonne Infocenter. Merci de regarder la WMQ v7.0 Infocenter section sur À l'aide des Certificats Signés par une autorité de certification. Celui que vous cherchez à est pour le Message Broker, et franchement, l'article vous-même liée à un peu de désordre. Je vais voir à propos de la correction. Pour commencer, un peu sur la création du cert dans un kdb, il a signé, puis de l'exporter, de le supprimer et de les importer à la QMgr de la KDB est de la pure foutaise. Tout simplement de générer le CSR dans le QMgr propre fichier KDB et de recevoir l'signé cert directement à elle. C'est beaucoup plus facile et est le processus illustré dans l'article mentionné ci-dessus.

Enfin, si vous allez à t-rob.net et télécharger le WMQ le Laboratoire de Sécurité de l'IMPACT 2011 vous y trouverez un guide de laboratoire et de certains scripts. Ces certificats auto-signés, mais les scripts peuvent être facilement convertis à l'utilisation des certificats signés par une autorité de certification, puis adapté pour une utilisation dans votre WMQ réseau.

Mise à JOUR:

Répondre aux il des questions supplémentaires dans les commentaires:

Je suis réellement l'intention d'utiliser un certificat auto-signé, donc je suppose que je n'ai besoin de l'extraire et de l'ajouter au client du magasin de confiance?

Oui, c'est correct. Mais ici, c'est un problème dans le WMB Infocenter page qui a été à l'origine liées en ce qu'il vous demande de créer un cert avec l'étiquette qmgrname au lieu de ibmwebspheremqqmgrname. Le QMgr trouve sa cert fondée sur l'étiquette et il doit correspondre au format spécifié. Ainsi, lorsque vous créez votre auto-signé cert, mke assurez-vous que l'étiquette est le littéralibmwebspheremq avec le QMgr nom plié en minuscules ajouté. Si vous avez fait une cert avec la mauvaise étiquette, vous pouvez toujours exporter vers un fichier P12 et ensuite l'importer dans un nouveau KDB, avec le droit de l'étiquette.

J'ai utilisé le WMQ SSL Assistant mentionné dans la WMQ de Sécurité en Laboratoire pour créer la configuration correcte. La configuration s'est bien passé, mais quand je lance le JMS échantillon inclus avec le SSL Assistant, je reçois l'erreur MQJE001: Completion Code '2', Reason '2397', le SSL journaux indique l'erreur suivante main, received EOFException: error main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake main, SEND TLSv1 ALERT: fatal, description = handshake_failure

Il ya quelques raisons qui pourraient se produire. Plutôt que d'aller à travers eux tous, je vais vous proposer quelques techniques de diagnostic. Lorsque j'ai créé canaux SSL, j'ai toujours utiliser la procédure suivante:

1. Obtenir le canal en cours d'exécution sans SSL. Cela prouve que la principale voie de communication est de travail (port d'écoute en cours d'exécution, les ports de match, le canal de l'objet de définitions de match, etc.).
2. Si c'est la première fois que le QMgr est à l'aide de SSL, ou si la kdb a changé, assurez-vous de la question REFRESH SECURITY TYPE(SSL) commande.
3. Activer SSL en spécifiant le même ciphersuite à la QMgr et le client, mais assurez-vous que le QMgr de SVRCONN canal est réglé sur SSLCAUTH(OPTINAL) SSLPEER(). Cette opération vérifie que le client accepte la QMgr de certificat. Seulement quand cela fonctionne, passez à l'étape suivante.
4. Maintenant modifier la QMgr de SVRCONN à SSLCAUTH(REQUIRED) SSLPEER(). Cela provoque la QMgr pour demander le certificat du client.
5. Si vous utilisez SSLPEER fixé à la valeur désirée.

Ce processus isole les éventuels problèmes de telle sorte qu'à tout moment, vous savez où regarder. Si le processus échoue à l'Étape #3 alors qu'il y a un problème avec la configuration SSL de l'application, ou il ne peut valider le QMgr cert. Si le processus échoue à l'Étape 4, puis nous savons de l'application de configuration SSL est solide et qu'il aime la QMgr cert bu que de l'QMgr n'aime pas l'application cert. Si nous arrivons à l'Étape #5, alors c'est juste une question de la SSLPEER valeur correcte.

Parce que vous avez une poignée de main échec qui semble être due à la QMgr la fermeture de la connexion TCP, je suis en supposant que vous avez SSLCAUTH(REQUIRED) (qui est la valeur par défaut, par la voie) et qui soit le QMgr qui n'ont pas de demande de certificat ou de ce que vous essayez d'utiliser une connexion anonyme où le client n'a pas besoin d'un personnel cert. Si c'est le cas, le réglage de SSLCAUTH(OPTIONAL) vous obtenez au-delà de l'échec, bien qu'éventuellement à un tout nouveau point de défaillance.

OriginalL'auteur T.Rob