Impossible de se Connecter avec Websphere MQ SSL Canal via JNDI

Mon JMS client se connecte à WMQ via JNDI. Le contexte initial d'usine est utilisé com.ibm.mq.jms.context.WMQInitialContextFactory.

Actuellement, à WMQ côté, il y a un gestionnaire de file d'attente appelée TestMgr. En vertu de ce gestionnaire de file d'attente, j'ai créé deux canaux. On est PLAIN.CHL qui ne permet pas de spécifier un algorithme de Chiffrement Spec, l'autre est SSL.CHL configuré SSL Cipher Spec avec RC4_MD5_US et l'Authentification SSL avec Optional.

J'ai créé un magasin de clés pour le gestionnaire de file d'attente à l'aide d'IBM outil de Gestion Clé. Le chemin de la clé de db est [wmq_home]\qmgrs\TestMgr\ssl\key.

Pour le canal PLAIN.CHL, j'ai défini une file d'attente de connexion usine comme:

DEF QCF(PlainQCF) QMANAGER(TestMgr) CHANNEL(PLAIN.CHL) HOST(192.168.66.23) PORT(1414)   TRANSPORT(client)

Et sous le canal SSL SSL.CHL, j'ai défini une file d'attente de connexion usine comme:

DEF QCF(SSLQCF) QMANAGER(TestMgr) CHANNEL(SSL.CHL) HOST(192.168.66.23) PORT(1414) TRANSPORT(client) SSLCIPHERSUITE(SSL_RSA_WITH_RC4_128_MD5)

Maintenant, je ne peux que créer une connexion à l'aide de la PlainQCF. Mais pas le SSL connexion de file d'attente de l'usine. Mon code ressemble à ceci:

 Hashtable environment = new Hashtable();
    environment.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.mq.jms.context.WMQInitialContextFactory");
    environment.put(Context.PROVIDER_URL, "192.168.66.23:1414/SSL.CHL");
    Context ctx = new InitialContext( environment );
    QueueConnectionFactory qcf = (QueueConnectionFactory) ctx.lookup("SSLQCF");
    qcf.createConnection();
    ....

Suis-je en manquant de certaines propriétés de contexte lors de la recherche de l'SSL usine? connexion Et puis j'ai trouvé le code est suspendu sur la ligne new InitialContext( environment ) pendant une longue période, de près de 5 minutes et je suis CC=2;RC=2009;AMQ9208... erreur.

Toute suggestion serait la bienvenue. Est-il vrai que canal SSL ne peut pas être relié par JNDI?

@T. Rob, merci pour votre réponse très bien. Mais nous voulons encore utiliser WMQInitialContextFactory, donc j'ai peur, j'ai encore besoin de trouver une solution pour ce.

J'ai défini la fabrique de connexion une fois. De l'affichage de l'info pour le SSL connexion de file d'attente de l'usine comme:

InitCtx> DISPLAY QCF(SSLQCF)
ASYNCEXCEPTION(ALL)
CCSID(819)
CHANNEL(SSL.CHL)
CLIENTRECONNECTOPTIONS(ASDEF)
CLIENTRECONNECTTIMEOUT(1800)
COMPHDR(NONE )
COMPMSG(NONE )
CONNECTIONNAMELIST(192.168.66.23(1414))
CONNOPT(STANDARD)
FAILIFQUIESCE(YES)
HOSTNAME(192.168.66.23)
LOCALADDRESS()
MAPNAMESTYLE(STANDARD)
MSGBATCHSZ(10)
MSGRETENTION(YES)
POLLINGINT(5000)
PORT(1414)
PROVIDERVERSION(UNSPECIFIED)
QMANAGER(TestMgr)
RESCANINT(5000)
SENDCHECKCOUNT(0)
SHARECONVALLOWED(YES)
SSLCIPHERSUITE(SSL_RSA_WITH_RC4_128_MD5)
SSLFIPSREQUIRED(NO)
SSLRESETCOUNT(0)
SYNCPOINTALLGETS(NO)
TARGCLIENTMATCHING(YES)
TEMPMODEL(SYSTEM.DEFAULT.MODEL.QUEUE)
TEMPQPREFIX()
TRANSPORT(CLIENT)
USECONNPOOLING(YES)
VERSION(7)
WILDCARDFORMAT(TOPIC_ONLY)

JNDI Fournisseur devrait être bien parce que j'ai peut rechercher de la plaine de l'usine de raccordement avec succès. Aussi, pour mon client app, j'ai extrait le cert de la clé de stockage qui a créé pour MQ server et importé à la banque de confiance(le fichier cacerts) de mon JRE avec le nom de l'alias ibmwebspheremqtestmgr.

Vous sont corrects, avec erreur de 2009 il y a quelques entrées de journal:

=================================================================

4/20/2012 20:24:27 - Process(13768.3) User(MUSR_MQADMIN) Program(amqzmur0.exe)
                      Host(xxxx_host of my MQ) Installation(mqenv)
                      VRMF(7.1.0.0) QMgr(TestMgr)                
AMQ6287: WebSphere MQ V7.1.0.0 (p000-L111019).
EXPLANATION:
WebSphere MQ system information: 
Host Info         :- Windows Server 2003, Build 3790: SP2 (MQ Windows 32-bit) 
Installation      :- C:\IBM\WebSphereMQ (mqenv) 
Version           :- 7.1.0.0 (p000-L111019)
ACTION:
None. 

-------------------------------------------------------------------------------
4/20/2012 20:24:27 - Process(7348.116) User(MUSR_MQADMIN) Program(amqrmppa.exe)
                      Host(xxxx_host of my MQ) Installation(mqenv)
                      VRMF(7.1.0.0) QMgr(TestMgr)
AMQ9639: Remote channel 'SSL.CHL' did not specify a CipherSpec.

EXPLANATION:
Remote channel 'SSL.CHL' did not specify a CipherSpec when the local channel
expected one to be specified. 

The remote host is 'xxx_host of my app (192.168.66.25)'. 
The channel did not start.

ACTION:
Change the remote channel 'SSL.CHL' on host 'xxx_host of my app (192.168.66.25)' to
specify a CipherSpec so that both ends of the channel have matching
CipherSpecs.

----- amqcccxa.c : 3817 -------------------------------------------------------
4/20/2012 20:24:27 - Process(7348.116) User(MUSR_MQADMIN) Program(amqrmppa.exe)
                      Host(my app host) Installation(mqenv)
                    VRMF(7.1.0.0) QMgr(TestMgr)                    
AMQ9999: Channel 'SSL.CHL' to host 'xxx_host of my app (192.168.66.25)' ended
abnormally.

====================================================================

J'ai aussi eu une certaine confusion avec le journal des erreurs. Mon application est mise en scène à une machine qui est différent de mon MQ. Mais le journal dit que le Change the remote channel 'SSL.CHL' on host 'xxx_host of my app (192.168.66.25)' to specify a CipherSpec so that both ends of the channel have matching CipherSpecs. Comment puis-je changer le canal cipher spec sur mon application hôte?

mises à jour sur MQEnvironment...

répondre aux commentaires.

La valeur de MQEnvironment.sslCipherSuite est nulle, de sorte qu'il jette NullPointerExcetpion quand je l'ai mis à l'env de table de hachage. Mais j'ai essayé un autre environment.put(MQC.SSL_CIPHER_SUITE_PROPERTY, "SSL_RSA_WITH_RC4_128_MD5") et elle n'a toujours pas avec 2009 erreur.

Pour JMSAdmin outil, j'avais changé la config à utiliser WMQInitialContextFactory. La configuration comme celle-ci(JMSAdmin.config):

INITIAL_CONTEXT_FACTORY=com.ibm.mq.jms.context.WMQInitialContextFactory
PROVIDER_URL=192.168.66.23:1414/SYSTEM.DEF.SVRCONN

Le reste de la configuration des feuilles en tant que par défaut.

Veuillez noter, ici, j'utilise le canal par défaut SYSTEM.DEF.SVRCONN afin que je puisse connexion à la console d'administration. Si je change le canal SSL unSSL.CHL, je ne peux pas de connexion à l'admin console. L'erreur qui s'est passé ici est le même que dans mon application client.

Une autre précision, dans mon client, j'utilise le code ci-dessous peut se connecter à connecter qmgr(TestMgr) avec succès à travers le canal SSL.CHL.

   MQConnectionFactory factory = new MQConnectionFactory();
    factory.setTransportType(JMSC.MQJMS_TP_CLIENT_MQ_TCPIP);
    factory.setQueueManager("TestMgr");
    factory.setSSLCipherSuite("SSL_RSA_WITH_RC4_128_MD5");
    factory.setPort(1414);
    factory.setHostName("192.168.66.23");
    factory.setChannel("SSL.CHL");

    MQConnection connection = (MQConnection) factory.createConnection();

Et maintenant le problème est juste comme vous l'avez dit, c'est le contexte initial a échoué connecter à qmgr par canal SSL. L'option(use plain channel for initial context and ssl channel for connection factory) que vous avez fourni fonctionne aussi. Mais je veux toujours savoir comment obtenir contexte initial avec canal ssl travail. Merci pour votre patience et beaucoup. Vos mises à jour seront appréciées.

grâce

bonjour, voir ma réponse ci-dessous.
La seule chose qui manque dans votre mise à jour de la configuration de l'WMQ Contexte Initial. Votre QCF est clairement un cipherspec donc, si elle avait été utilisée et ne correspond pas à la QMgr de réglage que vous voyez une erreur différente. L'erreur que vous voyez m'amène à croire que le WMQ Initiale Contect est aussi de tenter de frapper SSL.LCH. Vous pouvez poster ces paramètres de configuration?
Oh, je pensais que le WMQ Contexte Initial est construit en WMQ naturellement et l'utilisateur n'a pas besoin de configurer ce Contexte Initial de plus. Il semble que j'avais tort. Je vais essayer de le configurer. Si possible, pouvez-vous m'indiquer comment configurer WMQ Contexte Initial?
Mise à jour de réponse ci-dessous. En bref, le WMQInitialContextFactory est configuré pour utiliser le canal SSL mais qui n'ont pas la configuration SSL. Vous aurez besoin d'utiliser la norme env vars pour définir la ciphersuite et l'emplacement du fichier de stockage des clés. Les détails ci-dessous.
Merci pour votre mise à jour. Je comprends beaucoup pour votre réponse. Veuillez voir ma mise à jour "mises à jour sur MQEnvironment" suivi dans ma question.
Salut, tout d'autres idées sur l'utilisation de ssl pour le contexte initial de l'usine?

InformationsquelleAutor zgcharley | 2012-04-20

1

Je n'ai jamais vraiment aimé com.ibm.mq.jms.context.WMQInitialContextFactory très bien. Il stocke les objets gérés dans une file d'attente. Alors, pour la recherche de la connectionFactory, qui raconte JMS comment se connecter à la QMgr, il est d'abord nécessaire pour se connecter à la QMgr pour faire de la JNDI appel. Par conséquent, avant de vous pouvez déboguer la connexion SSL, vous devez savoir si le sous-jacent JNDI fournisseur de travail.

Si vous souhaitez ignorer la MQ à base de JNDI fournisseur et il suffit d'utiliser le système de fichiers, consultez la mise à jour de la version de Bobby Woolf article ici. Si vous souhaitez continuer avec com.ibm.mq.jms.context.WMQInitialContextFactory, lire la suite mais être prêt à fournir plus d'informations de configuration.

Lorsque vous exécutez le JMSAdmin outil, avez-vous afficher les objets après leur création? Pour exemple, voici l'un de mes JMSAdmin.bat scripts:
```
# Connection Factory for Client mode
# Delete the Connection Factory if it exists
DELETE  CF(JMSDEMOCF)

# Define the Connection Factory
DEFINE  CF(JMSDEMOCF) +
        SYNCPOINTALLGETS(YES) +
        SSLCIPHERSUITE(NULL_SHA) +
        TRAN(client) +
        HOST(127.0.0.1) CHAN(SSL.SVRCONN) PORT(1414) +
        QMGR( )

# Display the resulting definition
DISPLAY CF(JMSDEMOCF)
```
Cela supprime l'objet (parce que JMSAdmin n'ont pas de définir avec remplacer option) qui définit l'objet, puis l'affiche. Ne vous en fait voir à la fois les objets définis? Pouvez-vous vous connecter de manière interactive les afficher à la fois? Pouvez-vous mettre à jour votre question avec le contenu affiché?

Si oui, alors quel est le JNDI de la configuration du fournisseur ressemble avec chaque exemple de programme? L'2009 indique qu'il y a au moins une connexion à la QMgr, et il est important de déterminer si la chose que la souffrance, l'échec de connexion est votre application ou de votre JNDI fournisseur. Pour diagnostiquer que nécessite l'info de config que vous utilisez pour le JNDI fournisseur et si c'est le même dans le travail et, à défaut d'affaires. Si non, comment sont-ils différents?

Une fois que vous savez si c'est l'application ou de la JNDI fournisseur qui est à l'origine du problème (ou de passer à un autre JNDI fournisseur qui ne nécessite pas un MQ de connexion telles que le système de fichiers contexte initial), alors il sera possible de déterminer les prochaines étapes.

La article lié ci-dessus présente des exemples de code et des objets gérés des scripts qui utilisent un système de fichier JNDI fournisseur. Vous remarquerez peut-être mes scripts collé ci-dessus utilisent le même QMgr nom. C'est parce que j'ai écrit cette partie de l'article. Quand je veux passer en SSL à l'aide de ces mêmes échantillons, je viens de mettre à jour le connectionFactory pour pointer vers le canal SSL et il fonctionne.

Voici les autres bits à partir de l'exemple que j'ai modifié:
```
java -Djavax.net.debug=ssl  ^
     -Djavax.net.ssl.trustStore=key2.jks  ^
     -Djavax.net.ssl.keyStore=key2.jks ^
     -Djavax.net.ssl.keyStorePassword=????????  ^
     -Djavax.net.ssl.trustStorePassword=???????? ^
     -cp "%CLASSPATH%"  ^
      com.ibm.examples.JMSDemo -pub -topic JMSDEMOPubTopic %*
```
Remarque: Le ^ est la version Windows de continuation de ligne.

Alors si il y a des problèmes, j'ai suivi le débogage scénario que j'ai décrit dans cette SORTE de réponse. Notez que l'application aura besoin d'un truststore, même si vous avez SSLCAUTH(OPTIONAL) sur votre chaîne. C'est parce que l'application doit toujours valider les QMgr du certificat, même si l'application ne présente pas de son propre certificat. Dans mon cas, j'ai été en utilisant SSLCAUTH(REQUIRED) donc mon application nécessaires à la fois un magasin de clés et un truststore. Votre question mentionne que le QMgr a un magasin de clés, mais ne dites pas ce que vous avez fait pour l'application.

Enfin, en 2009, un va générer une entrée dans le QMgr les journaux d'erreurs. Si vous continuez à obtenir le problème, veuillez mettre à jour votre question avec ceux des entrées de journal.

Mise à JOUR:

Répondant aux observations, le JMSAdmin outil fait partie de la WMQ paquet. Cependant, WMQ il est livré avec des pots pour le système de fichier de contexte et LDAP contexte. Le WMQInitialContextFactory est facultatif et est livré comme SupportPac ME01. Lors de l'utilisation de WMQInitialContextFactory avec le JMSAdmin outil (ou le JMSAdmin GUI ou WMQ Explorer), il est nécessaire de configurer le PROVIDER_URL avec l'hôte, le port et le canal. Par exemple:
```
PROVIDER_URL: <Hostname>:<port>/<SVRCONN Channel Name>
192.168.66.23:1414/SSL.SVRCONN
```
Donc après examen de votre poste de nouveau, j'ai réalisé que vous ne fournir l'info de config pour WMQInitialContextFactory. Je cherchais un JMSADmin.fichier de config, mais vous l'avez dans l'environnement de la table de hachage. Et c'est où est le problème. Vous tentez d'utiliser le canal SSL pour le WMQInitialContextFactory et l'usine de raccordement. C'est ce qui est à l'origine de la recherche à l'échec. Le WMQInitialContextFactory fait d'abord une Java connexion à la QMgre afin de regarder dans la file d'attente pour obtenir des administrés, des objets tels que des QCF. Pour ce faire, il a besoin de savoir la ciphersuite que le canal est mis en place dans le but de négocier la poignée de main. Maintenant, le *seul * lieu que ciphersuite sont enregistrées dans le QCF définition.

Essayez d'ajouter la ligne suivante:
```
environment.put(MQEnvironment.sslCipherSuite, "SSL_RSA_WITH_RC4_128_MD5");
```
Comme par cette page Infocenter, que devrait dire le contexte de classes usine, ce qui ciphersuite à utiliser. Bien sûr, ils ont aussi besoin de savoir où le trust store est (et, éventuellement, de magasin de clés, si le canal a SSLCAUTH(RQUIRED) set) si vous avez encore besoin pour obtenir ces valeurs dans l'environnement. Vous pouvez utiliser la ligne de commande de variables ou d'essayer de les charger dans l'environnement à l'aide de code. Vous aurez besoin des deux -Djavax.net.ssl.trustStore=key2.jks et -Djavax.net.ssl.trustStorePassword=????????.

L'autre option est de continuer à utiliser le texte en clair de canal pour la WMQInitialContextFactory et le canal SSL pour l'application. Si le texte clair de canal a un MCAUSER pour un utilisateur non privilégié ID, il peut être limité à uniquement se connecter à la QMgr et accéder à la file d'attente qui contient les administrés des objets. Avec ces restrictions, n'importe qui sera capable de lire les administrés objets à l'aide de ce canal, mais pas l'application des files d'attente ou administratives, les files d'attente.

InformationsquelleAutor T.Rob

Vous devez vous connecter pour publier un commentaire.