XMS for .Net and SSL

[John Watson]

Although I have a simple .Net XMS application working, I am having very
great difficulty in converting it to use SSL. I have a keystore that works
very happily with an equivalent client-side JMS application. However with
XMS I am unsure:

1) Which IConnetionFactory properties I should set

2) When I attempt to set the XMSC.WMQ_SSL_KEY_REPOSITORY property, I get the
error: System.Exception {@"CWSMQ00007E: The specified value <filename> not
allowed for XMSC_WMQ_SSL_KEY_REPOSITORY. The given value is not allowed for
the property specified. Change the value to a value that is supported for
the property." This is pretty much the case irrespective of the value I
give for the key repository file name.

Has anyone any ideas

John Watson

[SaketR]

Currently MQ SSL only applies to Unmanaged client. This functionality is
not available for managed client (which is the default). This
functionality is not applicable for bindings mode, as there is no
network communication in bindings.

cf.SetIntProperty(XMSC.WMQ_CONNECTION_MODE, XMSC.WMQ_CM_CLIENT_UNMANAGED);

Also note:

Set channel to be the defined SSL channel on qm.

Following two SSL props are mandatory:

Set string property XMSC_WMQ_SSL_CIPHER_SPEC to be “RC4_MD5_US”, for
example.

Set string property XMSC_WMQ_SSL_KEY_REPOSITORY to be
@"D:\vs-workspace\ssl\key", for example.

(@ denotes no escape char interpolation in C# and saves escaping \)

Other XMSC_WMQ_SSL_* properties can be used for advanced functionality.

Finally, for more info see the XMS manual.

[John Watson]

Thanks, Saket. I've now set the UNMANAGED property. I'm still having
problems though setting the key repoitory. What is the object I must use?
I have a bunch of files generated with the java keytool in a directory named
c:\KeyDatabase\ROB. These are rob.key.kdb, rob.key.jks, rob.cert.arm etc.
etc. I've tried the full path name of the ROB directory, the key database
itself and also the java key store - all to no avail. For example:
QueueManager.SetStringProperty(XMSC.WMQ_SSL_KEY_REPOSITORY,
@"c:\KeyDatabase\ROB\rob.key.kdb");

I still get the message to say that it doesn't like the value I'm trying to
enter.

Post by SaketR
Currently MQ SSL only applies to Unmanaged client. This functionality is
not available for managed client (which is the default). This
functionality is not applicable for bindings mode, as there is no network
communication in bindings.
cf.SetIntProperty(XMSC.WMQ_CONNECTION_MODE, XMSC.WMQ_CM_CLIENT_UNMANAGED);
Set channel to be the defined SSL channel on qm.
Set string property XMSC_WMQ_SSL_CIPHER_SPEC to be “RC4_MD5_US”, for
example.
Set string property XMSC_WMQ_SSL_KEY_REPOSITORY to be
@"D:\vs-workspace\ssl\key", for example.
Other XMSC_WMQ_SSL_* properties can be used for advanced functionality.
Finally, for more info see the XMS manual.
--
Warm regards,
Saket
wastedmonkeys.com

[SaketR]

Post by SaketR
Set string property XMSC_WMQ_SSL_KEY_REPOSITORY to be
@"D:\vs-workspace\ssl\key", for example.

This assumes a physical file "D:\vs-workspace\ssl\key.kdb" exists (with
extension). The property is set without the extension.

[John Watson]

Thanks very much, Saket - this has taken me forward.....

I now do:
QueueManager.SetIntProperty(XMSC.WMQ_CONNECTION_MODE,
XMSC.WMQ_CM_CLIENT_UNMANAGED);

QueueManager.SetStringProperty(XMSC.WMQ_CHANNEL, "S_ROB");

QueueManager.SetStringProperty(XMSC.WMQ_SSL_CIPHER_SPEC,
"SSL_RSA_WITH_DES_CBC_SHA");

QueueManager.SetStringProperty(XMSC.WMQ_SSL_KEY_REPOSITORY,
@"c:\KeyDatabase\ROB\rob.key");

I now get a reason code 2393 (MQRC_SSL_INITIALIZATION_ERROR). Not sure how
to debug this - I've obviously supplied incorrect SSL parameters, but which
ones? Any ideas gratefully accepted.



John

Post by SaketR

Post by SaketR
Set string property XMSC_WMQ_SSL_KEY_REPOSITORY to be
@"D:\vs-workspace\ssl\key", for example.

This assumes a physical file "D:\vs-workspace\ssl\key.kdb" exists (with
extension). The property is set without the extension.
--
Warm regards,
Saket
wastedmonkeys.com

[John Watson]

sorry - cipher spec should read DES_SHA_EXPORT - still fails.

John

[SaketR]

Hi there,

My notes are based on v6, so if you're using v5.3 then I'm not sure.

According to 'WebSphere MQ Messages' book:

2393 (X'0959') MQRC_SSL_INITIALIZATION_ERROR
Explanation: An MQCONN or MQCONNX call was issued with SSL configuration
options specified, but an error occurred during the initialization of
the SSL environment.

This reason code occurs in the following environments:
AIX, HP-UX, Solaris, Windows.

Completion Code: MQCC_FAILED

Programmer Response: Check that the SSL installation is correct.

--

So, I assume you've a working GSKit installation, configured the channel
properties for SSL, and done the certificates create/export/import stuff.

I would recommend reading the 'Using .NET' book and 'WebSphere MQ
Security' book.

[Ian Burnett]

Post by John Watson
Thanks very much, Saket - this has taken me forward.....
QueueManager.SetIntProperty(XMSC.WMQ_CONNECTION_MODE,
XMSC.WMQ_CM_CLIENT_UNMANAGED);
QueueManager.SetStringProperty(XMSC.WMQ_CHANNEL, "S_ROB");
QueueManager.SetStringProperty(XMSC.WMQ_SSL_CIPHER_SPEC,
"SSL_RSA_WITH_DES_CBC_SHA");
QueueManager.SetStringProperty(XMSC.WMQ_SSL_KEY_REPOSITORY,
@"c:\KeyDatabase\ROB\rob.key");
I now get a reason code 2393 (MQRC_SSL_INITIALIZATION_ERROR). Not sure how
to debug this - I've obviously supplied incorrect SSL parameters, but which
ones? Any ideas gratefully accepted.

Do you have the GSkit installation on your Windows PATH variable? That's
my usual cause of SSL init errors. I think it gives a much more
descriptive error if your options are wrong (eg MQRC_SSL_CONFIG_ERROR).

Ian.

[John Watson]

Thanks, Ian. I placed both /Websphere MQ/gskit and Websphere
MQ/gskit/jre/bin on my path, but to no avail, I'm afraid. Is this what you
mean?

John

Post by Ian Burnett

Post by John Watson
Thanks very much, Saket - this has taken me forward.....
QueueManager.SetIntProperty(XMSC.WMQ_CONNECTION_MODE,
XMSC.WMQ_CM_CLIENT_UNMANAGED);
QueueManager.SetStringProperty(XMSC.WMQ_CHANNEL, "S_ROB");
QueueManager.SetStringProperty(XMSC.WMQ_SSL_CIPHER_SPEC,
"SSL_RSA_WITH_DES_CBC_SHA");
QueueManager.SetStringProperty(XMSC.WMQ_SSL_KEY_REPOSITORY,
@"c:\KeyDatabase\ROB\rob.key");
I now get a reason code 2393 (MQRC_SSL_INITIALIZATION_ERROR). Not sure
how to debug this - I've obviously supplied incorrect SSL parameters, but
which ones? Any ideas gratefully accepted.

Do you have the GSkit installation on your Windows PATH variable? That's
my usual cause of SSL init errors. I think it gives a much more
descriptive error if your options are wrong (eg MQRC_SSL_CONFIG_ERROR).
Ian.
--

[Ian Burnett]

Post by John Watson
Thanks, Ian. I placed both /Websphere MQ/gskit and Websphere
MQ/gskit/jre/bin on my path, but to no avail, I'm afraid. Is this what you
mean?

Putting the following onto my path works for me:

C:\Program Files\IBM\gsk7\lib

This directory contains the .dll files. Can't help any further, sorry.

Ian.

[SaketR]

Hi John,

I've put some notes I had as a blog entry. I haven't had a chance to
tidy it, but maybe you will find it interesting:

http://hursleyonwmq.wordpress.com/2007/05/24/xms-net-wmq-ssl-a-minimalist-cookbook/

[John Watson]

Thanks for taking the trouble to do this, Saket. I think I've followed your
instructions pretty closely. I still get the 2393 reason code, with a
helpful embedded exception of 'Application error'. I seem to get some
response server side - I see this in the error logs for the QM in question:

----- amqrmrsa.c :
459 --------------------------------------------------------
29/05/2007 12:00:47 - Process(9092.110) User(MUSR_MQADMIN)
Program(amqrmppa.exe)
AMQ9209: Connection to host 'sdgatewaydev (áf|
)' closed.

EXPLANATION:
An error occurred receiving data from 'sdgatewaydev (áf|
)' over TCP/IP.
The
connection to the remote host has unexpectedly terminated.
ACTION:
Tell the systems administrator.
----- amqccita.c :
3094 -------------------------------------------------------
29/05/2007 12:00:47 - Process(9092.110) User(MUSR_MQADMIN)
Program(amqrmppa.exe)
AMQ9492: The TCP/IP responder program encountered an error.

EXPLANATION:
The responder program was started but detected an error.
ACTION:
Look at previous error messages in the error files to determine the error
encountered by the responder program.
----- amqrmrsa.c : 459 ------------------------

Post by SaketR
Hi John,
I've put some notes I had as a blog entry. I haven't had a chance to tidy
http://hursleyonwmq.wordpress.com/2007/05/24/xms-net-wmq-ssl-a-minimalist-cookbook/
--
Warm regards,
Saket
wastedmonkeys.com

[John Watson]

Another thing I notice, Saket - in java/JMS you have to specify the password
into the key repository before you can use it. Is this not needed in XMS?

John

Post by SaketR
Hi John,
I've put some notes I had as a blog entry. I haven't had a chance to tidy
http://hursleyonwmq.wordpress.com/2007/05/24/xms-net-wmq-ssl-a-minimalist-cookbook/
--
Warm regards,
Saket
wastedmonkeys.com

[SaketR]

I don't quite remember whether I did that or not. Will have to try a
fresh setup to be sure!

[John Watson]

I've done a little more investigating - the Windows event monitor indicates
that it's failing with SSLPEER checking of the certificate provided by the
MQ server. I am hoping to do distinguished name checking at each end. The
value I provide to the XMS client for XMSC.WMQ_SSL_PEER_NAME is the
client-side peer name (if I provide the server side peer name here I get no
handshake at all). Error text contains the following.....

SSL distinguished name does not match peer name, channel S_ROB

The distinguished name <server-side distinguished name> contained in the SSL
certificate for the remote end of the channel does not match the local SSL
peer name for channel S_ROB.

I'm not sure how I switch on/off client-side peer checking anyway. Is it
picked up from the JNDI?

John

[John Watson]

I've now got this working at last. Nothing whatever wrong with the
certificates. Problem was twofold - firstly I was supplying an incorrect
SSL peer name, second was I was relying on setting the user id using
QueueManager.SetStringProperty(XMSC.USERID). I found instead it was
necessary to run under a login for the actual user. In either case, the SSL
error mesages were extremely misleading, and I arrived at the solution by
sheer persistence! Anyway, thanks for all your help.