Configuring Secure Sockets Layer connectivity in WebSphere MQ File Transfer Edition

WebSphere MQ File Transfer Edition (FTE) provides a reliable, auditable, and managed file transfer solution for moving files, regardless of their size, between IT systems without the need for programming. This article describes a three queue manager scenario for setting up Secure Sockets Layer (SSL) with WebSphere MQ FTE.

Share:

Alex Fehners (fehners@uk.ibm.com), Software Developer, IBM

Alex Fehners is a Software Developer in Application and Integration Middleware at the IBM Hursley Park Software Lab in the UK. You can contact Alex at fehners@uk.ibm.com.



Laurence Bonney (bonneyl@uk.ibm.com), Software Engineer, IBM

Laurence Bonney is a Software Engineer with eight years experience working at the IBM Hursley Development Lab in the UK. He works on the WebSphere MQ and WebSphere MQ File Transfer Edition Development Team. You can contact Laurence at bonneyl@uk.ibm.com.


developerWorks Contributing author
        level

13 January 2010

Also available in Chinese Russian Spanish

Introduction

This article shows you how to configure Secure Sockets Layer (SSL) connections from an IBM® WebSphere® MQ File Transfer Edition (WMQFTE) agent. It also explains the WMQFTE commands and the WMQFTE Plug-in for MQ Explorer, and how to connect over TCP/IP to three separate WebSphere MQ queue managers representing an Agent queue manager, a Command queue manager, and a Coordination queue manager. The article shows you how to create test certificates and configure a queue manager to create a secure server connection channel (SVRCONN) with MQ FTE. The article does not cover the SSL inter-queue manager connections between the three queue managers.

The scenario has been developed using WMQFTE V7.0.2 with WebSphere MQ V7.0.1 on Microsoft® Windows®. You should have enough experience with WebSphere MQ to configure a three queue manager network with WMQFTE without SSL as a starting point. While this configuration is not described in the article, you can easily adapt the scenario to a single queue manager configuration by substituting any reference to the Command, Coordination, and Agent queue managers with your single queue manager providing the function of all three queue manager types in one. Screenshots of both the graphical IBM Key Management tool / MQ Explorer, and command-line examples, are provided where appropriate.

Interaction between queue managers and WMQFTE components

SSL configuration for WMQFTE is performed through configuration properties within one or more of the three types of property files found in your WMQFTE configuration directory hierarchy: agent.properties, command.properties, and coordination.properties. The SSL configuration for any scenario within WMQFTE depends on the underlying queue managers to which you are connecting. In many cases, you may have a scenario where your agents need to connect only to their Agent queue manager via SSL, while other more complex scenarios may require, for example, SSL connections to the Coordination queue manager. An understanding of the queue manager iterations between each of the WMQFTE commands, the WMQFTE Plug-in for MQ Explorer, and the Agents is required to configure your WMQFTE topology to suit your business needs.

There are some common misunderstanding regarding these WMQFTE to queue manager interactions. For example, some users believe that the command fteListAgents requires a connection to the Command queue manager to perform its operation. But the function of this command is to retrieve agent information within your WMQFTE network, and as the Agent information as a whole is stored on the Coordination queue manager, this command only needs to connect to the Coordination queue manager. Therefore if this command is required to connect over an SSL connection, the coordination.properties file SSL configuration is required. Other commands though, such as fteCreateTransfer, do directly connect to the Command queue manager. Table 1 below shows the queue manager connection between the a number of WMQFTE commands, the MQ Explorer WMQFTE Plug-in, and agents. For more information on this topic, see Which WebSphere MQ FTE commands connect to which queue manager in the WMQFTE information center.

Table 1. Connection of WMQFTE entities to queue manager types
WMQFTE EntityAgent queue managerCommand queue managerCoordination queue manager
fteCreateTransferX
fteStartAgent (the Agent itself)X
fteStopAgentX
fteListAgentsX
WebSphere MQ File Transfer Edition Plug-in for WebSphere MQ ExplorerXX

In each case where a queue manager type is referenced, you must configure SSL in the corresponding WMQFTE properties file to enable that type of WMQFTE entity to connect to its queue manager. As an example from the table above, the MQ Explorer WMQFTE Plug-in requires iteration with both the Coordination queue manager and the Command queue manager to operate, because the plug-in submits commands to the Command queue manager (creating transfers), and requests information from the Coordination queue manager (transfer progress). If both Coordination queue manager and Command queue manager need to be configured with SSL enabled connections, then both the commands.properties and coordination.properties files require WMQFTE SSL configuration information in them to allow operation of the plug-in.

Of course you can just enable SSL on all of your queue managers and put the SSL configuration information in all of your WMQFTE properties files, if SSL is required throughout your topology. For simplicity's sake, the example scenario will be configured in this manner.

WMQFTE SSL example

As mentioned earlier, this example shows you how to configure SSL for the three queue managers -- AgentQmgr, CommandQmgr, and CoordinationQmgr -- and the WMQFTE agent AGENT1, using self signed certificates.

  1. Creating a client-side truststore to be used for the agent, the WMQFTE commands, and the MQ Explorer Plug-in.
  2. Creating queue manager certificate stores
  3. Creating queue manager self-signed certificates
  4. Adding certificates to the client-side truststore
  5. Configuring the WMQFTE properties files
  6. Configuring the queue managers
  7. Creating and configuring the client-side keystore to be used for client authentication (optional)
  8. Testing the configuration

All steps except for Step 7 are required to configure the basic SSL connections. Do Step 7 only if you want to configure client authentication. To reduce complexity and simplify debugging, you should not use client authentication initially. After you have a basic SSL connection configured and working as expected, you can add client authentication. You will test whether these four WMQFTE entities can connect to their respective queue managers:

  • WMQFTE Plug-in for MQ Explorer
  • Test agent AGENT1
  • WMQFTE commands fteCreateTransfer and fteListAgents

Creating a client-side truststore

The truststore holds the certificate of a signing certificate authority (CA) for a queue manager you trust. What this means in terms of WMQFTE is that when a connection is made to a queue manager, it sends its certificate to WMQFTE as part of the initial SSL handshake. The Java Secure Socket Extension (JSSE), which handles all SSL communication, looks in the truststore to validate the certificate that it has just received. If it cannot validate the certificate, the connection is terminated. To create a truststore, use the IBM Key Management tool, which is part of WebSphere MQ V7. You can also use the keytool program packaged with the WMQFTE Java installation.

  • In the start bar, select Programs => IBM WebSphere MQ => IBM Key Management.
  • When IBM Key Management starts, click New and set the values shown in Figure 1 below:
    • Key database type: JKS
    • File name: truststore.jks
    • Location: C:\WMQFTE_SSL\
  • Click OK to continue.
  • You will be prompted to enter a password of your choice. The password is required to open the truststore only if you wish to add certificates to it. The JSSE does not require a password if it is only being used as a truststore. For this example, enter a password.
  • Click OK to continue. You should now have a truststore to which you can import certificates of trusted CAs.

On the command line, you can enter runmqckm for Windows or gsk7cmd for Unix to achieve the same outcome, as shown in Listing 1:

Listing 1. Creating a truststore
runmqckm -keydb -create -db C:\WMQFTE_SSL\truststore.jks -pw password 
-type jks
Figure 1. Creating a truststore
Creating a truststore

Creating queue manager certificate stores

In a non-client authentication scenario, the queue manager certificate store acts in the same way as any keystore, in that it holds the client's personal certificates. When configuring the additional client authentication, the queue manager certificate store acts as a truststore as well as a keystore. Since you are using self-signed certificates for this scenario, our personal certificate and CA are one and the same thing, so by implication our queue manager certificate stores can act as both keystore and truststore.

The key.kdb file

You can call the queue manager certificate store kdb file whatever you like, as long as the extension is .kdb. The default name the queue manager uses is key.kdb, so you will have to update the SSLKEYR property of the queue manager (using either runmqsc or MQ Explorer) to reflect the value you choose.

In the three queue manager scenario, you need to create a queue manager certificate store for each of the queue managers. As with the previous step, you can use the IBM Key Management tool to create a certificate store:

  • Open the IBM Key Management tool.
  • Click New and set the following values, as shown in Figure 2 below.
    • Key database type: CMS
    • File name: key.kdb
    • Location: C:\Program Files\IBM\WebSphere MQ\Qmgrs\AgentQmgr\ssl\
  • Click OK to continue.
  • You will be prompted to enter a password of your choice. Do so, and select Stash the password to a file.
  • Click OK to continue. You should now have your first of three queue manager certificate stores.
  • Repeat the steps for CommandQmgr and CoordinationQmgr to create all three queue manager certificate stores

On the command-line, you can enter runmqckm for Windows or gsk7cmd for Unix to achieve the same outcome, as shown in Listing 2:

Listing 2. Creating queue manager Keystore
runmqckm -keydb -create -db C:\Progra~1\IBM\Websph~1\qmgrs\AgentQmgr\ssl\key.kdb 
-pw password -type cms -expire 365 -stash
Figure 2. Creating a queue manager certificate store
Creating a queue manager certificate store

Creating queue manager self-signed certificates

Key label value of a self-signed certificate

This value must be in the form <ibmwebspheremq<qmname lowercase>>. So in this case it would be one of the following:

  • ibmwebspheremqagentqmgr
  • ibmwebspheremqcommandqmgr
  • ibmwebspheremqcoordination

Create three self-signed certificates, one for each queue manager. To save additional complication, create each self-signed certificate in the queue manager certificate store to which the certificate relates. Again, you can use the IBM Key Management tool:

  • Open the IBM Key Management tool.
  • Click Open to open the AgentQmgr certificate store.
  • Click Create=>New Self-Signed Certificate and set the following values, as shown in Figure 3:
    • Key label: ibmwebspheremqagentqmgr
    • Common Name: <Owner name or machine name> (choose an appropriate value)
  • Click OK to continue.
  • You now should have a personal certificate listed as * ibmwebspheremqagentqmgr. Click Extract certificate to extract the self-signed certificate to a file to import it into the WMQFTE client-side truststore later. Set the following values, as shown in Figure 4 below:
    • Data type: Binary DER data
    • Certificate file name: AgentQmgr.der
    • Location: C:\WMQFTE_SSL\
  • Click OK to continue. You should now have your first of three self-signed certificates.
  • Repeat the steps for CommandQmgr and CoordinationQmgr to create all three self-signed certificates.

Short-cut to creating the certificate store and self-signed certificates

To save time, there is no technical reason to not create a single queue manager certificate store, create all the certificates in that single certificate store, and then just copy the files held in your queue manager ssl directory to each of your remaining queue managers, thus using the same store for each. The downside is that you would have self-signed certificates within your queue manager certificate store, and all certificate stores would be using the same password, but for testing and demonstration purposes this doesn't really matter.

On the command-line, you can enter runmqckm for Windows or gsk7cmd for Unix to achieve the same outcome, as shown in Listing 3:

Listing 3. Creating and extracting self-signed certificate
runmqckm -cert -create -db C:\Progra~1\IBM\Websph~1\qmgrs\AgentQmgr\ssl\key.kdb 
-pw password -label ibmwebspheremqagentqmgr -dn CN=FTEUser -size 1024 
-x509version 3 -expire 365

runmqckm -cert -extract -db C:\Progra~1\IBM\Websph~1\qmgrs\AgentQmgr\ssl\key.kdb 
-pw password -label ibmwebspheremqagentqmgr -target C:\WMQFTE_SSL\AgentQmgr.der 
-format binary
Figure 3. Creating a self-signed certificate
Creating a self-signed certificate
Figure 4. Extracting a self-signed certificate
Extracting a self-signed certificate

Adding certificates to the client-side truststore

Now that you have extracted the three self-signed certificates (AgentQmgr.der, CommandQmgr.der, and CoordinationQmgr.der), you need to add them to the WMQFTE client-side truststore. Whilst client authentication is not set, the self-signed certificate you add to the trust store will be acting like CAs. Again you can do this with the IBM Key Management tool.

  • Open the IBM Key Management tool.
  • Click Open and open the WMQFTE Client truststore C:\WMQFTE_SSL\truststore.jks. When prompted, type the password you entered previously.
  • Select the drop-down box under the label Key database content.
  • Select Signer Certificates.
  • Click Add. You will be prompted for the location of the certificate you wish to add. This certificate will either be the queue managers certificate if you are using self-signed certificates for testing, or the certificate of the CA that issued your queue managers certificate. This example uses the self signed certificates. Enter the following data, as shown in Figure 5 below:
    • Data type: Binary DER data
    • Certificate file name: AgentQmgr.der
    • Location: C:\WMQFTE_SSL\
  • Click OK. You will be prompted for a label. Enter ibmwebspheremqagentqmgr.
  • Click OK to add the certificate.
  • Repeat the steps for CommandQmgr and CoordinationQmgr to add all three queue manager signed certificates.

On the command-line, you can enter runmqckm for Windows or gsk7cmd for Unix to achieve the same outcome, as shown in Listing 4:

Listing 4. Adding a self-signed certificate to the WMQFTE truststore
runmqckm -cert -add -db C:\WMQFTE_SSL\truststore.jks -pw password -type jks 
-label ibmwebspheremqagentqmgr -file C:\WMQFTE_SSL\AgentQmgr.der -format binary 
-trust enable
Figure 5. Adding a self-signed certificate to the WMQFTE truststore
Adding a self-signed certificate to the WMQFTE truststore

Configuring the WMQFTE properties files

As you will be validating the WMQFTE SSL configuration using a selection of the available WMQFTE entities, referring back to Table 1, you can see that all three queue manager types will be directly connected to by these entities. Therefore you must add SSL configuration information to all three properties files:

For any of the WMQFTE entities to pick up changes to these properties files, they must be restarted. However at this state you have not completed the basic configuration so startup is likely to fail with SSL configuration issues.

agentSslCipherSuite vs. agentSslCipherSpec and other agent SSL properties

This example uses the agentSslCipherSpec. For consistency with other MQ Java Clients, you can also use the agentSslCipherSuite property. In general, specifying a CipherSpec is easier because you just need to match the value set on your MQ Server Connection channel. If you want to specify CipherSuite rather than a CipherSuite, see the table in Section 4 of the article SSL configuration of the WebSphere MQ Java/JMS client. If both types are specified in the agent.properties file, the agentSslCipherSpec takes precedence over agentSslCipherSuite. As of WMQFTE V7.0.2, other SSL configuration properties available for the Agent are:

For the the latest SSL properties available to WMQFTE, see the WMQFTE information center.

Configuring the agent.properties file

The agent.properties file is located in the root of your agent data directory and is used for configuring all aspects of the agent's behaviour. To enable SSL in this scenario, add or modify the following values:

  • agentQMgrChannel=SYSTEM.SSL.SVRCONN
  • agentSslCipherSpec=RC4_MD5_EXPORT
  • agentSslTrustStore=C:\\WMQFTE_SSL\\truststore.jks
  • agentSslTrustStorePassword=Password you chose above in Creating a client-side truststore.

For the agent properties file, you can use RC4_MD5_EXPORT as the SSL Cipher Suite, but you can use any supported value as long as it matches what you selected on the corresponding Server Connection channel on your Agent queue manager.

Configuring the coordination.properties file

The coordination.properties file is located under the Coordination queue manager directory under the root data directory. To enable SSL in this scenario, add or modify the following values:

  • coordinationQMgrChannel=SYSTEM.SSL.SVRCONN
  • coordinationSslCipherSpec=DES_SHA_EXPORT
  • coordinationSslTrustStore=C:\\WMQFTE_SSL\\truststore.jks
  • coordinationSslTrustStorePassword=Password you chose above in Creating a client-side truststore.

For the coordination properties file, you can use DES_SHA_EXPORT as the SSL Cipher Suite, and as with the agent.properties file, you can use any supported value as long as it matches what you selected on the corresponding Server Connection channel on your Coordination queue manager.

Security consideration using plain text passwords in the properties files

Truststore and keystore passwords are stored in the three WMQFTE property files in plain text. You need to restrict who can read these files using methods available on your operating system. These passwords are obscured in the Agent's output log file, and within WMQFTE trace files.

Configuring the command.properties file

The command.properties file is located under the Coordination queue manager directory under the root data directory. To enable SSL in this scenario, add or modify the following values:

  • connectionQMgrChannel=SYSTEM.SSL.SVRCONN
  • connectionSslCipherSpec=TRIPLE_DES_SHA_US
  • connectionSslTrustStore=C:\\WMQFTE_SSL\\truststore.jks
  • connectionSslTrustStorePassword=Password you chose above in Creating a client-side truststore.

For the command properties file, you can use TRIPLE_DES_SHA_US as the SSL Cipher Suite, and as with the previous properties files, you can use any supported value as long as it matches what you selected on the corresponding Server Connection channel on your Command queue manager.

Configuring the queue managers

Queue manager configuration in this example is minimal. It uses a new Server Connection channel on each of the three queue managers named SYTEM.SSL.SVRCONN, which you can create either through MQ Explorer or runmqsc:

Figure 6. Defining your SSL Server Connection
Defining your SSL Server Connection
Listing 5. Defining AgentQmgr SVRCONN Channel in runmqsc
C:\WMQFTE_SSL>runmqsc AgentQmgr
5724-H72 (C) Copyright IBM Corp. 1994, 2009.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager AgentQmgr.

DEFINE CHANNEL(SYSTEM.SSL.SVRCONN) CHLTYPE(SVRCONN) SSLCIPH(RC4_MD5_EXPORT) 
SSLCAUTH(OPTIONAL)
    2 : DEFINE CHANNEL(SYSTEM.SSL.SVRCONN) CHLTYPE(SVRCONN) SSLCIPH(RC4_MD5_EXPORT)
SSLCAUTH(OPTIONAL)
AMQ8014: WebSphere MQ channel created.
DISPLAY CHANNEL(SYSTEM.SSL.SVRCONN)
    3 : DISPLAY CHANNEL(SYSTEM.SSL.SVRCONN)
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.SSL.SVRCONN)             CHLTYPE(SVRCONN)
ALTDATE(2009-11-19)                     ALTTIME(13.01.25)
COMPHDR(NONE)                           COMPMSG(NONE)
DESCR( )                                HBINT(300)
KAINT(AUTO)                             MAXINST(999999999)
MAXINSTC(999999999)                     MAXMSGL(4194304)
MCAUSER( )                              MONCHL(QMGR)
RCVDATA( )                              RCVEXIT( )
SCYDATA( )                              SCYEXIT( )
SENDDATA( )                             SENDEXIT( )
SHARECNV(10)                            SSLCAUTH(OPTIONAL)
SSLCIPH(RC4_MD5_EXPORT)                 SSLPEER( )
TRPTYPE(TCP)

Repeat for CommandQmgr using SSLCIPH(TRIPLE_DES_SHA_US) and for CoordinationQmgr using SSLCIPH(DES_SHA_EXPORT). You should now have one SSL -enabled Server Connection channel on each of your queue managers.

Creating and configuring the client-side keystore (optional)

Complete this section only if you want client authentication when a connection is made to a queue manager. If client authentication has not been specified on the channel, you do not need to complete this section:

Defining client keystore

This scenario uses self-signed certificates, and in that sense you can just use the existing truststore as a keystore for client authentication also, as the certificate acts as both the personal certificate and the CA. The password that was not required to be set before will now need to be passed to the JSSE in order for it to access your personal certificate, which is why it was specified earlier.

Setting the keystore and password in the properties files

agent.property file updates:

coordination.property file updates:

command.property file updates:

Altering queue manager channels to require CA

As with the original queue manager configuration, use MQ Explorer (Figure 7) or runmqsc (Listing 6) to alter the server connection channels that you created earlier on all three queue managers:

Figure 7. Altering SSL Server Connection to require Client Authentication
Altering SSL Server Connection to require Client Authentication
Listing 6. Altering AgentQmgr SVRCONN Channel in runmqsc
C:\WMQFTE_SSL>runmqsc AgentQmgr
5724-H72 (C) Copyright IBM Corp. 1994, 2009.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager AgentQmgr.

ALTER CHANNEL(SYSTEM.SSL.SVRCONN) CHLTYPE(SVRCONN) SSLCAUTH(REQUIRED)
     1 : ALTER CHANNEL(SYSTEM.SSL.SVRCONN) CHLTYPE(SVRCONN) SSLCAUTH(REQUIRED)
AMQ8016: WebSphere MQ channel changed.
DISPLAY CHANNEL(SYSTEM.SSL.SVRCONN)
     2 : DISPLAY CHANNEL(SYSTEM.SSL.SVRCONN)
AMQ8414: Display Channel details.
   CHANNEL(SYSTEM.SSL.SVRCONN)             CHLTYPE(SVRCONN)
   ALTDATE(2009-11-19)                     ALTTIME(14.02.49)
   COMPHDR(NONE)                           COMPMSG(NONE)
   DESCR( )                                HBINT(300)
   KAINT(AUTO)                             MAXINST(999999999)
   MAXINSTC(999999999)                     MAXMSGL(4194304)
   MCAUSER( )                              MONCHL(QMGR)
   RCVDATA( )                              RCVEXIT( )
   SCYDATA( )                              SCYEXIT( )
   SENDDATA( )                             SENDEXIT( )
   SHARECNV(10)                            SSLCAUTH(REQUIRED)
   SSLCIPH(RC4_MD5_EXPORT)                 SSLPEER( )
   TRPTYPE(TCP)

Testing the configuration

At this point, you should have your three queue managers with an SSL-enabled server connection channel on each, all with their own certificate stores holding a self-signed certificate. Optionally, you may have also enabled CA. WMQFTE should be configured to allow connections to these new SSL-enabled channels. Starting MQ Explorer with the WMQFTE Plug-in, your SSL configured agent AGENT1, or any of the WMQFTE commands, will now connect to their respective queue managers via that SSL enabled channel, as shown in Table 1. Connection of WMQFTE entities to queue manager types. Try executing each of the following entities:

  • fteStartAgent AGENT1 -- Check output0.log for successful initialization and connection of your agent.
  • fteListAgent -- Stdout should show Agent AGENT1 on your WMQFTE network.
  • fteFteCreateTransfer -sa AGENT1 -da AGENT1 -df C:\MyDestinationFile -w C:\MySourceFile -- Should report that the file transfer has successfully completed, and the destination file should exist.
  • Connecting to the CoordinationQmgr via WMQFTE Plug-in for MQ Explorer -- the WMQFTE node in the MQ Explorer GUI should connect to CoordinationQmgr.

If everything went smoothly, you should see no difference in behaviour compared to running without SSL.

The best test is a failing test

Of course, testing your connections work could just mean that you are connecting on a non-SSL channel to your queue manager, and have not performed any of the WMQFTE side configuration. A simple way to check whether SSL is configured is to deliberately mismatch your WMQFTE and queue manager channel cipher suites. With such a misconfiguration, starting your agent should result in the connection to the queue manager failing with MQRC 2397 - MQRC_JSSE_ERROR. Match the cipher suites again and the agent should start. Example output for failed connections for each of the three queue manager types is shown below:

Listing 7. Failing agent output (Connecting to the AgentQmgr queue manager)
BFGAG0115I: Relative path transfer root directory: C:\Documents and Settings\Laurence
BFGAG0058I: The agent has successfully initialized.
BFGAG0052E: The agent received MQI reason code 2397 when establishing a client transport
    mode connection to the queue manager 'AgentQmgr' on host 'localhost', port '5050' and
    using channel 'SYSTEM.SSL.SVRCONN'.  The agent cannot continue and will end.
BFGAG0061E: The agent ended abnormally
Listing 8. Failing fteListAgent output (Connecting to the CommandQmgr queue manager)
C:\Program Files\IBM\WMQFTE\bin>fteListAgents 
5655-U80, 5724-R10 Copyright IBM Corp.  2008, 2009.  ALL RIGHTS RESERVED
BFGCL0002E: A messaging problem prevented the command from completing successfully.
The WebSphere MQ completion code was 2, and the reason code was 2397.  
A connection could not be established to queue manager CoordinationQmgr, 
on host 'localhost' using port 5052 and channel SYSTEM.SSL.SVRCONN.
Listing 9. Failing fteCreateTransfer output (Connecting to the CoordinationQmgr queue manager)
C:\Program Files\IBM\WMQFTE\bin>fteCreateTransfer -sa AGENT1 -da AGENT1 -df 
C:\MyDestinationFile -w C:\MySourceFile 
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2009.  ALL RIGHTS RESERVED 
com.ibm.wmqfte.api.TransportException: BFGCL0002E: A messaging problem prevented
the command from completing successfully. The WebSphere MQ completion code was 2, 
and the reason code was 2397.  A connection could not be established to queue manager 
CommandQmgr, on host 'localhost' using port 5051 and channel SYSTEM.SSL.SVRCONN.

Conclusion

This article showed you how to configure a three queue manager WMQFTE with SSL scenario, relating to agent, command, and the WMQFTE Plug-in for MQ Explorer. It also described the basic MQ configuration for your SSL-enabled WMQFTE entities to connect, and the optional client authentication.

Troubleshooting

Debugging SSL issues is tricky. When unexpected authentication failures occur, check these two places first:

  • The Agents Output0.log files -- look for any information on the action that you expected to happen.
  • Queue manager error logs -- look for details on failed connections.

A configuration issue is usually the root cause, so double-checking that your client and server configurations correctly match can weed out a lot of problems. When building a complex scenario, develop it in increments, checking it as you go. Creating a complex scenario with certificate revocation lists, client-side authentication, and the like from scratch in one go is likely to leave you with multiple configuration problems that are difficult to isolate and resolve.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=461506
ArticleTitle=Configuring Secure Sockets Layer connectivity in WebSphere MQ File Transfer Edition
publish-date=01132010