Planning for SSL on the WebSphere MQ network


Content series:

This content is part # of # in the series: Mission:Messaging

Stay tuned for additional content in this series.

This content is part of the series:Mission:Messaging

Stay tuned for additional content in this series.

In each column, Mission: Messaging discusses topics designed to encourage you to re-examine your thinking about IBM® WebSphere® MQ, its role in your environment, and why you should pay attention to it on a regular basis.

Make good on your resolutions

I am here this month to help you with your New Year's resolution -- assuming, of course, that your resolution was to enable SSL on the messaging network.

With the number of shops enabling SSL increasing, and having had the chance to work and talk with many WebSphere MQ administrators who have implemented SSL, I have noticed a couple of trends:

  • The first is that the SSL configurations were checked to make sure that they allowed the expected connections, but there was insufficient checking to ensure that these were the only connections accepted. As a result, many of these configurations unknowingly allowed far more connectivity than expected, even to the point of allowing anonymous connections.
  • The second trend I noticed was that many SSL configurations allow inappropriate administrative access, often due to a misunderstanding about how the SSL authentication is applied to WebSphere MQ API calls.

I will address both of these issues in this article, so if you are just starting your SSL implementation, perhaps I can help you avoid these pitfalls. If you have already deployed SSL, you might find a few suggestions here that will help you tighten it up.

Why use SSL?

Secure Sockets Layer, more commonly known as SSL, provides three services:

  • Confidentiality is provided using encryption. If an eavesdropper captures messages moving through the network, the encryption makes it impossible (or at least prohibitively expensive) to convert the data to usable plain text. There are many different types of encryption available in WebSphere MQ, using a variety of algorithms and key lengths. It is even possible to enable SSL on the channel with no encryption at all.
  • Integrity is provided by hashing the messages. A hash is very much like a fingerprint and the hash algorithm is constructed so that the smallest change in the source produces a completely different and unpredictable hash value. When the message arrives at its destination, the hash provides some assurance that the message has not been tampered with. The integrity function is not optional. When SSL is enabled for a WebSphere MQ channel, all messages on that channel are hashed and verified.
  • The certificates used in SSL contain identity information and are encapsulated in a cryptographic envelope to prevent tampering. The certificate's identity information is the basis for SSL authentication. The SSL protocol has its own exchange of messages before the WebSphere MQ channel ever starts up and it is during this SSL handshake that authentication of the server -- and, optionally, the client -- takes place. In this case, "client" is the thing that initiates the connection. It could be an application or user connecting to a WebSphere MQ client channel, or it could be another queue manager. Similarly, "server" in this context is the thing that receives the connection request.

But what exactly does it mean to say that something has been authenticated based on an SSL certificate? Understanding the answer to that question is the key to building meaningful security using SSL.

Authenticated: The SSL definition

The queue manager has a database of certificates that are used during the SSL exchange. The database has one section called the key store that contains all of the certificates that could be used to sign something to be sent out. The queue manager is associated with a single certificate which must be available in the key store. Another section in the key database is the trust store and it contains all of the public keys of things that are trusted by the queue manager. When the database is created, the trust store is populated with a default set of keys from commercial certificate authorities. Currently, these include Entrust, Verisign, Thawte, and RSA.

When a certificate is presented, the criteria used to authenticate is very simple: Has the certificate been signed by something in the trust store? If so, then the certificate is accepted and that part of the SSL exchange is complete.

Consider the example of a certificate issued by a commercial certificate authority. The integrity of the certificate is checked using the hash algorithm. Next, a check is made to see if a certificate for the signing CA exists in the local trust store. If so, the candidate certificate is accepted. Note that it is not necessary to have a copy of the candidate certificate in advance. It is only necessary that the authority who signed the certificate presented is trusted.

By itself, this is not terribly useful in a WebSphere MQ context. Any certificate signed by one of the default commercial CAs would be accepted; for all practical purposes, this means that anyone can connect. Fortunately, WebSphere MQ provides some additional tools to narrow down the scope of who can connect.

Filtering unwanted connections

A certificate contains several types of identity information, one of which is known as the Distinguished Name, or DN. What distinguishes the name is that no two certificates from the same CA should have the same identity. Each certificate from a given certificate authority is unique. In addition, a reputable certificate authority will require proof of the requestor's identity before issuing a certificate. This due diligence on the part of the CA provides a basis to trust the identity bound to the certificate. The identity in the certificate is also designed to be machine-readable. WebSphere MQ exploits these three features -- uniqueness, trustworthiness, and machine parsability -- to provide a filtering mechanism.

The DN is composed of several fields, including a common name (CN), organization (O), organizational unit (OU), and country (C). (There are more, but I'll confine my examples to these fields to keep them readable.) The CN field usually contains the server or queue manager name. The O field contains the company to whom the certificate was issued. One or more OU fields contain qualifiers within the company, such as division or line of business. A valid DN, then, might look something like this:


The channel's SSLPEER attribute enables the administrator to specify values to match on the various fields within the DN to construct rules. It is possible to specify individual values, wild cards, or even the entire DN. Depending on the values chosen, the result is filtering that can range from very permissive to the ability to specify a single acceptable DN. For example, setting SSLPEER('C=US') allows any certificate issued in the United States to connect. A more useful designation might be SSLPEER('O=IBM') which would filter out any request where the Organization field does not contain the string "IBM." Note that even though O=IBM is a better filter than C=US, both of these are far too broad to be considered useful. In an actual implementation, you should always choose the most restrictive filter that meets the business requirement, starting with a fully-qualified DN and working back from there.

In the case of a RCVR, RQSTR, or SVR channel, it can be useful to match a single certificate since these channels usually connect to only one partner node. Generic filters that match multiple certificates are useful for SVRCONN and CLUSRCVR channels, which usually need to accept connections from a variety of client nodes.

Pre-planning is essential when designing a naming convention for certificate DNs. Matching on the company name might seem sufficient at first glance, but over time additional requirements tend to emerge. For example, it can be very useful to include values like DEV, TEST, QA, PROD, and so forth, as part of the Organizational Unit. If there are multiple clusters, including the cluster name as one of the OU fields can be helpful. In order to match multiple certificates, the OU fields must be consistent across certificates and appear in the same sequence. The OU fields should be arranged in order of increasing specificity because SSLPEER requires the OU nodes to be specified left to right. For example, given a DN that contains OU=IBM,OU=ISSW,OU=PROD, an SSLPEER string of OU=ISSW,OU=PROD would not be valid, but OU=*,OU=ISSW,OU=PROD would work.

Once issued, the certificate DN cannot be changed. Mistakes can be costly, so understand how SSLPEER works, and test your filtering using self-signed certificates before purchasing permanent certificates from a commercial CA. The SSLPEER field allows 256 characters on z/OS platforms and 1024 characters on distributed platforms. DNs, on the other hand, can be arbitrarily long. If the DN length exceeds the capacity of the SSLPEER field, it will be necessary to match using wild cards, which opens the possibility of accepting unintended connections.

If the SSLPEER attribute does not provide enough granularity, it is possible to use a security exit to evaluate the DN and filter on any arbitrary set of rules. The popular BlockIP2 channel exit enables the administrator to provide a list of fully qualified or wild-carded distinguished names to check.

Revisiting the certificate exchange

With SSLPEER or an exit in place, the SSL handshake is much more useful. There is still the basic check, meaning that the certificate signer must be present in the trust store. In addition, there is now a second check so that the identity of the certificate matches some string that the administrator has designed to filter out all but a known set of legitimate users. The SSLPEER value should be designed to match either a single unique DN or to match generically, based on values in the DN, such as common name, company name, and cluster name. When matching multiple certificates, choose the narrowest specification possible.

I should mention at this point that self-signed certificates work in exactly the same way as CA signed certificates. When a self-signed certificate is presented, a check is made ensure that the thing that signed it exists in the trust store. In the case of a self-signed certificate, it is the certificate's own public key that must exist in the trust store. If it does, then the certificate is accepted and passed to WebSphere MQ for SSLPEER or an exit to process. In essence, the public key acts as a Certificate Authority that has issued exactly one certificate.

Client authentication

The discussion so far has been framed only in terms of what happens when a certificate is presented. The question of who is presenting the certificate has been intentionally ignored in order to focus on the details of the exchange. The certificate exchange occurs at least once (and potentially twice) while the SSL connection request is negotiated. The server side of the connection always presents a certificate. The client can optionally be anonymous, depending on the configuration at the server. If the server does not force the client to present a certificate, the second certificate exchange never happens.

This is acceptable when, for example, you sign onto your bank's Web site. In this case, the server-side authentication lets you know that you really are connected to your bank and not some look-alike imposter. But you do not need to purchase a personal certificate to sign onto your bank's Web site, any browser will do. The client side of the connection can be anonymous because you are going to be required to enter a second set of credentials at the login page. But with an MQ channel, there is no secondary login layer. The certificate presented by the client side is the only opportunity to authenticate it, and it is up to the administrator to make sure that happens.

The administrator can force the client to present a certificate (keeping in mind that "client" in this case can be another queue manager) by setting the channel's SSLCAUTH attribute to REQUIRED. As always, the server presents its certificate first. If the client accepts the server's certificate and SSLCAUTH is set to 'REQUIRED', the client then presents its certificate to the server.

The authentication process and credential exchange work exactly the same regardless of whether it is the server or client being authenticated. A certificate is presented, its signer is matched to something in the trust store and, if a match is found, the DN can be matched to a value in the SSLPEER attribute or processed by a channel security exit.

Configuration weaknesses

Now that we know how all the pieces fit together, let's take a look at how they can fall apart, starting with the basic case of using self-signed certificates.

Self-signed certificates are almost always used at some point because they are free. But their other advantage is that a self-signed certificate does not require trusting a signer that has signed thousands, or even millions of other certificates. The trust store entry for a self-signed certificate matches one and only one certificate.

Implementing SSL with self-signed certificates requires the administrator to:

  • Create a key database for the client and generate the corresponding certificate.
  • Create a key database for the server and generate the corresponding certificate.
  • Extract public keys from each of the certificates.
  • Import the public key of the client into the server's key database.
  • Import the public key of the server into the client's key database.
  • Enable SSLCIPH and set SSLCAUTH(REQUIRED) on the channels between the client and server.

Assuming all of this has been done correctly, the client and server will now connect. But is this enough? The client has indeed been authenticated to the server, and vice versa. The configuration admits who it is supposed to admit. Unfortunately, it potentially still admits anyone holding a certificate issued by any of the default trusted certificate authorities. The solution for this is simple and effective: remove the default certificate authorities from the key database. If the key database contains only self-signed certificates, there is no chance of matching multiple unintended certificates. The trust store effectively becomes an enumeration of all the identities allowed to connect. Merely possessing the matching certificate is sufficient to authenticate the connection.

Now, consider the case of using CA signed certificates. Trusting a certificate authority does not equate to trusting all of the certificates issued by that CA. Better to think of it in terms of trusting that the identity bound to the certificate is valid and then setting criteria defining which identities are allowed to connect.

The setup tasks to implement SSL using CA issued certificates are:

  • Create a key database for the client and generate a certificate signing request (CSR).
  • Create a key database for the server and generate a CSR.
  • Submit the CSRs to the CA for authentication and obtain the signed results.
  • Import the CA root certificate, if it does not already exist in the trust store of the client or the server.
  • Receive the client certificate into the client's key database.
  • Receive the server certificate into the server's key database.
  • Enable SSLCIPH and set SSLCAUTH(REQUIRED) on the channels between the client and server.
  • Set SSLPEER on the server to a string that matches the client certificate.
  • Remove all other CA signers from the trust store.

Notice that the server does not need to have the client's key in its trust store (and vice versa) because the CA is trusted. The use of SSLPEER is what determines whether a given certificate is accepted or rejected. If SSLPEER specifies the entire distinguished name so that only one certificate can possibly match, is this sufficient? Perhaps. Consider that this same distinguished name can be requested from any trusted CA. For example, suppose you request a certificate with DN="CN=VENUS,O=IBM,OU=ISSW,C=US" from two of the trusted default CAs. The distinguished name is only guaranteed to be unique per CA, so there is no reason one CA would know or care that the identical DN had been issued by someone else. If you leave all five default CAs in your trust store, but are using certificates issued by only one of them, the remaining four represent opportunities for someone to request a certificate with a matching DN that could then successfully be used to connect.

If this doesn’t sound like a big exposure, consider how it might be exploited in a case when a vendor asks you to trust their internal CA rather than using a commercial CA. Your DMZ queue manager would then trust the vendor's CA for the external-facing channels and something else for the internal-facing channels. The vendor's certificate looks like DN="CN=GATEWAY,O=Vendor,OU=PROD,C=US" and your internal certificates look like DN="CN=QMGR,O=MyCorp,OU=Retail,C=US". You configure your channels with SSLPEER so that the internal-facing ones match your internal certificates and the external-facing ones match the vendor certificates. An unscrupulous vendor could issue certificates with DNs that match your internal certificates and connect to your internal-facing channels because SSLPEER only looks at the DN and not who issued it. Since your queue manager trusts the vendor's CA, the forged certificate and the legitimate one with the same DN are identical as far as the queue manager is concerned. Although it is unlikely that such a DN collision between two CAs could occur by accident with a fully-specified SSLPEER value, adding wildcards to the SSLPEER specification increases that chance. Adding several wild cards makes it a virtual certainty.

Protecting against this is not as simple as with self-signed certificates. If the trust store contains more than one entity, for example two CAs or a CA and some self-signed certificates, then DN collisions are possible. Reduce the chance of a collision by removing all unused CAs from the trust store. In addition, take advantage of other WebSphere MQ hardening techniques to limit connectivity, especially for B2B interfaces.

Revoking access

Sooner or later in the lifetime of a queue manager, there comes a time when access will need to be revoked. There are two cases to consider: that of revoking privileges granted to an otherwise legitimate identity, and that of revoking a certificate that has been compromised. Bear this distinction in mind and be sure that your implementation is designed to handle both cases.

Revoking privileges is easiest when access is granted to individual identities. If access is based on an SSLPEER that specifies the fully-qualified DN, then stopping and deleting the channel revokes access for that DN. If access is based entirely on self-signed certificates, deleting the public key of a certificate from the trust store revokes its access.

The more interesting case for revoking privileges is the SVRCONN or CLUSRCVR channel that must match many certificates when at least one CA is trusted. Clusters and interactive users are the most volatile population of identities and the most likely to require revocation of access at some point. But the SSLPEER attribute does not provide enough granularity to specify allow this group of DNs and then within this group deny these individual DNs. The only way to achieve this level of granularity in the presence of a wildcard SSLPEER and the use of CA-issued certificates is the use of a security exit capable of blacklisting individual distinguished names.

You have seen that revoking privileges blocks a certificate on one resource while allowing it on another. You must also prepare for the case where the certificate itself has been compromised. When this happens, it is likely that the certificate will be reissued with the same DN. The requirement is to universally revoke access for that specific certificate, but not necessarily for the DN associated with it. This cannot be addressed by SSLPEER or an exit because these operate only on the DN. Revocation in this case must be based on the cryptographic fingerprint of the certificate, and the mechanism that provides this functionality is a certificate revocation list (CRL).

The WebSphere MQ documentation explains how to set up a CRL, and there is a SupportPac (MQ01) with examples, so I won't describe that in detail here. At a high level, the CA provides a feed of revoked certificates. These are captured periodically (the product manuals recommend every 12 hours) and imported into a local database. During the SSL negotiation, the certificate being authenticated is checked against the local CRL. If a match is found, the connection is rejected.

It is important to remember that the matching of certificates in the CRL is based on the unique serial number of the certificate and not on the DN. For example, if a certificate with the distinguished name of DN="CN=GATEWAY,O=Vendor,OU=PROD,C=US" is revoked, this does not revoke certificates with the same DN, regardless of whether they are self-signed or issued by this or any other CA. That DN is still perfectly viable in every context, including the CA that revoked it; it is only the DN and fingerprint together (this one certificate) that is invalid.

The interaction between the trust store, the SSLPEER value and the CRL becomes very important in those cases where a channel needs to allow multiple certificates. In the best case, the trust store will consist entirely of self-signed certificates, or it will contain a single entry for a trusted CA and nothing else. With self-signed certificates, trust is granular down to individual certificates and can be revoked on a per-certificate basis. With a trust store consisting of a single trusted CA and nothing more, the CRL approaches an equivalent per-DN revocation capability in which revocation of the certificate effectively revokes access. I qualify this statement because the CA can always reissue the certificate with the same DN. The CRL alone provides some assurance that a DN is blocked, but an exit would be required to be sure. Also, it is customary to revoke a certificate only in the case that it is compromised and not simply as a means to revoke privileges.

Continuing the discussion of matching multiple certificates on a single channel, the situation gets worse with multiple CAs in the trust store. The set of potential SSLPEER matches for any given DN is at least as large as the number of CAs in the trust store, larger if certificate reissuance is taken into account. The CRL operates on a single certificate within that set. Use of a CRL is still mandatory to handle compromised certificates, but it is of very limited use in removing a DN from the match pool. An exit is the only option that gives any assurance of blocking a DN in this scenario.

Other issues when matching multiple certificates

An interesting side effect of using a certificate authority is that it externalizes the configuration required to connect to a queue manager. For example, suppose the administrator sets up SSLPEER to filter connections based on O=MyCompany, OU=WidgetsDivision, OU=PROD, and C=US. At this point, the question of whether something can successfully connect depends on possession of a certificate that will match the SSLPEER filter. This is compounded by the fact that the certificate may be "in the wild" on somebody's workstation or mobile computer with minimal physical access controls. If a single certificate is compromised, the MQ administrator cannot do anything at the queue manager to block it without affecting all the other legitimate users. The one thing that can help, the certificate revocation list, is also external to the queue manager.

This issue can be addressed with an exit. It would be possible for example, to provide a "good" list of acceptable DNs. Revoking one would be as simple as removing that entry from the list. Similarly, an exit can work in combination with SSLPEER. The allowable set of certificates would be defined in SSLPEER and the exit could contain an overriding set of blacklisted DNs. In this way, the MQ administrator has direct and immediate control over who can and cannot connect to the queue manager. Whether this level of control is necessary depends on the application. In too many cases, the decision is not made deliberately but rather because it is not well understood.

Using exits on cluster channels

When working with self-signed certificates, there is a one-to-one correspondence between a certificate and an identity. Revoking access privileges and revoking a certificate are functionally equivalent; removing the certificate from the trust store accomplishes both tasks. If the trust store contains only self-signed certificates, this functionality eliminates the need in most cases for SSLPEER filtering or processing of DNs with exits. On the other hand, the use of CA-issued certificates requires separate mechanisms for the tasks of revoking certificates and revoking privileges. Certificates are handled with the CRL, and privileges are granted or revoked by mechanisms that operate on the distinguished name. In several scenarios, such as a DN that exceeds the SSLPEER length or the need for wild-card matching, a channel exit is the only solution.

Before choosing this as your solution, be aware that when using exits on WebSphere MQ cluster channels, you will probably need both a security exit and a channel auto-definition (CHAD) exit. This is because the channel definition on the receiving side is propagated out to the sending side when the channel is established. If the two sides of the channel are on identical platforms, and the exit has the same name and is located in the same place, then everything works and no CHAD exit is required. However such a homogenous cluster is the exception rather than the norm. A CHAD exit is used to tailor the cluster channel definition to specify the security exit with the proper syntax for the local platform. In most clusters with a mix of platforms, the choices are to use self-signed certificates, write a CHAD exit, or live without the ability to revoke access per distinguished name.

A note about FIPS

The Federal Information Processing Standards (FIPS) specify, among other things, specific ciphersuites that are acceptable for use in US government installations. Many non-government shops also use FIPS as a baseline for their own secure configurations. To assist in configuring FIPS-compliant networks, the queue manager has an attribute called SSLFIPS that can be set to YES or NO. When set to YES, SSL channels are restricted to use only FIPS approved encryption algorithms. What administrators sometimes do not realize is that this setting has no affect whatsoever on non-SSL channels. These continue to operate exactly as they do when SSLFIPS(NO) is set.

The intent is to enable a mixed environment, where some channels use FIPS-approved SSL and others might use an exit. There are also cases where an existing network is migrated to SSL and contains both SSL and non-SSL channels for a period of time. In this case, setting SSLFIPS(YES) ensures that channels migrate directly to FIPS compliance even while legacy channels continue to operate without SSL.

Cryptographic strength

As mentioned earlier, messages and certificates make use of cryptographic hashes to verify integrity. The two hash types currently in use are MD5 and SHA1. Although the tooling in WebSphere MQ supports both of these, you should use only SHA hashes. Security researchers have recently demonstrated exploits against the MD5 algorithm which allowed them to forge usable certificates. To guard against such an attack, root and signer certificates based on the MD5 hash should not be trusted. If any exist in the trust store, they should be removed. In addition, it is advised to choose SHA1 for generation of self-signed certificates, certificate signing requests, and as the hashing component of the channel ciphersuite.

The size of the key is another factor that determines the reliability of the encryption. The larger the key, the greater the possible number of values and the harder it is to crack using brute force techniques. Be sure to choose key lengths of 1024 bits or greater.

Interactions with non-SSL configuration parameters

Enabling SSL on the channels does not, in itself, result in a reasonably secure queue manager. There are several other configurations that must be implemented in order for SSL protection to be meaningful. I have a favorite example of this that I illustrate when I give my presentation on WebSphere MQ hardening.

The story is about a financial clearing house that uses WebSphere MQ to connect to dozens of large financial institutions. Each institution has its own dedicated channel and each channel has a fully-specified SSLPEER value. The result is the ability to securely connect to each client institution, and assurance that the different clients could not hijack each other's channels. One day, one of the clients reported a channel problem. When the vendor went to investigate, they were surprised to find an unrecognized administrator signed on with WebSphere MQ Explorer. The administrator at the client institution had grown impatient and decided to see whether WebSphere MQ Explorer could connect to the vendor's queue manager in order to have a look around. Surprisingly it did, and with administrative authority.

The lesson here is that it is not sufficient to enable SSL on some of the channels on the queue manager. In order to be effective, every single inbound channel on the queue manager needs to be SSL enabled or else deactivated. This includes all channels of type RCVR, RQSTR, CLUSRCVR, SVR, and SVRCONN, and especially those named SYSTEM.DEF.* or SYSTEM.AUTO.* since these are perfectly usable and have well known names.

It is also important that any channel not intended to support administration of the queue manager have a low-privileged user ID in the MCAUSER attribute. This includes all the channel types mentioned above, except for SVR channels. If remote administration is allowed, it should be over a dedicated channel configured to only accept the certificates of people on the MQ administration team. All other access, whether from interactive users or from other queue managers, should arrive over a channel protected by a low-privileged MCAUSER. The reason for this is that the identity authenticated by the SSL exchange does not propagate to the MQ API. Unless overridden by MCAUSER, connections arriving over SVRCONN channels can assert any user ID, including an administrative one. SSL does not restrict that ability to assert an ID. The other inbound channel types, RCVR, RQSTR, and CLUSRCVR, always run with administrative rights unless overridden by MCAUSER. The MCAUSER can be set in the channel definition or dynamically by an exit. If an exit is used, the channel definition should contain MCAUSER('nobody') so that if the exit breaks, the channel will fail to an inoperable state.


Although the discussion here draws on generic SSL principles, this article is specific to WebSphere MQ and should not be applied in other contexts. For example, I have talked about the certificate DN as if there were only one. This is consistent with how the topic is treated in the WebSphere MQ manuals at the time of this writing. In fact, a standard X.509 certificate contains much more identity information and includes, among other things, the DN of the CA that issued the certificate. The DN referred to in this article is more properly known as the subjectDN. Some products expose more of the certificate identity to the administrator. Readers familiar, for example, with IBM WebSphere Application Server might have wondered why not simply include the issuerDN in the SSLPEER filter or in the matching criteria of an exit. After all, the combination of issuerDN and subjectDN should be universally unique within the pool of all possible DNs and would resolve many of the DN matching issues described here. The answer is that WebSphere MQ exposes only the subjectDN to the administrator or to an exit. The issuerDN (and even the certificate fingerprint) are not exposed either in the administrative commands or in the low-level exit interface. This results in a slightly different treatment of CAs in WebSphere MQ than in other products, and the requirement that the trust store contain that one CA and nothing else when using CA issued certificates. It would be possible for a pair of custom channel security exits to interrogate the certificate database to obtain and exchange additional certificate identity information, but that is well beyond the scope of this article.


Two recurring SSL problems are addressed in this article. The first is promiscuous connections, a situation where the channels accept a broad range of connections in addition to the intended ones. The second issue is SSL authenticated connections which unintentionally allow administrative privileges.

Some specific advice was provided to help with these issues:

  • Delete all unused certificate authorities from the trust store.
  • If the trust store contains a certificate authority, filter unwanted connections using SSLPEER or an exit, or both.
  • Limit the number of CAs that are trusted to (ideally) no more than one.
  • Use SSLCAUTH(REQUIRED) to ensure that clients are authenticated.
  • Anticipate the need for granular SSLPEER filtering by designing a naming convention for certificate distinguished names that contains useful organizational unit fields.
  • Practice DN filtering with self-signed certificates before settling on a naming convention.
  • Use self-signed certificates or exits if there is a need to match multiple DNs with fully qualified names.
  • Exits are required if the DN exceeds the SSLPEER length or when SSLPEER uses wild card matching.
  • Channel auto-definition exits are required to implement security exits on cluster channels in a mixed-platform cluster.
  • Establish a strategy in advance for revoking access by distinguished name as well as by individual certificate.
  • The use of a certificate revocation list is mandatory when using CA issued certificates.
  • Set SSLFIPS(YES) if FIPS compliance is an issue, but be aware that this does not disable non-SSL channels.
  • Disable all unused channels such as those named SYSTEM.DEF.* and SYSTEM.AUTO.*, by setting MCAUSER('nobody').
  • Insure that all inbound channels not intended to allow administrative access contain a value in the MCAUSER attribute.

There is plenty of documentation available that describes how to set up SSL, as well as a number of helpful tools. Many of these are in the Resources section to help you get started. Although I've provided a checklist here, I encourage you to build a couple of test queue managers and play around with SSL channels until you get a good feel for the capabilities of SSLPEER and understand how to revoke access, as well as how to grant it. Download BlockIP2 and play with it as well. Finally, get familiar with certificate revocation lists and the process for updating them. Then, when you are ready to start an SSL implementation or remediation project, you will have the background needed to build a comprehensive implementation plan and be able to avoid some of the common pitfalls.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Mission:Messaging: Planning for SSL on the WebSphere MQ network