MQSeries.net :: View topic - amqssslc ended 2393, while conn via MQ Explorer CCDT is OK

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » amqssslc ended 2393, while conn via MQ Explorer CCDT is OK

Goto page 1, 2 Next

amqssslc ended 2393, while conn via MQ Explorer CCDT is OK

« View previous topic :: View next topic »

Author

Message

t603

Posted: Mon Mar 31, 2014 2:04 am Post subject: amqssslc ended 2393, while conn via MQ Explorer CCDT is OK

Voyager

Joined: 16 Oct 2012
Posts: 88
Location: Prague, the Czech Republic, Europe

Good afternoon,

I have a problem with connection to the AIX MQ Server, command level 7.0.1, secured by SSL from my MS Windows terminal server using C binary applications like amqssslc and qload.

The connection should not be the problem, because I can connect to the same AIX MQ Server from the same MS Windows terminal server using MQ Explorer, version 7.5.0.2, via CCDT. So I suppose, that the problem is between the chair and the keyboard = in the way, how I call amqssslc and qload.

Could You please point me to the mistake, I am doing, while calling amqssslc and qload? At least I suppose, I should provide somewhere passwords for JKS like javax.net.ssl.(key|trust)StorePassword setting passwords for Java applications while connectiong to Broker using .broker XML files. But I did not find any remark about providing passwords for C programs.

Thank You in advance for Your answer, Stepan

Calling my apps:

Code:

set MQCCSID=912
set MQIPADDRV=MQIPADDR_IPV4
set MQCHLLIB=C:\temp\qload
set MQCHLTAB=BK1.QM_integr.unix.csob.cz.tab

set MQSSLKEYR=C:\temp\qload\key

cd "C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin"

rem https://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzal.doc/fg17940_.htm
amqscnxc -x integr.unix.csob.cz -c SCC_SYS BK1.QM

rem https://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzal.doc/fg20740_.htm
amqssslc -m BK1.QM -c SCC_SYS -x integr.unix.csob.cz -k "c:\temp\qload\key" -s NULL_SHA -o http://dummy.OCSP.responder

cd "C:\temp\qload"

qload -m BK1.QM -i CSOBI.TEST.TO -f out.txt -l mqic32

The result:

Code:

C:\temp\qload>set MQCCSID=912

C:\temp\qload>set MQIPADDRV=MQIPADDR_IPV4

C:\temp\qload>set MQCHLLIB=C:\temp\qload

C:\temp\qload>set MQCHLTAB=BK1.QM_integr.unix.csob.cz.tab

C:\temp\qload>set MQSSLKEYR=C:\temp\qload\key

C:\temp\qload>cd "C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin"

C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin>rem https://publib.
boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzal.doc/fg17940_.htm

C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin>amqscnxc -x integr.u
nix.csob.cz -c SCC_SYS BK1.QM
Sample AMQSCNXC start
Connecting to queue manager BK1.QM
using the server connection channel SCC_SYS
on connection name integr.unix.csob.cz.
MQCONNX ended with reason code 2393

C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin>rem https://publib.b
oulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzal.doc/fg20740_.htm

C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin>amqssslc -m BK1.QM -
c SCC_SYS -x integr.unix.csob.cz -k "c:\temp\qload\key" -s NULL_SHA -o http://du
mmy.OCSP.responder
Sample AMQSSSLC start
Connecting to queue manager BK1.QM
Using the server connection channel SCC_SYS
on connection name integr.unix.csob.cz.
Using SSL CipherSpec NULL_SHA
Using SSL key repository stem c:\temp\qload\key
Using OCSP responder URL http://dummy.OCSP.responder
MQCONNX ended with reason code 2393

C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin>cd "C:\temp\qload"

C:\temp\qload>qload -m BK1.QM -i CSOBI.TEST.TO -f out.txt -l mqic32
QLOAD Program by Paul Clarke [ V1.9 Build:Jun 19 2012 ]
MQCONN on object 'BK1.QM' returned 2393 SSL initialisation error.

C:\temp\qload>pause 1000
Press any key to continue . . .

Tibor

Posted: Mon Mar 31, 2014 3:39 am Post subject:

Grand Master

Joined: 20 May 2001
Posts: 1033
Location: Hungary

MQExplorer uses JKS format, a native MQ code (client or server) a KDB.

...and check your local AMQERR01.LOG file for errors.

fjb_saper

Posted: Mon Mar 31, 2014 6:23 am Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Tibor wrote:

MQExplorer uses JKS format, a native MQ code (client or server) a KDB.

...and check your local AMQERR01.LOG file for errors.

You need to copy your JKS to a KDB (CMS type). Assign it a stashfile, set the corresponding environment variables for the CCDT, the Keyring etc... (Read up in the infocenter).

Have fun

_________________
MQ & Broker admin

t603

Posted: Mon Mar 31, 2014 8:27 am Post subject:

Voyager

Joined: 16 Oct 2012
Posts: 88
Location: Prague, the Czech Republic, Europe

Hello,

thank You for Your hints, but I guess, that it should be some other reason. Because:

1) I create again (just now) KDB (CMS type) file using iKeyman 8.0.373, CMS 1.3.6, Java 1.6.0, GUI from those one JKS, which I am using in MQ Explorer together with CCDT. I created it on MS Windows (client system). Files key.kdb, key.rdb and key.sth were created. No other security files other that jsk, kdb, rdb, sth are presented in client side directory. I did it just only on client side, because I suppose, that if MQ Explorer + JKS works OK, then amqssslc + KDB should work also.

2) The server side SSL configuration was made by my ex colleague. I have no idea about what he did. But I suppose, that if MQ Explorer + JKS works OK, then amqssslc + KDB should work also.

3) I just created client channel using command

Code:

DEFINE CHANNEL(SCC_SYS) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME(integr.unix.csob.cz) QMNAME(BK1.QM) REPLACE
REFRESH SECURITY TYPE(SSL)

4) I even started and stopped server channel, although I guess, it should solve nothing. I can not restart whole MQ server just for my pleasure.

5) After all of above, I got now the following error in AMQERR01.LOG on the client side (MS Windows):

Code:

----- amqccisa.c : 6758 -------------------------------------------------------
31.3.2014 18:21:20 - Process(10524.1) User(jd33148) Program(qload.exe)
Host(CZASPTW055) Installation(Installation1)
VRMF(7.5.0.2)
AMQ9633: ChybnÃ½ certifikÃ¡t SSL pro kanÃ¡l 'SCC_SYS'.

VYSVĚTLENÃ:
CertifikÃ¡t zjiÅ¡těnÃ½ v průběhu navÃ¡zÃ¡nÃ komunikace SSL vÃ½měnou potvrzenÃ je z
jednoho z nÃ¡sledujÃcÃch důvodů povaÅ¾ovÃ¡n za chybnÃ½:
(a) byl nesprÃ¡vně formÃ¡tovÃ¡n a nebylo moÅ¾nÃ© jej ověřit;
(b) byl formÃ¡tovÃ¡n sprÃ¡vně, ale selhalo ověřenÃ proti kořeni certifikačnÃ
autority (CA) a dalÅ¡Ãm certifikÃ¡tům v lokÃ¡lnÃm systÃ©mu;
(c) byl nalezen v seznamu odvolanÃ½ch certifikÃ¡tů (CRL) na serveru LDAP;
(d) seznam odvolanÃ½ch certifikÃ¡tů (CRL) byl určen, ale nebyl nalezen na serveru
LDAP;
(e) odpovÃdacÃ modul protokolu OCSP indikuje, Å¾e byl odvolÃ¡n;

NÃ¡zev kanÃ¡lu je 'SCC_SYS'. V některÃ½ch přÃpadech nÃ¡zev nelze určit a zobrazÃ se
jako '????'. VzdÃ¡lenÃ½ hostitel je 'integr (10.242.168.16)(1414)'. KanÃ¡l nebyl
spuÅ¡těn.

Podrobnosti danÃ©ho certifikÃ¡tu, kterÃ© nemohly bÃ½t ověřeny, jsou '????'.

Chyba ověřenÃ platnosti certifikÃ¡tu byla 575010.
AKCE:
Zkontrolujte, kterÃ¡ z moÅ¾nÃ½ch přÃčin se vztahuje na vÃ¡Å¡ systÃ©m. Opravte chybu a
spusťte kanÃ¡l znovu.
----- amqccisa.c : 6758 -------------------------------------------------------

which I found in English means:

Code:

EXPLANATION:
A certificate encountered during SSL handshaking is regarded as bad for one of
the following reasons:
(a) it was formatted incorrectly and could not be validated
(b) it was formatted correctly but failed validation against the Certification
Authority (CA) root and other certificates held on the local system
(c) it was found in a Certification Revocation List (CRL) on an LDAP server
(d) a CRL was specified but the CRL could not be found on the LDAP server
(e) an OCSP responder has indicated that it is revoked

when I am running these commands:

Code:

C:\temp\qload>set MQCCSID=912

C:\temp\qload>set MQIPADDRV=MQIPADDR_IPV4

C:\temp\qload>set MQCHLLIB=C:\temp\qload

C:\temp\qload>set MQCHLTAB=BK1.QM_integr.unix.csob.cz.tab

C:\temp\qload>set MQSSLKEYR=C:\temp\qload\key

C:\temp\qload>cd "C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin"

C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin>rem https://publib.
boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzal.doc/fg17940_.htm

C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin>rem amqscnxc -x inte
gr.unix.csob.cz -c SCC_SYS BK1.QM

C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin>rem https://publib.b
oulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzal.doc/fg20740_.htm

C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin>amqssslc -m BK1.QM -
c SCC_SYS -x integr.unix.csob.cz -k "C:\temp\qload\key" -s NULL_SHA -o http://du
mmy.OCSP.responder
Sample AMQSSSLC start
Connecting to queue manager BK1.QM
Using the server connection channel SCC_SYS
on connection name integr.unix.csob.cz.
Using SSL CipherSpec NULL_SHA
Using SSL key repository stem C:\temp\qload\key
Using OCSP responder URL http://dummy.OCSP.responder
MQCONNX ended with reason code 2393

C:\Program Files (x86)\IBM\WebSphere MQ\tools\c\Samples\Bin>cd "C:\temp\qload"

C:\temp\qload>qload -m BK1.QM -i CSOBI.TEST.TO -f out.txt -l mqic32
QLOAD Program by Paul Clarke [ V1.9 Build:Jun 19 2012 ]
MQCONN on object 'BK1.QM' returned 2393 SSL initialisation error.

C:\temp\qload>pause 1000
Press any key to continue . . .

6) Because we do not use CLR just now on acceptance, just point a), b) or e) could be the reason. And I have no idea, how to determine the correct reason and moreover how to repair it.

fjb_saper

Posted: Mon Mar 31, 2014 8:07 pm Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

When you created the CMS type did you get a *.crl file?

_________________
MQ & Broker admin

t603

Posted: Mon Mar 31, 2014 9:32 pm Post subject:

Voyager

Joined: 16 Oct 2012
Posts: 88
Location: Prague, the Czech Republic, Europe

fjb_saper wrote:

When you created the CMS type did you get a *.crl file?

No, iKeyman did not create any CRL file during convertsion JKS to KDB described tommorrow in my post as at Mon Mar 31, 2014 3:27 pm. Just these files were created: key.kdb, key.rdb and key.sth.

Is CRL necessary? Even I read http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzas.doc%2Fsy12740_.htm, I am not sure, if it means, that I have to setup LDAP filled with blank CRL on the client side. Hope not, when JKS does not need it. As I understand, implementation of CRL is voluntary for MQ, am I true?

t603

Posted: Tue Apr 01, 2014 12:16 am Post subject:

Voyager

Joined: 16 Oct 2012
Posts: 88
Location: Prague, the Czech Republic, Europe

One more think I would like to point - in the AMQERR01.LOG is the code of the SSL error, which is 575010, so it according to the http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.tro.doc/q049080_.htm means:

Code:

575010 No certificate chain was built

So I suppose, that it should not deal with CRL, because there are other specific error sodes for CRL errors.

But I have no idea, what means "No certificate chain was built" - it sounds too general for me.

zpat

Posted: Tue Apr 01, 2014 12:33 am Post subject:

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

Also you can turn off OCSP contact in qm.ini

Code:

SSL: ; SSL parms
OCSPCheckExtensions=No ; Do not try to contact OCSP server
OCSPAuthentication=WARN

No point trying to contact the OCSP server if your firewall blocks it.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.

Tibor

Posted: Tue Apr 01, 2014 3:48 am Post subject:

Grand Master

Joined: 20 May 2001
Posts: 1033
Location: Hungary

t603 wrote:

But I have no idea, what means "No certificate chain was built" - it sounds too general for me.

It means, there is no relation between your certificate and CA (signer).

t603

Posted: Tue Apr 01, 2014 4:14 am Post subject:

Voyager

Joined: 16 Oct 2012
Posts: 88
Location: Prague, the Czech Republic, Europe

zpat wrote:

Also you can turn off OCSP contact in qm.ini
No point trying to contact the OCSP server if your firewall blocks it.

I did it just now. My qm.ini on the server side contains now

Code:

SSL:
OCSPAuthentication=OPTIONAL
OCSPCheckExtensions=No

Then I ran in MQ Explorer: connected QM -> right mouse click -> Security -> Refresh SSL... I did not run "Refresh Autorization Service...".

I also created mqclient.ini and set up

Code:

set MQCLNTCF=C:\temp\qload\mqclient.ini

. This whole file looks like

Code:

OCSPCheckExtensions=No
OCSPAuthentication=Warn

.

And this again does not help, still the error is 575010

Tibor

Posted: Tue Apr 01, 2014 4:24 am Post subject:

Grand Master

Joined: 20 May 2001
Posts: 1033
Location: Hungary

I am sure that "575010 No certificate chain was built" is option (b):

(b) it was formatted correctly but failed validation against the Certification Authority (CA) root and other certificates held on the local system

t603

Posted: Tue Apr 01, 2014 4:26 am Post subject:

Voyager

Joined: 16 Oct 2012
Posts: 88
Location: Prague, the Czech Republic, Europe

Tibor wrote:

It means, there is no relation between your certificate and CA (signer).

Tibor, it sounds, it could be the problem. This certificate was created for inhouse usage, so I suppose, that this could be done in as little effort to be correct as possible. Certificate was issued by our internal CA for internal purposes.

Please, could You point me, how and what should I check? I already investigate key.db in iKeyman, but I do not know, what to check.

Although I believed, that if JKS works OK, then KDB created from this JKS has to work OK too, but maybe my assumption was wrong.

fjb_saper

Posted: Tue Apr 01, 2014 4:33 am Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Make sure that for all certificates in the kdb / jks you have all the signer certs up to the CA cert in the truststore.

It is not enough to have your cert signed by the internal CA you also need the internal CA's public cert in the truststore...

https://www.google.com/#q=x.509+certificate+chain+verification

_________________
MQ & Broker admin

Tibor

Posted: Tue Apr 01, 2014 4:55 am Post subject:

Grand Master

Joined: 20 May 2001
Posts: 1033
Location: Hungary

You can check the chain in your keydb.

- list all the certificates:

Code:

$ gsk7cmd -cert -list -db key.kdb -pw 'xxx'
Certificates in database: key.kdb
internalca
ibmwebspheremqclient

- then ask for details for every entries, e.g.

Code:

$ gsk7cmd -cert -details -db key.kdb -pw 'xxx' -label 'ibmwebspheremqclient'
Label: ibmwebspheremqclient
Key Size: 2048
Version: X509 V3
Serial Number: ...
Issued By: InternalCA

$ gsk7cmd -cert -details -db key.kdb -pw 'xxx' -label 'internalca'
...

fjb_saper

Posted: Tue Apr 01, 2014 12:29 pm Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

And remember you need 2 trust chains in your truststore:

The trust chain for your own certificate
The trust chain for the partner's certificate
Sometimes they happen to be one and the same...

Have fun

_________________
MQ & Broker admin

Display posts from previous:

Goto page 1, 2 Next

Page 1 of 2

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » amqssslc ended 2393, while conn via MQ Explorer CCDT is OK

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Protected by Anti-Spam ACP