Skip to main content

SSL / Determining whether SSL connections have been set up

SSL / Determining whether SSL connections have been set up
==========================================================


This section deals with determining whether SSL connections have been set up for WebSphere® MQ.

For channel definitions see the section "Checking whether channel definitions have been SSL-enabled".
For channels set up using client application MQCONNX calls, see the section "Checking whether client-connection channels set up using MQCONNX calls have been SSL-enabled".
Checking whether channel definitions have been SSL-enabled
For each queue manager on the computer you are working with, you must check whether any channels have been defined to use SSL. Display the SSLCIPH (CipherSpec) value for each channel defined on the queue manager. To do this you must have the queue manager running and have started the RUNMQSC environment. Enter DIS CHL(*) CHLTYPE SSLCIPH to display the channel details. The output should be similar to the following:

AMQ8414: Display Channel details.
CHANNEL(SYSTEM.DEF.SENDER) CHLTYPE(SDR) SSLCIPH( )
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.DEF.SERVER) CHLTYPE(SVR) SSLCIPH( )
AMQ8414: Display Channel details.
CHANNEL(TO.QM4) CHLTYPE(CLUSRCVR) SSLCIPH(RC4_MD5_EXPORT)
AMQ8414: Display Channel details.
CHANNEL(TO.QM5) CHLTYPE(CLUSSDR) SSLCIPH(RC4_MD5_EXPORT)
AMQ8414: Display Channel details.
CHANNEL(TO.QM6) CHLTYPE(SVR) SSLCIPH( )
AMQ8414: Display Channel details.
CHANNEL(TO.QM7) CHLTYPE(CLNTCONN) SSLCIPH(NULL_SHA)
AMQ8414: Display Channel details.
CHANNEL(TO.QM7) CHLTYPE(SVRCONN) SSLCIPH(NULL_SHA)

Channel definitions that have a value in the brackets after SSLCIPH are SSL channels. If there are any SSL channels the section "SSL migration steps" will apply. In the above example, the 'TO.QM4', 'TO.QM5', and both 'TO.QM7' channel definitions have a value for SSLCIPH.

Any client channel definition tables copied from another computer or accessed as a shared file on another computer will also need to be checked for SSLCIPH values. To check these values, either:

use DIS CHL(*) CHLTYPE SSLCIPH on the queue manager they were defined on
if your client is running on a system that has a local queue manager, change the MQCHLLIB and MQCHLTAB environment variables which relate to RUNMQSC to specify the directory path and filename of the relevant client channel definition table, then use the DIS CHL(*) CHLTYPE SSLCIPH command on the local queue manager. (Note: You should return the MQCHLLIB and MQCHLTAB settings to their previous values after completing this check.)

Any client-connection channel definitions that have been imported into Active Directory will also need to be checked for non-null SSLCIPH values. Display these definitions using the command setmqscp -d.



Checking whether client-connection channels set up using MQCONNX calls are SSL-enabled

For each client application that uses an MQCONNX call, search the MQCD channel definition structure for the optional SSLCipherSpec field, which provides equivalent values to SSLCIPH.

If the value of the SSLCipherSpec field is not null, the MQI channel used by the client application is an SSL channel and the section "SSL migration steps" will apply.

Comments

adsrerrapop

Popular posts from this blog

Troubleshooting Java/JMS SSL Configurations - Middleware News

 This document is intended to help diagnose WebSphere MQ V7 Java™ or JMS SSL setup errors. It lists most of the common configuration errors that can cause an SSL connection from a Java/JMS client to a queue manager to fail, and gives the course of action to resolve the problem. In each case the error can be diagnosed by a combination of the error seen in the client log - either a console output, trace file or SystemOut.log file - and the queue manager's error logs. The document is quite long, so the easiest way to find the potential error is to search for one of the errors seen in this list, then filter this list using the error from the opposite end of the channel. All cases here assume that 2-way authentication is being attempted (SSLCAUTH set to REQUIRED on the queue manager's SVRCONN channel). This is the default, and the errors are very similar for 1-way authentication (SSLCAUTH set to OPTIONAL). Symptom Instructions on collecting documentation...

IBM Websphere MQ interview Questions Part 5

MQ Series: - It is an IBM web sphere product which is evolved in 1990’s. MQ series does transportation from one point to other. It is an EAI tool (Middle ware) VERSIONS:-5.0, 5.1, 5.3, 6.0, 7.0(new version). The currently using version is 6.2 Note: – MQ series supports more than 35+ operating systems. It is platform Independent. For every OS we have different MQ series software’s. But the functionality of MQ series Default path for installing MQ series is:- C: programfiles\BM\clipse\SDK30 C: programfiles\IBM\WebsphereMQ After installation it will create a group and user. Some middleware technologies are Tibco, SAP XI. MQ series deals with two things, they are OBJECTS, SERVICES. In OBJECTS we have • QUEUES • CHANNELS • PROCESS • AUTHENTICATION • QUERY MANAGER. In SERVICES we have LISTENERS. Objects: – objects are used to handle the transactions with the help of services. QUEUE MANAGER maintains all the objects and services. QUEUE: – it is a database structure ...

Using telnet to test connectivity between IBM Websphere MQ Client and MQ server - Middleware News

You are having trouble connecting a WebSphere MQ client to a MQ server, receiving errors that you can not connect to the MQ queue manager. One of the first things to determine is if the two machines can communicate, and using the telnet tool is one way to accomplish it. Symptom Receiving errors which state that a queue manager is not found or not available. Connection errors. For example: AMQ9213, AMQ9524, AMQ9202 or AMQ9508 or MQRC =2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE. Please note, this is by no means an exclusive list of errors related to this type a problem but just a sample of some of the more common error messages and codes that might occur. Cause One possible cause is that the two machines can not communicate. May be the IP address or hostname was not properly specified by the MQ client. The port number might be incorrect. A queue manager is not running at the desired host. The queue manager could be running, but the corresponding listener is not runnin...