I have one queue encrypted with PRIVACY quality encryption. I configure the keystore and exchange certificates between the source and target and the target is able to write to the source's queue securely. The queue is on the source and is encrypted with the source's key. The target writes to the source with the sources public key.
When I try to add a second target writer, i perform the same steps.. Exchanging the source and target public keys across both nodes. when the new target attempts to write to the queue it gets an AMQ9021E error. Which appears that the source fails to find the targets CN. However, I can see the CN in the same KDB used for the first target and I know that it can find this certificate because a NEW queue shared between source and target2 works without issue.
I tried using REFRESH SECURITY TYPE(SSL) on the source so it would refresh it's cache and allow the new messages to be read by target 2. Still doesn't seem to work.
Does anyone know what I might be missing?
From the logs:
AMQ9021E: An error occured during the certificate import for the following DN:
CN=3a04d052-1e48-430b-8e2c-de8da6644ea0,O=IBM,C=US, result: 57
EXPLANATION:
The distinguished name is not present in the keystore or invalid.
ACTION:
Consult the GSKit appendix in the Information Center for the explanation
of the GSKit reason code and take corrective action. If the problem persists,
contact your IBM service representative.
AMQ9017E: IBM MQ security policy internal error: message could not be unprotected: GSKit
error code 851968, reason 62.
EXPLANATION:
The IBM MQ security policy interceptor could not verify or decrypt a message
because the indicated GSKit error occurred. This can happen for several
reasons, all of which are internal failures: (1) the message is not a valid
PKCS#7 message; (2) the sender's certificate does not have the required key
usage bit to be able to encrypt the message; (3) the sender's certificate was
not recognized as a trusted certificate; (4) receiver is not among the
recipients of the message
ACTION:
Consult the GSKit information in the Information Center for the explanation of
the GSKit reason code and take corrective action. If the problem persists,
contact your IBM service representative.
policy Definition
[dsadm#kobe1 - Db2wh /]$ /opt/mqm/bin/dspmqspl -m IJPYQVAD_CQM
Policy Details:
Policy name: IJPYQVAD_ADMINQ
Quality of protection: PRIVACY
Signature algorithm: SHA256
Encryption algorithm: AES256
Signer DNs: -
Recipient DNs:
CN=996804c4-2fa6-4625-a4fd-acb8ab698b7f,O=IBM,C=US
Key reuse count: 0
Toleration: 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Related
I managed to get Microsoft Example 52 to work last friday. But after the weekend (from 13. January on) I get the following error:
Error refreshing OpenId configuration:
System.InvalidOperationException: IDX20803: Unable to obtain configuration from: 'https://login.botframework.com/v1/.well-known/openidconfiguration'.
at Microsoft.IdentityModel.Protocols.ConfigurationManager1.GetConfigurationAsync(CancellationToken cancel) at Microsoft.IdentityModel.Protocols.ConfigurationManager1.GetConfigurationAsync()
at Microsoft.Bot.Connector.Authentication.JwtTokenExtractor.ValidateTokenAsync(String jwtToken, String channelId, String[] requiredEndorsements)
...
Error refreshing OpenId configuration: System.InvalidOperationException: IDX20803: Unable to obtain configuration from: 'https://login.botframework.com/v1/.well-known/openidconfiguration'.
---> System.IO.IOException: IDX20804: Unable to retrieve document from: 'https://login.botframework.com/v1/.well-known/openidconfiguration'.
---> System.Net.Http.HttpRequestException: connection attempt failed because the remote peer did not respond properly after a certain period of time, or the established connection was faulty because the connected host did not respond.
---> System.Net.Sockets.SocketException (10060): A connection attempt failed because the remote terminal did not respond properly after a certain period of time, or the established connection was faulty because the connected host did not respond
-> By the way I translated the last two exceptions with deepl as they where in German
I already checked the forum and also documentation but with no luck.
Today I tried the example from scratch with different bot, different bot channels registration, and new copied example project but I still get the same error.
I still have to mention: The only difference to documentation is, that I registered bot and channel registration with another my azure user. And in teams I use an other account with office 365 business basic license. But last week it has worked - so maybe that's no problem at all!?!
Does anyone has an idea what to try next?
As per the comments above, this sounded like an issue with how the bot was hosted, and jwt validation code not being able to call out to the internet (e.g. a security or proxy setting). It needs to be able to physically call out to login.botframework.com/v1/.well-known/openidconfiguration . That might be fine on a local dev workstation, but blocked on an internal company server, for instance. In the end it was something in this line - proxy settings blocking the outgoing call, so listing it here as an answer for future visitors.
We have a single installation of WAS(8.5.5.10), with multiple clusters(JVMs). We enabled TLS1.2 on one of the JVMs, (say JVM1). But when I run the code sslSocket.getEnabledProtocols(), it gives me supported protocols=[TLSv1], which is V 1.0. My application runs on Java 1.7.
When I check in Security > SSL certificate and key management, and under Related Items, click SSL configurations. ( such as CellDefaultSSLsetting , NodedefaultSSLsetting and any other SSLConfig), it shows 'TLS' as the protocol, under QoP settings.
But when I check in SSL certificate and key management > Manage endpoint security configurations > jvm1_cluster, it shows 'TLS1.2' as SSL configuration.
From IBM forums, I came to understand that it is possible to enable TLSV1.2 at only one cluster. and need to use jssehelper to specify an outbound ssl configuration.
Tried following the link on how to programmatically specifying an outbound SSL configuration using JSSEHelper API. https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tsec_ssloutconfiguseJSSE.html
but I still could not get it to work. When I print the properties, I can see protocol as TLSV1.2 (com.ibm.ssl.protocol = TLSv1.2). Application uses com.ibm.jsse2.SSLSocketFactoryImpl for ssl socket provider.
To give you some background, am trying to connect to APNS using okhttp3 library. Am adding these properties, at the place where I create the socket connection. And after the socket is created, when I do sslSocket.getEnabledProtocols(), it gives me supported protocols=[TLSv1], which is V 1.0.
Since it tries to connect via TLS1, it gives javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure, when trying to establish connection to APNS. I have the certificate added to was store already and the firewall rules are in place as well, to allow the connection.
Error:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.ibm.jsse2.j.a(j.java:23)
at com.ibm.jsse2.j.a(j.java:21)
at com.ibm.jsse2.qc.b(qc.java:465)
at com.ibm.jsse2.qc.a(qc.java:451)
at com.ibm.jsse2.qc.h(qc.java:759)
at com.ibm.jsse2.qc.a(qc.java:353)
at com.ibm.jsse2.qc.startHandshake(qc.java:800)
Pls guide me on how to fix the issue. Thanks.
Guys I am trying to connect to MQ Hub from WAS Liberty application. Our MQ Hub supports only SSL certificate authentication. I have created QCF, Keystore with JKS file and with certificate inside it. Then I created defaultSSLConfig and pointed to that keystore.
But I could not find anyway to specify the SSLConfig in the QCF and read on some page that it was not possible. The only way was to use defaultSSLConfig and specify keystore from there which I did. So now I am here and MQ connection does not work. On the MQ Hub logs I see the error saying that "The channel is lacking a certificate to use for the SSL handshake."
This is how my QCF looks like, no parameter to specify an SSL config
<jmsConnectionFactory connectionManagerRef="ConMgr" jndiName="jms/wmqCF">
<properties.wmqJms channel="TEST_CHANNEL" hostName="REMOVED" port="1415" queueManager="ALQ.TEST" transportType="CLIENT" sslCipherSuite="SSL_RSA_WITH_AES_128_CBC_SHA"/>
</jmsConnectionFactory>
Full error on MQ side
EXPLANATION:
The channel is lacking a certificate to use for the SSL handshake. The
channel
name is 'XXX.ADM.SVRCONN' (if '????' it is unknown at this stage in the
SSL
processing).
The remote host is 'XXX (10.xx.xx.x)'.
The channel did not start.
ACTION:
Make sure the appropriate certificates are correctly configured in the
key
repositories for both ends of the channel.
----- amqccisa.c : 7355
02/14/17 15:07:44 - Process(7510.304808) User(mqm) Program(amqrmppa)
Host(xxx) Installation(Installation1)
VRMF(7.5.0.6) QMgr(XXXXX)
AMQ9999: Channel 'XXX.ADM.SVRCONN' to host 'xxx (10.xx.xx.xx)' ended
abnormally.
EXPLANATION:
The channel program running under process ID 7510 for channel 'XX.ADM.
SVRCONN'
ended abnormally. The host name is 'xx (10.xx.xx.xx)'; in some
cases the
host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error
logs to
determine the cause of the failure. Note that this message can be
excluded
completely or suppressed by tuning the "ExcludeMessage" or
"SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information
can be
found in the System Administration Guide.
It is working now :) What we think was the cause of the problem is this bug http://www-01.ibm.com/support/docview.wss?uid=swg1IT16056
Although the error in APAR above is not the same I was getting. I was seeing this error on the Liberty (client side)
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with
compcode '2' ('MQCC_FAILED') reason '2059' ('MQRC_Q_MGR_NOT_AVAILABLE').
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.
java:203)
I was using this resource adapter when the problem was manifesting itself: 9.0.1.0-IBM-MQ-Java-InstallRA.jar
Then we decided to try lower version of the adapter which had that APAR/fix in it and thus used this one: 8.0.0.6-WS-MQ-Java-InstallRA.jar
So that solved the problem.
I was pretty sure that the above bugfix was included in Ver 9.X of the resource adapter but as it turns out it is not the case.
I checked with IBM and they confirmed that APAR IT16056 is not included in the 9.0.1.0 CD release. They are working to correct the APAR to show the right target release for the fix.
Quote from IBM support is below.
I can confirm that the APAR in question, "IT16056" is NOT included in
the 9.0.1.0 CD release, and is currently targeted to be included in
the 9.0.2.0 CD release.
Based on this if you want you use a version of the RA higher than 8.0 you would need to do one of the following:
Wait until the 9.0 LTS (Long Term Support) 9.0.0.1 fixpack is released (IBM has a site where they list they are targeting 1Q 2017).
Wait until the 9.0 CD (Continuous Delivery) 9.0.2.0 release is out (IBM does not publish a target for CD)
Open a PMR to IBM and ask them for a IFIX to apply the 9.0.0.1 LTS or 9.0.1.0 CD release.
I want to import websphere MQ messages to my hadoop VM using Flume.I have not used MQ before and installed MQ version 8.0.0.4 on my windows machine and created JNDI binding . I have copied that JNDI binding file to the /etc/flume/conf location and created conf file for flume. Once i have started the Flume agent i am getting below error:-
Caused by: com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'JMSDEMO' with connection mode 'Client' and host name 'XXX.XXX.XX.XX(1414)'
Below are the errors in the Log file of Websphere MQ:-
4/20/2016 22:00:18 - Process(14396.9) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(armaan) Installation(Installation1)
VRMF(8.0.0.4) QMgr(JMSDEMO)
AMQ9245: Unable to obtain account details for channel MCA user ID.
EXPLANATION:
WebSphere MQ was unable to obtain the account details for MCA user ID 'root'.
This user ID was the MCA user ID for channel 'SYSTEM.DEF.SVRCONN' on queue
manager 'JMSDEMO' and may have been defined in the channel definition, or
supplied either by a channel exit or by a client.
ACTION:
Ensure that the user ID is correct and that it is defined on the Windows local
system, the local domain or on a trusted domain. For a domain user ID, ensure
that all necessary domain controllers are available.
----- cmqxrsrv.c : 2140 -------------------------------------------------------
4/20/2016 22:00:18 - Process(6376.20) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(armaan) Installation(Installation1)
VRMF(8.0.0.4) QMgr(JMSDEMO)
AMQ7227: WebSphere MQ encountered the following network error: The trust
relationship between this workstation and the primary domain failed.
EXPLANATION:
MQ failed to successfully complete a network operation due to the specified
error. If the error is encountered on systems that are part of a Windows 2000
domain it can indicate incorrect DNS or WINS configuration.
ACTION:
Ensure that your network is functioning correctly. On the Windows platform
check DNS and/or WINS settings to ensure that domain controllers, used for
authentication or authorisation functions, are accessible.
----- amqxsecn.c : 5125 -------------------------------------------------------
4/20/2016 22:00:18 - Process(6376.20) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(armaan) Installation(Installation1)
VRMF(8.0.0.4) QMgr(JMSDEMO)
AMQ8075: Authorization failed because the SID for entity 'root' cannot be
obtained.
EXPLANATION:
The Object Authority Manager was unable to obtain a SID for the specified
entity. This could be because the local machine is not in the domain to locate
the entity, or because the entity does not exist.
ACTION:
Ensure that the entity is valid, and that all necessary domain controllers are
available. This might mean creating the entity on the local machine.
----- amqzfubn.c : 2421 -------------------------------------------------------
4/20/2016 22:00:18 - Process(6376.20) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(armaan) Installation(Installation1)
VRMF(8.0.0.4) QMgr(JMSDEMO)
AMQ7227: WebSphere MQ encountered the following network error: The trust
relationship between this workstation and the primary domain failed.
EXPLANATION:
MQ failed to successfully complete a network operation due to the specified
error. If the error is encountered on systems that are part of a Windows 2000
domain it can indicate incorrect DNS or WINS configuration.
ACTION:
Ensure that your network is functioning correctly. On the Windows platform
check DNS and/or WINS settings to ensure that domain controllers, used for
authentication or authorisation functions, are accessible.
----- amqxsecn.c : 5125 -------------------------------------------------------
4/20/2016 22:00:18 - Process(6376.20) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(armaan) Installation(Installation1)
VRMF(8.0.0.4) QMgr(JMSDEMO)
AMQ8075: Authorization failed because the SID for entity 'root' cannot be
obtained.
EXPLANATION:
The Object Authority Manager was unable to obtain a SID for the specified
entity. This could be because the local machine is not in the domain to locate
the entity, or because the entity does not exist.
ACTION:
Ensure that the entity is valid, and that all necessary domain controllers are
available. This might mean creating the entity on the local machine.
----- amqzfubn.c : 2421 -------------------------------------------------------
4/20/2016 22:00:18 - Process(14396.9) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(armaan) Installation(Installation1)
VRMF(8.0.0.4) QMgr(JMSDEMO)
AMQ9557: Queue Manager User ID initialization failed for 'root'.
EXPLANATION:
The call to initialize the User ID 'root' failed with CompCode 2 and Reason
2035.
ACTION:
Correct the error and try again.
----- cmqxrsrv.c : 2321 -------------------------------------------------------
I have submitted the flume command from VM as root user.
I know i had done something wrong with MQ settings as i have noprevious experience with MQ . Please help .
I know i had done something wrong with MQ settings as i have
no previous experience with MQ.
How about doing some self-training and read the documentation. There is a whole section in the MQ Knowledge Center about MQ & JMS. Please read it here. Or you could go to the largest conference in the world solely dedicated to IBM MQ (aka WebSphere MQ & MQSeries) - MQ Technical Conference v2.0.1.6.
Just put the credentials as follows:
QueueConnection conn = cf.createQueueConnection(userID, password);
I try to install WebSphere MQ v8 on Centos 7... I did have no problem instaling the server and test it. When I try to configure client every is OK until I try to put a message at queue with the following command: ./amqsputc queue manager. Here part of the log file.
-------------------------------------------------------------------------------
08/01/15 13:16:17 - Process(37991.4) User(mqm) Program(amqrmppa)
Host(localhost.localdomain) Installation(Installation1)
VRMF(8.0.0.0) QMgr(my.manager)
AMQ9776: Channel was blocked by userid
EXPLANATION: The inbound channel 'CANAL1' was blocked from address
'127.0.0.1' because the active values of the channel were mapped to a
userid which should be blocked. The active values of the channel were
'MCAUSER(mqm) CLNTUSER(mqm) ADDRESS(localhost)'. ACTION: Contact the
systems administrator, who should examine the channel authentication
records to ensure that the correct settings have been configured. The
ALTER QMGR CHLAUTH switch is used to control whether channel
authentication records are used. The command DISPLAY CHLAUTH can be
used to query the channel authentication records.
----- cmqxrmsa.c : 1257 -------------------------------------------------------
08/01/15 13:16:17 - Process(37991.4) User(mqm) Program(amqrmppa)
Host(localhost.localdomain) Installation(Installation1)
VRMF(8.0.0.0) QMgr(my.manager)
AMQ9999: Channel 'CANAL1' to host '127.0.0.1' ended abnormally.
EXPLANATION: The channel program running under process ID 37991 for
channel 'CANAL1' ended abnormally. The host name is '127.0.0.1'; in
some cases the host name cannot be determined and so is shown as
'????'. ACTION: Look at previous error messages for the channel
program in the error logs to determine the cause of the failure. Note
that this message can be excluded completely or suppressed by tuning
the "ExcludeMessage" or "SuppressMessage" attributes under the
"QMErrorLog" stanza in qm.ini. Further information can be found in the
System Administration Guide.
----- amqrmrsa.c : 925 --------------------------------------------------------
I appreciate all the help you can give me, thanks in advance.
It is very easy to troubleshoot the reasons why you have been blocked by a CHLAUTH rule. There is a blog post on it, I'm being blocked by CHLAUTH - how can I work out why?
However, I can tell you from here exactly which rule is blocking you, it is the default rule which bans remote privileged access, i.e. mqm access from client connections. If you want to have access without being privileged, read A non-privileged MQ administrator, and alternatively if you do want to allow the risky remote access from privileged users, read CHLAUTH - Allow some privileged admins
It's worth noting MQ v8 doesn't support CentOS at all, and hasn't declared support for RHEL 7 either.
http://www-969.ibm.com/software/reports/compatibility/clarity-reports/report/html/softwareReqsForProduct?deliverableId=1350550241693&osPlatform=Linux
At time of writing MQ v8 supports the following Linux distros:
Asianux 3.0
RHEL 6
SLES 11
Ubuntu 12.04
That said, the error 'AMQ9776: Channel was blocked by userid' you pasted above show that your client is failing the channel authentication checks.
You can check this by disabling channel authentication via the following MQSC command:
'ALTER QMGR CHLAUTH(DISABLED)'
There's a good article on developerworks that explains how to work out why your connection attempt was blocked you can look at here:
https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/blocked_by_chlauth_why?lang=en