Introduction

Today, the Secure Socket Layer (SSL) protocol provides the basis for much of the security implemented across insecure networks such as the Internet. Consequently, SSL, particularly in its hybrid guise of HTTPs, has become a familiar term to J2EE developers.

IBM® WebSphere® MQ Version 5.3 (hereafter called MQ) supports SSL for securing channels between queue managers, and channels between applications and the queue managers being used. In JMS terms, this means that a JMS client (application) that uses the client (network-based) transport to communicate with an MQ JMS provider can secure the communication using SSL.

This article demonstrates how to configure an SSL connection between a JMS application and an MQ queue manager running on Windows 2000. The article introduces SSL, and discusses key SSL concepts such as digital certificates and cipherspecs. If you are already very familiar with SSL, you may wish to skip ahead to the section, Configuring WebSphere MQ SSL. It is assumed that you have a working knowledge of WebSphere MQ and MQ JMS, and that you have already created a queue manager and properly configured your JMS environment. Refer to the Resources later in this article for more detail on these topics.

Back to top

Security concepts

Before delving into SSL itself, it is useful to consider the key security problems that network communication faces, along with the appropriate solutions. Key security problems include:

• Eavesdropping
• Tampering
• Impersonating

Eavesdropping

Eavesdropping occurs when unknown people understand the messages that are passed between the communicating parties. In other words, you need to stop unknown people from reading your messages. To protect against eavesdropping, an application must encrypt the information before sending it, converting it from plain text to unreadable ciphertext. The receiving application then decrypts the message upon receipt, converting from ciphertext back to plain text. The theory is simply that the eavesdropper will not know how to decrypt the message. The process of encryption or decryption is generally known as cryptography, and relies on mathematical algorithms.

Encryption algorithms encrypt or decrypt messages by performing a sequence of mathematical operations on the message, transforming its appearance but not its content. The algorithm is referred to as a stream or block cipher depending on whether the algorithm transforms the message one byte at a time or a block (eight bytes) at a time. The encryption algorithm is created specific to the particular use case based on a key fed into the algorithm. The key is typically a random sequence of bits; its size categorizes the strength of the encryption algorithm.

The encryption algorithm makes use of keys in one of two ways:

• A symmetric algorithm requires that both the sender and receiver of the message use the same secret key; this is often referred to as secret key cryptography.
• An asymmetric algorithm uses a different key for encrypting or decrypting the message; one of the keys must be kept secret, and the other key is usually made public. In this case, a sender might encrypt the message using the receiver's public key, but only the receiver has the secret key that is used to decrypt the message. This approach involving private and public key pairs is also known as public key cryptography.

Symmetric algorithms have faster performance than asymmetric algorithms, but passing the secret key securely between participants poses a distribution problem. First, how do you pass the key secretly, and second, how do you scale the approach to many sender/receiver pairs. With private and public key pairs, the distribution problem is alleviated because the receiver publishes a public key for all senders to use to encrypt information, and uses a private (secret) key to decrypt all information received. The public key cannot be reverse-engineered to get the private key, and the private key is known only to the receiver. This, however, comes at the expense of increased performance overhead.

Tampering

Tampering involves someone intercepting a message and then changing it. Tampering is addressed by a message digest, which is a fixed size numeric representation of the contents of a message. The message digest (also called the message authentication code) is computed using a hash function. This is one-way only, which means that it is not possible to reverse the function and find the message corresponding to the digest, and is implemented in such a way that it is computationally unfeasible to find two different messages that hash to the same digest.

Once computed, the digest is transmitted along with the message. The receiver then invokes the same hash function on the received message and compares the generated digest to the one received. If the digests are the same, then the message was not tampered with en route. Clearly, for this process to work, the sender and receiver must agree on the hash function that will be used before transmission begins.

Impersonating

Impersonating occurs when a message is sent by someone other than the actual specified sender. To address this problem, you need to verify that the message was actually sent by the sender, and authenticate the partner who you are exchanging information with.

Digital signatures are used to verify that the message was actually sent by the sender; they combine the use of message digests and public key cryptography. The process involves the sender generating the message digest, then encrypting the digest using its private key to create the digital signature. The receiver then decrypts the message digest using the sender's public key, confirming that the message was indeed sent by the sender. Comparing the digest with the one the receiver generates further confirms that the message has not been changed since it was signed.

However, how does the receiver know that the public key can be trusted? Often referred to as the man-in-the-middle attack, this problem occurs when an unknown third party intercepts the sender's public key and swaps it for its own. The rogue agent then impersonates the original sender and signs intercepted messages. Because the receiver is able to decrypt the sent messages, the receiver does not know that it is interacting with a rogue user. Now we come to the question of how to authenticate the partner who you are exchanging information with.

Digital certificates address this problem by certifying that a public key belongs to a named entity. The digital certificate is typically issued by a trusted third party called a Certification Authority (CA). For a fee, the CA will generate a digital certificate that contains:

• The owner's public key
• The owner's Distinguished Name
• The Distinguished Name of the CA that is issuing the certificate
• The date from which the certificate is valid
• The expiry date of the certificate
• A version number
• A serial number

Before issuing a certificate, Certification Authorities run appropriate background checks on the requestor to verify that the requestor is who they say they are. All certificates issued by a CA are digitally signed by the CA, and can be verified using the CA certificate (which contains the CA's public key). The exchange between the sender and receiver now takes on an additional verification step. Instead of simply sending its public key to the receiver, the sender sends its digital certificate issued by a CA. The receiver uses the CA's certificate to verify the sender's certificate, ascertaining that the public key contained in the certificate truly belongs to the owner. During the lifetime of a digital certificate, the issuing CA might determine that the certificate is no longer to be trusted. Such certificates are published to a Certificate Revocation List, against which both the sender and receiver can choose to check the received certificates.

Back to top

Secure Socket Layer

The SSL protocol uses the concepts of secret and public key encryption, digital signatures, and digital certificates to establish a secure connection between parties and to facilitate the transmission of secure data over an insecure network. SSL was designed by Netscape (see the SSL Protocol ), and defines the following participants:

• SSL Client: The calling application that initiates the SSL connection
• SSL Server: The responding application

The SSL Client and SSL Server interact to establish a secure connection. This interaction is referred to as the SSL handshake:

1. The SSL Client initiates the conversation and sends information such as the SSL version, along with the encryption algorithms and hash functions it supports.
2. The SSL Server responds with the encryption algorithm and hash function to be used. This is selected from the list provided by the Client. It also sends a session ID, a random byte string, and its digital certificate. The Server can optionally include a request for the Client's digital certificate.
3. The SSL Client authenticates the SSL Server by verifying the digital signature on the supplied digital certificate, and the digital certificate itself, using the issuing Certification Authority's certificate. The Server's certificate might be optionally checked against a Certificate Revocation List.
4. If satisfied, the SSL Client sends the secret key that will be used to encrypt further exchanges. The secret key is itself encrypted using the SSL Server's public key obtained from the Server's digital certificate. In addition, the Client might send its digital certificate, if it was requested by the Server.
5. The SSL Server decrypts and stores the secret key, using its private key. It optionally authenticates the Client, similarly using the issuing Certification Authority's certificate and potentially associated Certificate Revocation Lists. This step only occurs if the Server requested the Client's certificate in step 2 above.
6. The SSL Client sends a message encrypted with the secret key, indicating that the Client part of the SSL handshake is complete.
7. The SSL Server responds with a message similarly encrypted with the secret key, indicating that the Server part of the handshake is complete.
8. A secure connection is now established, and communication for the rest of the session is encrypted using the secret key.

To facilitate the specification of encryption algorithms and hash functions that are used during an SSL session, the algorithms are grouped into CipherSuites. A CipherSuite defines:

• The key exchange and authentication algorithm used during the SSL handshake
• The encryption algorithm used to secure data
• The hash function used to generate the message digest

The encryption algorithm and the hash function are further grouped into CipherSpecs.

WebSphere MQ 5.3 supports only the RSA key exchange and authentication algorithms. Details of some of the supported CipherSpecs are listed in the following table:

Notes:

• RC2 is a block cipher algorithm. It encrypts the data by blocks (8-bytes long), and supports key lengths of 40 bits, 64 bits, and 128 bits. RC4 is a stream cipher algorithm operating on each byte of data; like the RC2, it supports key lengths of 40 bits, 64 bits, and 128 bits. Both RC2 and RC4 are produced by RSA Data Security Inc.
• DES, the United States Data Encryption Standard, is a block cipher algorithm with 8-byte long blocks and a key length of 56 bits. Triple DES is a variation of DES, with a key length of 168 bits.
• In terms of performance, from fastest to slowest, they are: RC4, DES, RC2, TripleDES.
• SHA stands for Secure Hash Algorithm and MD5 stands for Message Digest Version 5. Choosing between MD5 and SHA-1 is a tradeoff between security and performance. The SHA algorithm is more secure, producing a 160-bit output compared to the MD5 algorithm's 128-bit output. However the MD5 algorithm is much faster in calculating the message digest.
• An example of an MQ-supported CipherSuite is SSL_RSA_WITH_RC4_SHA_US. This specifies the use of the RSA Key Exchange and authentication algorithm, along with the RC4_SHA_US CipherSpec.

Back to top

Configuring WebSphere MQ SSL

To configure WebSphere MQ and the associated JMS Client for SSL, you need to complete the following:

1. Obtain or generate digital certificates for the SSL Server and optionally the SSL Client
2. Configure the SSL Server, in this case the MQ queue manager
3. Configure the SSL Client, in this case the MQ JMS application

Obtaining a digital certificate

To obtain a digital certificate, you can do either of the following:

• Request a digital certificate from a Certification Authority, or
• Use environment-specific tools to generate a self-signed certificate

With a self-signed certificate, you act as you own CA. Self-signed certificates can be useful for test environments because you can generate them locally and you do not have to pay fees to a CA. However, many Certification Authorities offer a demo facility that lets you generate demo (test) certificates at no charge. Also, in some environments, you can request a CA to generate a CA certificate for a self-signed certificate, which validates and resigns the previously generated certificate.

In this article, we will use a Certification Authority's demo facilities to generate a certificate for a Windows 2000-based queue manager, and we will use Java utilities to generate a self-signed certificate for the JMS Client application.

Certificates are stored in repositories that vary based on the operating system and the tools used to access them. On the Windows platform, certificates are stored in Microsoft Certificate Stores; you can view and manipulate them using Internet Explorer. In a Java environment, certificates are stored in keystores (flat files), which you can manipulate using keytool, a utility that ships as part of the JVM SSL support infrastructure (this will be described in more detail later). On UNIX, you would use the iKeyman key management tool to handle digital certificates. You must be familiar with the digital certificate infrastructure support provided by or supplied for the operating environment in question. This article focuses on the Windows and Java environments; however, the process is fairly generic, with the main difference being the actual commands used.

Obtaining a certificate for the WebSphere MQ queue manager
Digitrust is a certification authority that offers demo certificates. Here, we will obtain a certificate for the MQ queue manager:

1. In your Internet Explorer browser, launch the URL: http://www.digsigtrust.com/prod_serv/index.html.
2. Click on Get a TrustID Demo Certificate (see Figure 1).
   
   Figure 1. Get a TrustID Demo Certificate
   
   
3. Fill in the identification form. The certificate is based on the name, organization, and location details. In Figure 2, the name SSL QMGR is used to identify the queue manager certificate. The certificate is sent to the e-mail address provided. The passphrase you provide is used to retrieve the certificate. Click Continue.
   
   Figure 2. Server identification
   
   
   
4. Review the information, and click Continue.
   
5. Select Browser as the option for storing the certificate (see Figure 3). Click Continue.
   
   Figure 3. Choose storage mechanism
   
   
6. Click Accept on the Certificate Agreement.
7. Accept the defaults: 1024 and Microsoft Enhanced Cryptographic Provider v1.0. These values are used to generate your public/private key pair (see Figure 4). Click Continue.
   
   Figure 4. Generating the key pair
   
   
8. If you receive warning messages from Internet Explorer indicating that a site is generating a certificate on your behalf, simply click Yes on the message dialogs.
9. The next pane confirms that the certificate is being generated. It also prompts you to download the DST Root Certificate; this step is not required because Windows 2000 comes pre-supplied with various Root Certificates from different Certification Authorities, including the DST Root Certificate.
10. Check your e-mail for a note from the Digitrust; it will contain a URL and activation code.
11. Access the supplied URL using Internet Explorer; supply your passphrase (refer to step 3 above), and click Retrieve.
12. Internet Explorer will now prompt you to add a certificate. Click Yes on this message dialog.
13. The resulting status screen confirms that the certificate has been added. Click Continue.
14. To view the certificate in Internet Explorer, select Tools => Internet Options. On the resulting Dialog box, click the Contents tab, and then click the Certificates button. The Certificates dialog box displays all of the certificates available in the Microsoft Certificate Store. The Personal tab view lists in alphabetical order the personal certificates, including the ones that you have just generated (see Figure 5).
    
    Figure 5. Microsoft Certificate Store
    
    
15. Click the View button. This displays various details associated with the certificate. The Certification Path Tab view displays the certification chain for the certificate (see Figure 6). The certification chain defines the hierarchy of approving Certification Authorities, and provides a list of CA certificates required to approve a given personal certificate. In the case of the queue manager's certificate, there are three CA certificates in the chain. The JMS Client application will need access to all three CA certificates to successfully authenticate the queue manager's personal certificate.
    
    Figure 6. The certification path
    
    

Generating a certificate for the JMS Client
JSSE (Java Secure Socket Extension) provides support for Java applications to communicate securely using SSL. It provides APIs and utilities for developing and configuring SSL-based applications. JSSE is bundled with J2SE 1.4; supported environments include JREs at the same level from both IBM and Sun. You may also use the IBM JRE 1.3.1 with the IBM JSSE 1.0.3 package. However, extended functions such as Certificate Revocation Lists are not supported at the 1.3.1 level as it is defined as part of the CertAPI that ships with JRE 1.4. Therefore, for a full-featured environment, J2SE 1.4 is required.

For this article, I used IBM JRE 1.3.1 and JSSE 1.0.3. JSSE 1.0.3 includes installation instructions for adding the package to the JRE, which I will not repeat here. I also tested with IBM JRE 1.4 which comes bundled with JSSE, as does Sun JRE 1.4. It requires no additional package configuration. If you want to run your JMS application in WebSphere Application Server, keep in mind that the embedded 1.3.1 JVM is preconfigured with JSSE support, and therefore also requires no additional configuration. If you are a newcomer to JSSE, you might want to walk through the JSSE tutorial referenced in the Resources section to familiarize yourself with JSSE.

In the Java environment, digital certificates are stored in keystores, which resolve to flat files in the directory structure. We will create a keystore for our JMS application; a self-signed certificate will be generated in this keystore.

From a command line, run the following command:

keytool -genkey -keystore jmskeystore -storepass
changeit -keypass changeit -dname
"cn=JMSClient, ou=Test, o=IBM, c=US, st=MD"
-alias jmsclient -keyalg RSA -keysize 2048

This command specifies that a personal certificate (public/private key pair) be generated in a keystore that is to be located in the current directory. Passwords are associated with both the keystore and the key. The X.500 distinguished name that identifies the certificate is specified (this is equivalent to filling in the identification information when requesting a certificate from a CA). The command also includes an alias for the certificate, along with the specification of the algorithm and key size used to generate the key pair.

You have now generated a self-signed certificate contained in jmskeystore, which can be found in the current directory.

Configuring the WebSphere MQ queue manager

To configure the WebSphere MQ queue manager as the SSL Server, you need to assign it a personal certificate, and ensure that it has access to any CA or self-signed certificates that it might need. The queue manager maintains a certificate store (key repository), which is stored as a file (extension .sto) under the queue manager directory structure. Although you can change the location, the defaults are suitable for our purposes.

1. In MQExplorer, select your queue manager (in our case, SSLQMGR), and right-click to view the properties. In the Properties dialog, click the SSL tab (see Figure 7). Use this tab view to define the location of the key repository, and configure both Certificate Revocation List servers (refer to the Security concepts section) and hardware cryptography support (available on some platforms). We will not be using these additional functions. Click Manage SSL Certificates.
   
   Figure 7. Queue manager properties provided in the SSL tab view
   
   
   
2. You need to add the queue manager's personal certificate, which was generated previously. Click Add (see Figure 8). The resulting dialog box (see Figure 9) provides access to the Microsoft Certificate Store on the machine. Find the queue manager's certificate (SSL QMGR), and click Add. (Note that the dialog also lets you import certificates from files that might have been exported from other systems.)
   
   Figure 8. Manage SSL certificates
   
   
   Figure 9. Add queue manager personal certificate
   
   
3. You also need to add the public certificate from the JMS Client; this is required to authenticate the JMS Client. From a command line, run the following command:
   
   keytool -export -keystore jmskeystore -storepass changeit -alias jmsclient -file jmsclient.key
   
   This command exports the public key for the personal certificate stored in jmskeystore to a file called jmsclient.key. The storepass value should match what was specified when the certificate was generated.
   
   
4. You can now import the public certificate for the JMS Client. In the Manage SSL Certificate dialog, click Add, and select the Import from file radio button.
5. Browse and retrieve the file jmsclient.key (set file type to all files). Leave the password field blank, and click Add (Figure 10). Note that a public certificate called JMSClient is now added to the queue manager's key repository.
   
   You have now added all of the required certificates.
   
   Figure 10. Import public certificate from file
   
   
6. In the Manage SSL Certificate dialog, select the added queue manager certificate, SSL QMGR , and click Assign. In the resulting dialog, click Assign to confirm your selection. The queue manager has now been assigned a personal certificate with which it can be authenticated, and it has access to the public certificate required to authenticate the JMS Client (see Figure 11).
   
   Figure 11. Certificate assigned to the queue manager
   
   
7. Close all open dialogs.
   

Now, you will configure the channel with which the JMS Client will communicate with the queue manager for SSL:

1. In MQExplorer, select the queue manager, SSLQMGR. Select the Advanced folder, and then select the Channels folder, and right-click.
2. From the drop-down menu, select New => Server Connection Channel. In the resulting dialog, in the General tab view, provide a name for the channel (in this case, use SSL.SVRCONN). Switch to the SSL tab view, and specify a cipher specification (in this case, use RC4_MD5_US). Note that the default settings also specify that the queue manger should authenticate the SSL Client (if this is not desired, deselect the check box) (see Figure 12). Click OK.
   
   Figure 12. Specifying the new server connection channel
   
   

You have now configured the server connection channel that the JMS Client will use to communicate with the queue manager.

Command-line equivalents exist for all of the above tasks; run these commands when a GUI is not required or available (for example, on a non-Windows platform). You can find these commands and attributes in the WebSphere MQ User Guides listed in the Resources section; some commands are listed in the following table for illustrative purposes:

Configuring the JMS Client

First, ensure that the JMS Client has access to the CA certificates that are required to authenticate the queue manager. The Java Runtime Environment (JRE) provides a default keystore for CA certificates, called cacerts, which you will use here.

1. In your Internet Explorer browser, Select Tools => Internet Options. On the resulting dialog box, click the Contents tab, and then click the Certificates button.
2. View the queue manager's certificate, SSL QMGR, and confirm the certification path. Select the Certification Path tab. The tab view contains DEMO CA A6, DEMO Root CA X3, and DEMO RootCA X1. The first two are located in the Intermediate Certification Authorities tab view, and the third one is located in the Trusted Root Certification Authorities tab view.
3. For all three certificates, select the certificate, and then click Export. The Certificate Export Wizard launches. Click Next.
4. Accept the default export format, DER encoded binary X.509 .CER. Click Next.
5. Specify a path and filename to which the certificate will be saved (for example, for DEMO CA A6, specify DEMOCAA6.cer as the filename). Click Next.
6. Click Finish to export the certificate.

You now have the CA certificates stored in files in the chosen directory. Now you will use keytool to import the CA certificates into the default keystore for CA certificates, cacerts.

1. From a command line, run the following command:
   
   keytool -import -keystore JAVA_HOME\jre\lib\security\cacerts
-storepass changeit -keypass changeit -alias CAA6 -file DEMOCAA6.cer
   
   
2. You will be asked if this certificate can be trusted. Type Y and press Enter. The certificate is now added.
   
   As you can see in the above command, cacerts is located in the jre\lib\security directory of your Java run-time installation. The default password for the keystore is changeit ; you can change the password if desired. Optionally, you can create a truststore by specifying a different name for keystore. The alias is an identifying string, and was simply based on the certificate's name; it must be different for each imported file.
   
   
3. Repeat steps 1 and 2 to import the remaining CA certificates.

Having successfully imported all of the required certificates, you can now configure and run the JMS Client application.

The JMS Client application does not require any special APIs to utilize SSL because the configuration takes place in the ConnectionFactory. For this test scenario, I adopted the Point-to-Point domain, and wrote a simple application to place a message on the queue. While the source code is provided, note that there is nothing specific to SSL in the application; it is simply a generic JMS application.

As previously mentioned, the SSL configuration is defined by the ConnectionFactory object that the application retrieves. Specifically, for this case, the object is QueueConnectionFactory. To define the QueueConnectionFactory, use the jmsadmin utility available with WebSphere MQ 5.3.

1. Navigate to the directory that contains the jmsadmin tool (<mq_home>\java\bin ). It is assumed that you have already edited JMSAdmin.config to configure a namespace to store JMS-administered objects. Now, from a command line, run jmsadmin.
2. Define a QueueConnectionFactory by running the following command:
   
   DEF QCF(SSL) QMANAGER(SSLQMGR) TRANSPORT(CLIENT) HOSTNAME(localhost)
PORT(1414) CHANNEL(SSL.SVRCONN) SSLCIPHERSUITE(SSL_RSA_WITH_RC4_128_MD5)
   
   This command creates a QueueConnectionFactory that accesses the queue manager, SSLQMGR, using the client (network-based) transport on a machine localhost via port 1414 and channel SSL.SVRCONN. Recall that these values come from the configuration of the queue manager. You simply need to set a value for the attribute SSLCIPHERSUITE to enable an SSL connection to be initiated when connecting to the queue manager. This is the QueueConnectionFactory that the JMS application uses.
3. The supplied sample JMS Client application expects a Queue object to be defined, which references an existing queue on the target queue manager. You can define the Queue object by running the following command (ensure that you have created the queue on the queue manager as well):
   
   DEF Q(Q1) QUEUE(Q1)

The SSLCIPHERSUITE value is a valid CipherSuite implemented by the JSSE implementation. WebSphere MQ components specify only a CipherSpec, as only SSL_RSA is supported. Consequently you need to specify a CipherSuite that is functionally equivalent to MQ's SSL support (SSL_RSA) and the CipherSpec defined for the channel, noting that the names differ slightly between both environments. The following table is taken from from the WebSphere MQ 5.3 Using Java user guide (Appendix H) that details the JSSE CipherSuite and associated WebSphere MQ CipherSpec.

Currently, WebSphere MQ 5.3 does not let SSL clients pass a list of CipherSuites to the server.

Running the test case

To run a generic JMS application to use SSL, you must pass two key parameters to the JVM as part of the Java command. The first parameter provides the location of the keystore that will be used, and the second provides the password required to access the keystore. Consequently, the Java command would be of the form:

Java -Djavax.net.ssl.keyStore=jmskeystore
-Djavax.net.ssl.keyStorePassword=changeit <classname>

The download file contains a sample JMS Client application. The application requires additional arguments that specify:

• The type of JNDI namespace from which administered objects are to be retrieved
• The location of the JNDI namespace
• The name of the QueueConnectionFactory
• The name of the Queue object which defines the message destination

Therefore, to run the sample, you need to run the following Java command:

Java -Djavax.net.ssl.keyStore=jmskeystore
-Djavax.net.ssl.keyStorePassword=changeit
JMSSSLApp com.sun.jndi.fscontext.RefFSContextFactory
file:/C:/JNDINamespace SSL Q1

In this command, the JNDI namespace is identified as being the file located in C:\JNDINamespace, and the QueueConnectionFactory and Queue are represented by SSL and Q1 respectively.

If you have configured everything correctly, then the application will successfully place a message to the queue. To view the SSL exchanges that occur, run the JVM in SSL debug mode by adding the following command switch:

• On IBM's JVM, add: -Djavax.net.debug=true
• On Sun's JVM, add: -Djavax.net.debug=ssl

It is recommended that you pipe the output to a file because the exchange is verbose.

If you choose to use a different keystore other than the default (cacerts) to store the CA certificates, then you can specify this keystore (known as a truststore) by including the following command switch:

-Djavax.net.ssl.trustStore=<truststore>

where truststore is the location of your CA keystore.

Back to top

Conclusion

This article introduced SSL and described how to configure an SSL connection between a JMS Client application and a WebSphere MQ queue manager (JMS Provider). This involved:

1. Obtaining a digital certificate for the SSL server (queue manager) and the SSL Client (JMS client). The certificate for the JMS Client was required only because we wanted to the server to authenticate the client. We used a Certification Authority and stand-alone utilities to generate the certificates.
2. Configuring the SSL Server (queue manager). We populated the queue manager's key repository, with appropriate certificates, and assigned the queue manager a certificate to use in the exchange.
3. Configuring the SSL Client (JMS Client). We populated Java keystores with required certificates, and configured the ConnectionFactory object for SSL.

This article is by no means exhaustive, but by following the steps outlined in this article, you can now easily configure and demonstrate SSL-secured communication.

Back to top

Download

Name	Size	Download method
JMSSSLApp.zip	0.003 MB	FTP|HTTP

Information about download methods

Resources

• IBM developerWorks article, Writing Java Message Service programs using WebSphere MQ and WebSphere Studio Application Developer -- Part 1: Installing the software and running your first programs
  
  
• JSSE tutorial: Using JSSE for Secure Socket Communication
  
  
• WebSphere MQ v5.3 User Guides
  • WebSphere MQ 5.3 Using Java (SC34-6066-01)
  • WebSphere MQ 5.3 Security (SC34-6079-01)
  • WebSphere MQ 5.3 System Administration Guide (SC34-6068-00)
  
  
  
• IBM Redbook: IBM WebSphere Advanced Edition 4.0 Security.
  
  

About the author

Kareem Yusuf, Ph.D is a Consulting IT Specialist with IBM. For the past four years, he has been actively involved with developing and using IBM WebSphere-based JMS solutions. Kareem works for the WorldWide WebSphere Technical Sales team, and can be reached at yusufk@us.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Security concepts
• Secure Socket Layer
• Configuring WebSphere MQ SSL
• Conclusion
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere MQ
• Briefing: WebSphere flexible business processes
• Buy: WebSphere MQ

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers