I have done an SSL configuration for my IBM MQ v9, created a Java client, and added the certificates both sides. A Put and Get messages works fine. My issue is I'm able to browse the message using the MQ Explorer in the server. Is it because the message is decrypted and shown? Can I keep this message encrypted to a MQ Admin user who has access to the MQ explorer.
Any advice is very much appreciated.
Thanks in advance,
Yasothar
Configuring encryption at the channel level only encrypts data in motion (on the network).
Messages on a queue are not encrypted unless you do this at the application layer or use the IBM MQ Advanced Message Security (AMS) extension of the product, this requires additional configuration with different certs to represent the putting and getting applications as well as policies to tell MQ AMS what to encrypt and who can receive.
Even with IBM MQ AMS configured, someone with MQ admin authority can still override configurations to allow viewing of messages sent, since the the MQ admin controls the policy, so can easily add themselfs as a new recipient so they can also view message that are sent.
Related
can anyone clarify what the MQ "Prot Algorithm" bit of the ECapFlags3 struct is for and/or does, and why and when it gets set by IBM MQ during a connection setup?
At a high level, we're implementing an SSL offload configuration for a client (Mulesoft) to connect to an IBM MQ queue via an F5. Whenever we enable SSL, the connection fails. With TLS off, the data flow works fine. (it's not something basic, like not sharing an acceptable cipher, etc. - the TLS handshake completes between the Mulesoft client and the F5 fine, and data flows - but the client appears to stop the connection). We don't see any difference in what the F5 sends over to IBM MQ in either case; the only difference we can find is that the IBM MQ replies all have the ECapFlags3 "Prot Algorithm" bit set, when TLS is enabled between the client and the F5.
In performing captures, we note the following:
With TLS on, the TLS handshake completes apparently without issue, and MQ packets do go over to the IBM MQ
With TLS on, we see two "INITIAL_DATA" MQ requests go over, and receive responses back; immediately after that, the client sends a TLS alert
With TLS off, we see the same two INITIAL_DATA messages and responses, then the client sends credentials (i.e., sends a "USERID_DATA" message)
We see no unexpected differences in the first 2 exchanges (the INITIAL_DATA calls) with or without TLS, except that the MQ reply, to both INITIAL_DATA calls, has the msb of the ECapFlags3 set; this bit is labeled as "Prot Algorithm" by Wireshark
The whole exchange happens within 300ms when successful (no TLS), and within less when TLS is enabled, so no timeout should be occurring.
Our working hypothesis is that the "Prot Algorithm" bit being set is having some effect on the client; correction would involve either preventing it from being set, or adjusting the client configuration to handle it cleanly.
Any information on that flag bit - or any other thoughts! - welcome. Thank you!
We're running Websphere MQ 9.1 and our Telemetry (MQTT) channel is configured to require SSL Authentication.
Our certificates have lifespans of just a few months and we want to automate the process of replacing these certificates. I can easily create a new .kdb file and place in the SSLKEYR location, but this doesn't automatically make the channel use the new certificates.
I have tried the REFRESH SECURITY TYPE(SSL) command and this command succeeds (output: AMQ8560I: IBM MQ security cache refreshed.) I would think this should work, see: https://www.ibm.com/docs/en/ibm-mq/9.1?topic=authorities-refreshing-tls-security
Refreshing TLS security
If you make a change to the key repository, you can refresh the copy of the key repository that is held in memory while a channel is running, without restarting the channel. When you refresh the cached copy of the key repository, the TLS channels that are currently running on the queue manager are updated with the new information.
About this task
When a channel is secured using TLS, the digital certificates and their associated private keys are stored in the key repository. A copy of the key repository is held in memory while a channel is running. If you make a change to the key repository, you can refresh the copy of the key repository that is held in memory without restarting the channel.
When you refresh the cached copy of the key repository, all TLS channels that are currently running are updated:
Sender, server, and cluster-sender channels that use TLS are allowed to complete the current batch of messages. The channels then run the SSL handshake again with the refreshed view of the key repository.
All other channel types that use TLS are stopped. If the partner end of the stopped channel has retry values defined, the channel retries and runs the SSL handshake again. The new SSL handshake uses the refreshed view of the contents of the key repository, the location of the LDAP server to be used for the Certificate Revocation Lists, and the location of the key repository. In the case of server-connection channel, the client application loses its connection to the queue manager and has to reconnect to continue.
However - when I replace the KDB with a keyrepository with different certificates and I refresh the security, my clients still reconnect after I purge them from the channel. When I restart the channel, the clients stay offline as expected.
Why doesn't refresh security work in this case (because its a telemetry channel?) and is there a way to solve this puzzle without stopping and starting the channel?
In IBM MQ, MQTT components are called MQXR. There are 3 log files you can check:
(1)
Windows: {MQ_DATA_PATH}\qmgrs\{qmgr_name}\mqxr.stdout
Windows: {MQ_DATA_PATH}\qmgrs\{qmgr_name}\mqxr.stderr
Unix: {MQ_DATA_PATH}/qmgrs/{qmgr_name}/mqxr.stdout
Unix: {MQ_DATA_PATH}/qmgrs/{qmgr_name}/mqxr.stderr
(2)
Windows: {MQ_DATA_PATH}\qmgrs\{qmgr_name}\errors\mqxr_0.log
Unix: {MQ_DATA_PATH}/qmgrs/{qmgr_name}/errors/mqxr_0.log
The log file mqxr_0.log should have any error messages related to refreshing security.
Here's an interesting note from the MQ Knowledge Center:
All other channel types using TLS are stopped with a STOP CHANNEL MODE(FORCE) STATUS(INACTIVE) command. If the partner end of the stopped message channel has retry values defined, the channel retries and the new TLS handshake uses the refreshed view of the contents of the TLS key repository, the location of the LDAP server to be used for Certification Revocation Lists, and the location of the key repository. In the case of a server-connection channel, the client application loses its connection to the queue manager and has to reconnect in order to continue.
So, you issuing the stop channel command is basically what the note said the refresh security command will do.
Finally, you should probably open a PMR (help ticket) with IBM to see what they say and possibly fix the issue if it is a bug.
i'm trying to connect my VB.net application to Remote Queue Manager.
but keep getting the followig Erorr: MQRC_Q_MGR_NAME_ERROR. can anyone tell me what i'm doing wrong?
here is the code i'm using:
Dim mqQMgr As MQQueueManager = Nothing
Dim props As New Hashtable()
props.Add(MQC.HOST_NAME_PROPERTY, "192.168.28.191")
props.Add(MQC.CHANNEL_PROPERTY, "SYSTEM.ADMIN.SVRCONN")
props.Add(MQC.USER_ID_PROPERTY, "AQ")
props.Add(MQC.PORT_PROPERTY, 1313)
props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_BINDINGS)
mqQMgr = New MQQueueManager("QMSEPAM", props)
i also tried differentconnection method (MQC.TRANSPORT_MQSERIES_CLIENT) and i get the following error:
"MQRC_NOT_AUTHORIZED"
Thanks in advance.
You need to set MQC.TRANSPORT_PROPERTY property to MQC.TRANSPORT_MQSERIES_MANAGED or MQC.TRANSPORT_MQSERIES_CLIENT for connecting through TCP/IP socket to a queue manager that is running on a remote machine or on the same machine as your application . The MQC.TRANSPORT_MQSERIES_BINDINGS should be used only when the queue manager is running on the same machine as your application in which case your application would communicate with queue manager using shared memory.
The MQRC_NOT_AUTHORIZED (2035) is thrown if the user with which your application is attempting to connect to a remote queue manager does not have authority. There are multiple ways of providing access to queue manager, talk to your IBM MQ Administrator to provide you the required authority. Take a look at this link. BTW what version of MQ are you using?
Update: Two points
1) Is user AQ same as logged in user of the machine where the .NET application is running? MQ .NET v7.5 sends the logged in user id to queue manager for authorization unless you are using a security exit. If you are not using any security exit then the logged in user id must exist on remote machine and has authorizations to connect.
2) Do not add user to mqm as users in that group are blocked from connecting to queue manager by the Channel Authentication feature
There are couple of posts in SO that you can read:
WebSphere MQ v7.1 Security User Credentials
MQRC_NOT_AUTHORIZED error while connecting to Websphere MQ 7.1
Finally if you are just testing out your application and do not really need user id authorization, then you can disable channel authentication by running the below runmqsc command.
ALTER QMGR CHLAUTH (DISABLED)
I am trying to demonstrate to others that my queue is using SSL, however from the RabbitMQ web management tools there seems to be no distinction over which queues are using SSL and which are not.
Using RabbitMQ management on localhost, I am able to see all my queues. I have set up SSL on port 5671 successfully using the troubleshooting from RabbitMQ website.
Using MassTransit I have configured my incoming bus to use localhost:5671/my_queue_name with a client certificate and all is working successfully - I just can't confirm to others that the queue is secure. If I get a message from the queue using the web management tools, I can read the (JSON) message in plain text. Any ideas how I can prove my messages are secure?
I've attempted using BusDriver to peek the queues but get nothing back (independent of whether is SSL or not).
SSL is used to secure connections, not to encrypt queue contents.
What SSL gives you is that communication from clients to RabbitMQ will be encrypted, so you could theoretically be sure that nobody tampered with your messages.
Also if you need to validate that the sender of the message is a particular user, you could use this RabbitMQ extension: http://www.rabbitmq.com/validated-user-id.html
As the title says - i have 3 servers:
server-1 [wcf services]
server-2 [wcf services]
server-3 [esb using rhino.esb]
So -
server 1 publishes message to server-3 esb
server 2 subscribes to messages from server 1 via server-3 esb
do they all need to be in the same domain or anything?
For security there is no difference between public and private queues - "public" just means published in Active Directory.
Also, you need to differentiate between "different domain" and "different forest". I assume you mean the latter. Two domains in the same forest share the same security database so would not be a problem.
Do not regard Access Control Lists on queues as being a robust form of security. A message can be sent with the SID of any account to get round the queue permissions. Authentication with internel (MSMQ) or external certificates is a much better alternative if security is an issue.
How to send authenticated MSMQ messages without using a domain account
Authenticating MSMQ messages between forests
Cross-forest MSMQ? You need to be trusting
"How do I send MSMQ messages between domains?"
Understanding how MSMQ security blocks RPC traffic
Cheers
John Breakwell
No. But its less secure or more complicated. Depending if you are using no security ( everyone has access) or certificates.
Look at Securing Messages Using Transport Security.
Private queues are just accessed via a TCP port, so there is no need for the hosting server to even be on a domain for the MSMQ queue to be accessible. However, I would recommend that you apply transport-level security at the network layer (i.e. firewalls) to prevent any unauthorised traffic from putting messages on / retrieving from the queues.