I am trying to set up a 2 way SSl using my java code. I am successful doing it one way that is server certificate gets validated from my side but when it comes to two way I get a 2397 Error code.
Steps followed by me are:
- Create a keystore with a self-signed certificate using Keytool, deploy it in truststore of MQ server.
- Create a keystore for MQ server and create a self-signed certificate.
- Deploy MQ server’s certificate in my truststore.
Then I try to run my java Code. This works fine without SSL or One way SSL.But two way handshake if failing. Below is the code and stack trace:
//code to create MQ connectivity
public static void main(String [] args){
System.setProperty("javax.net.debug","ssl");
//keystore path
System.setProperty("javax.net.ssl.keyStore", "C:/keystores/keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "password");
//trsutstore path
System.setProperty("javax.net.ssl.trustStore", "C:/keystores/truststore.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "password");
//cipher spec
MQEnvironment.sslCipherSuite = "SSL_RSA_WITH_NULL_MD5";
MQEnvironment.hostname = "*****-ws3717";//system name
MQEnvironment.port = 1414;
MQEnvironment.channel = "channel_name";//channel name
MQQueueManager qm = null;
try { qm = new MQQueueManager("QMNGR");
System.out.println("Conn Successs!!!");
} catch (MQException e) {
e.printStackTrace();
}
finally {
try {
qm.disconnect();
} catch (Exception e) {
e.printStackTrace();
e.getCause();
}
}
} }
Stack Trace is as follows:
keyStore is : C:/keystores/keystore.jks
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
***
found key for : selfsigned
chain [0] = [
[
Version: V3
Subject: CN=Pooja Joshi, OU=SGW, O=SUNGARD, L=PUNE, ST=MH, C=IN
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: Sun RSA public key, 1024 bits
modulus: 132473562370742919150140985227175013875110053845431438145351913928668686945002725183702560702247749924970161010103451411451345824467592557656888776558245848713650717773344294766986771753500118311618188922138349812131167438364266468003061810102502957510761089213138803410346480285664890149111581898928681089463
public exponent: 65537
Validity: [From: Fri May 25 13:54:00 IST 2012,
To: Sat May 25 13:54:00 IST 2013]
Issuer: CN=Pooja Joshi, OU=SGW, O=SUNGARD, L=PUNE, ST=MH, C=IN
SerialNumber: [ 4fbf41a0]
]
Algorithm: [MD5withRSA]
Signature:
0000: 46 D0 CC DF AB 5F 6F D3 37 33 E1 64 F7 1B F7 3F F...._o.73.d...?
0010: 98 95 06 09 F9 84 C8 3A 65 CF A7 24 BB 46 95 DF .......:e..$.F..
0020: 8B 30 F2 BC 5C F9 CC 31 E4 36 53 43 BB 50 1B EF .0....1.6SC.P..
0030: 8C 9B DB C0 41 C9 2C 37 AD B6 1D 30 BF 6E 75 E4 ....A.,7...0.nu.
0040: A9 05 E7 30 5A B1 30 84 6B 8E B7 7A 83 2D 33 01 ...0Z.0.k..z.-3.
0050: A1 44 86 A0 11 30 C3 4D 5B 68 7E 0B 09 48 03 CC .D...0.M[h...H..
0060: DF C5 97 AD 87 40 DC 2A 9A 3D ED FC 27 D3 8B 4F .....@.*.=..'..O
0070: F0 21 02 E8 62 6B 05 63 57 BB E8 4D 33 EA 35 9E .!..bk.cW..M3.5.
]
***
trustStore is: C:keystorestruststore.jks
trustStore type is : jks
trustStore provider is :
init truststore
adding as trusted cert:
Subject: CN=Pooja Joshi, OU=SGW, O=SUNGARD, L=PUNE, ST=MH, C=IN
Issuer: CN=Pooja Joshi, OU=SGW, O=SUNGARD, L=PUNE, ST=MH, C=IN
Algorithm: RSA; Serial number: 0x4fbf4261
Valid from Fri May 25 13:57:13 IST 2012 until Sat May 25 13:57:13 IST 2013
trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, SSLv3
RandomCookie: GMT: 1321485794 bytes = { 138, 193, 95, 113, 86, 252, 250, 50, 154, 121, 73, 8, 93, 116, 115, 184, 182, 142, 240, 205, 15, 250, 172, 171, 111, 5, 122, 52 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_NULL_MD5]
Compression Methods: { 0 }
Extension renegotiation_info, renegotiated_connection: <empty>
***
main, WRITE: SSLv3 Handshake, length = 52
main, READ: SSLv3 Handshake, length = 4875
*** ServerHello, SSLv3
RandomCookie: GMT: 1321485794 bytes = { 250, 173, 248, 90, 241, 136, 107, 119, 99, 92, 80, 19, 223, 223, 152, 131, 216, 115, 242, 56, 198, 135, 156, 111, 210, 234, 220, 103 }
Session ID: {240, 31, 0, 0, 80, 56, 194, 89, 112, 238, 203, 154, 79, 75, 68, 48, 106, 203, 19, 130, 88, 88, 88, 88, 226, 70, 196, 79, 13, 0, 0, 0}
Cipher Suite: SSL_RSA_WITH_NULL_MD5
Compression Method: 0
***
Warning: No renegotiation indication extension in ServerHello
%% Created: [Session-1, SSL_RSA_WITH_NULL_MD5]
** SSL_RSA_WITH_NULL_MD5
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=Pooja Joshi, OU=SGW, O=SUNGARD, L=PUNE, ST=MH, C=IN
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: Sun RSA public key, 1024 bits
modulus: 105605049659295333895264877648371480987144339115417104117025065956957634413900327625548229515098843172709660865042903412409581107015480309223474293490705595126088958625491899627683399717294708677347640098462040771799700233921554682196524988217754821345297656825451441457385676164016790486091736694366149540953
public exponent: 65537
Validity: [From: Fri May 25 13:57:13 IST 2012,
To: Sat May 25 13:57:13 IST 2013]
Issuer: CN=Pooja Joshi, OU=SGW, O=SUNGARD, L=PUNE, ST=MH, C=IN
SerialNumber: [ 4fbf4261]
]
Algorithm: [MD5withRSA]
Signature:
0000: 81 F5 2C 2A 77 63 F1 CD D8 31 E1 BE B5 9B 28 C5 ..,*wc...1....(.
0010: 6B EA 24 BB 5C 3D EB D0 EB E3 86 2E D7 1C 0D 92 k.$.=..........
0020: 36 A2 79 13 BC 74 40 C4 BF 7C F7 1B 05 8C 6B CF 6.y..t@.......k.
0030: EB 2C C2 0D E3 40 F7 F0 95 66 B6 85 AE 84 66 C9 .,...@...f....f.
0040: B7 C5 29 BE 71 1F 28 C0 83 1C 94 41 08 2A 44 45 ..).q.(....A.*DE
0050: 99 FD C5 77 28 26 FC 50 A3 69 32 BD F5 8B 0C A6 ...w(&.P.i2.....
0060: 13 21 0F BA B2 C6 A2 71 18 17 94 31 3B 7E 88 63 .!.....q...1;..c
0070: C0 01 76 DC 60 47 BB 3F 2F 7E 2A 73 84 DA 60 79 ..v.`G.?/.*s..`y
]
***
Found trusted certificate:
[
[
Version: V3
Subject: CN=Pooja Joshi, OU=SGW, O=SUNGARD, L=PUNE, ST=MH, C=IN
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: Sun RSA public key, 1024 bits
modulus: 105605049659295333895264877648371480987144339115417104117025065956957634413900327625548229515098843172709660865042903412409581107015480309223474293490705595126088958625491899627683399717294708677347640098462040771799700233921554682196524988217754821345297656825451441457385676164016790486091736694366149540953
public exponent: 65537
Validity: [From: Fri May 25 13:57:13 IST 2012,
To: Sat May 25 13:57:13 IST 2013]
Issuer: CN=Pooja Joshi, OU=SGW, O=SUNGARD, L=PUNE, ST=MH, C=IN
SerialNumber: [ 4fbf4261]
]
Algorithm: [MD5withRSA]
Signature:
0000: 81 F5 2C 2A 77 63 F1 CD D8 31 E1 BE B5 9B 28 C5 ..,*wc...1....(.
0010: 6B EA 24 BB 5C 3D EB D0 EB E3 86 2E D7 1C 0D 92 k.$.=..........
0020: 36 A2 79 13 BC 74 40 C4 BF 7C F7 1B 05 8C 6B CF 6.y..t@.......k.
0030: EB 2C C2 0D E3 40 F7 F0 95 66 B6 85 AE 84 66 C9 .,...@...f....f.
0040: B7 C5 29 BE 71 1F 28 C0 83 1C 94 41 08 2A 44 45 ..).q.(....A.*DE
0050: 99 FD C5 77 28 26 FC 50 A3 69 32 BD F5 8B 0C A6 ...w(&.P.i2.....
0060: 13 21 0F BA B2 C6 A2 71 18 17 94 31 3B 7E 88 63 .!.....q...1;..c
0070: C0 01 76 DC 60 47 BB 3F 2F 7E 2A 73 84 DA 60 79 ..v.`G.?/.*s..`y
]
*** CertificateRequest
Cert Types: RSA
Cert Authorities:
<EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA>
<EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA>
<EMAILADDRESS=personal-basic@thawte.com, CN=Thawte Personal Basic CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA>
<EMAILADDRESS=personal-freemail@thawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA>
<EMAILADDRESS=personal-premium@thawte.com, CN=Thawte Personal Premium CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA>
<CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US>
<CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US>
<CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US>
<CN=VeriSign Class 4 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US>
<OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US>
<OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US>
<OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US>
<OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 4 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US>
<OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>
<OU=Class 2 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>
<OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>
<CN=VeriSign Class 3 Secure Server CA, OU=Terms of use at https://www.verisign.com/rpa (c)05, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US>
<CN=Entrust.net Secure Server Certification Authority, OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), O=Entrust.net, C=US>
<CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net>
<CN=Entrust.net Client Certification Authority, OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/Client_CA_Info/CPS incorp. by ref. limits liab., O=Entrust.net, C=US>
<CN=Entrust.net Client Certification Authority, OU=(c) 2000 Entrust.net Limited, OU=www.entrust.net/GCCA_CPS incorp. by ref. (limits liab.), O=Entrust.net>
<CN=Entrust.net Secure Server Certification Authority, OU=(c) 2000 Entrust.net Limited, OU=www.entrust.net/SSL_CPS incorp. by ref. (limits liab.), O=Entrust.net>
<CN=Pooja Joshi, OU=SGW, O=SUNGARD, L=PUNE, ST=MH, C=IN>
*** ServerHelloDone
matching alias: selfsigned
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=Pooja Joshi, OU=SGW, O=SUNGARD, L=PUNE, ST=MH, C=IN
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: Sun RSA public key, 1024 bits
modulus: 132473562370742919150140985227175013875110053845431438145351913928668686945002725183702560702247749924970161010103451411451345824467592557656888776558245848713650717773344294766986771753500118311618188922138349812131167438364266468003061810102502957510761089213138803410346480285664890149111581898928681089463
public exponent: 65537
Validity: [From: Fri May 25 13:54:00 IST 2012,
To: Sat May 25 13:54:00 IST 2013]
Issuer: CN=Pooja Joshi, OU=SGW, O=SUNGARD, L=PUNE, ST=MH, C=IN
SerialNumber: [ 4fbf41a0]
]
Algorithm: [MD5withRSA]
Signature:
0000: 46 D0 CC DF AB 5F 6F D3 37 33 E1 64 F7 1B F7 3F F...._o.73.d...?
0010: 98 95 06 09 F9 84 C8 3A 65 CF A7 24 BB 46 95 DF .......:e..$.F..
0020: 8B 30 F2 BC 5C F9 CC 31 E4 36 53 43 BB 50 1B EF .0....1.6SC.P..
0030: 8C 9B DB C0 41 C9 2C 37 AD B6 1D 30 BF 6E 75 E4 ....A.,7...0.nu.
0040: A9 05 E7 30 5A B1 30 84 6B 8E B7 7A 83 2D 33 01 ...0Z.0.k..z.-3.
0050: A1 44 86 A0 11 30 C3 4D 5B 68 7E 0B 09 48 03 CC .D...0.M[h...H..
0060: DF C5 97 AD 87 40 DC 2A 9A 3D ED FC 27 D3 8B 4F .....@.*.=..'..O
0070: F0 21 02 E8 62 6B 05 63 57 BB E8 4D 33 EA 35 9E .!..bk.cW..M3.5.
]
***
*** ClientKeyExchange, RSA PreMasterSecret, SSLv3
main, WRITE: SSLv3 Handshake, length = 711
SESSION KEYGEN:
PreMaster Secret:
0000: 03 00 3D 04 C8 EF 08 83 A4 EF 85 1C D9 96 A0 77 ..=............w
0010: 32 2A A5 43 14 98 11 6F DD 01 52 73 4D DF B4 5A 2*.C...o..RsM..Z
0020: C5 2E FC 2A C0 F6 C2 9B 11 23 B2 C0 7B 59 E8 96 ...*.....#...Y..
CONNECTION KEYGEN:
Client Nonce:
0000: 4F C4 46 E2 8A C1 5F 71 56 FC FA 32 9A 79 49 08 O.F..._qV..2.yI.
0010: 5D 74 73 B8 B6 8E F0 CD 0F FA AC AB 6F 05 7A 34 ]ts.........o.z4
Server Nonce:
0000: 4F C4 46 E2 FA AD F8 5A F1 88 6B 77 63 5C 50 13 O.F....Z..kwcP.
0010: DF DF 98 83 D8 73 F2 38 C6 87 9C 6F D2 EA DC 67 .....s.8...o...g
Master Secret:
0000: C0 20 A8 BC D1 A7 06 B0 C5 07 CA A7 83 C5 35 9E . ............5.
0010: 20 AB B6 28 8C 7E EF 14 CB 9D C1 ED C5 62 F8 A1 ..(.........b..
0020: 6A DE 9F AF 16 5B 2F 1D 21 8F A3 2C F7 B9 3D 36 j....[/.!..,..=6
Client MAC write Secret:
0000: 09 E8 CE 6C D1 2D 43 86 7E 74 1C 5F 68 DA E2 AE ...l.-C..t._h...
Server MAC write Secret:
0000: CE 62 DA F7 2C F2 2B 4A AD 47 8F 61 BD 58 51 BD .b..,.+J.G.a.XQ.
... no encryption keys used
... no IV used for this cipher
*** CertificateVerify
main, WRITE: SSLv3 Handshake, length = 134
main, WRITE: SSLv3 Change Cipher Spec, length = 1
*** Finished
verify_data: { 4, 127, 139, 212, 93, 181, 170, 62, 121, 196, 243, 156, 251, 103, 206, 222, 2, 10, 84, 35, 186, 251, 144, 6, 31, 97, 135, 179, 160, 127, 204, 93, 100, 140, 74, 79 }
***
main, WRITE: SSLv3 Handshake, length = 56
main, waiting for close_notify or alert: state 1
main, Exception while waiting for close java.net.SocketException: Software caused connection abort: recv failed
main, handling exception: java.net.SocketException: Software caused connection abort: recv failed
MQJE001: An MQException occurred: Completion Code 2, Reason 2397
MQJE030: IOException during security flows
MQJE001: Completion Code 2, Reason 2397
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2397
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:219)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:318)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:338)
at com.ibm.mq.StoredManagedConnection.<init>(StoredManagedConnection.java:84)
at com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:168)
at com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:772)
at com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:697)
at com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:657)
at com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:153)
at com.ibm.mq.MQQueueManager.<init>(MQQueueManager.java:451)
at com.test.SSlTest.main(SSlTest.java:68)
Caused by: java.net.SocketException: Software caused connection abort: recv failed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1493)
at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:103)
at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:689)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:985)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:904)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:238)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
at com.ibm.mq.SSLHelper.configureSSLSocket(SSLHelper.java:567)
at com.ibm.mq.SSLHelper.createSSLSocket(SSLHelper.java:150)
at com.ibm.mq.MQInternalCommunications.createSocketConnection(MQInternalCommunications.java:2264)
at com.ibm.mq.MQv6InternalCommunications$1.run(MQv6InternalCommunications.java:157)
at java.security.AccessController.doPrivileged(Native Method)
at com.ibm.mq.MQv6InternalCommunications.initialize(MQv6InternalCommunications.java:154)
at com.ibm.mq.MQv6InternalCommunications.<init>(MQv6InternalCommunications.java:102)
at com.ibm.mq.MQSESSIONClient.MQCONNX(MQSESSIONClient.java:1337)
at com.ibm.mq.MQSESSIONClient.MQCONN(MQSESSIONClient.java:1246)
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:184)
... 10 more
Kindly help me….
MQ Agent cannot connect to MQ Server. ssl handshake failure. Reason code 2397 MQRC_JSSE_ERROR
calendar_today
Updated On:
Products
CA Application Performance Management Agent (APM / Wily / Introscope)
INTROSCOPE
Issue/Introduction
The MQ Agent fails to connect to the MQ Server when using SSL set to Required Client Authentication.
When the SSL channel is configured for non-required client authentication, it allows full connectivity, but when the channel is set to required client authentication the connection fails.
Note that the functionality works even when not using SSL.
When SHA or MD5 is configured on channel APM.SSL.SVRCONN, the Client/MQ server connection negotiation throws a JSSE exception. This occurs even when the MQ server certificate has been added to the client and the client certificate has been added to the server.
The following messages are logged in the Agent Log:
ERROR] [com.wily.powerpack.websphereMQ.agent.MQMonitor.TracerDriverThread] MQMonitor: For configuration instance [email protected]_dev_machine and the drivers(namelist,cluster) an error occurred in sending query to MQ. The target MQ (test_dev_machine:port#) may be down. Reason code 2397 MQRC_JSSE_ERROR
$ openssl s_client -connect test_dev_machine :port# -prexit CONNECTED(00000003)
14815:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188
Environment
All supported releases.
Cause
The root problem is due to the following two factors:
1) The keystore contains extraneous private keys: one from a Local CA, and another from an OpenSSL CA generated by the MQ Admin.
To resolve this issue, the truststore was reduced to a single trustedCertEntry and the keystore was reduced to a single PrivateKeyEntry.
The Local CA key was selected instead of the required OpenSSL CA private key required by the MQ server. The key required by the MQ server must be used.
2) The keystore has password ‘AAA’ and the internal key (alias ibmwebspheremqTest_Dev) has a different password, ‘BBB’.
This results in unable to recover key errors when the agent starts up and tries to negotiate the MQ SSL connection.
Resolution
Resolution:
Use a single private key in the keystore and ensure that the keystore password and imported private key password are identical to the value in MQMonitor.properties keystore.password.
Feedback
thumb_up
Yes
thumb_down
No
Your debugging process is perfect! When setting up SSL for the first time, always test first without SSL (validates channel name spelling, listener port, etc.), then check with anonymous SSL (validates that the client can validate the QMgrs certificate) then finally check with mutually authenticated SSL.
In this case the failure is in that final step. By this point we know that the QMgr can read its KDB and that the client can read its trust store. There are very few possible issues at this point and the primary ones are that the client cannot find its private key or that the QMgr cannot validate the clients key.
Since the trace shows the client is able to access its key, we know thats not the problem. In most cases then, this points to a problem on the QMgrs side. There are two problems typical in this case.
- The clients key is not properly loaded into the QMgrs keystore (or perhaps a prior version of the key is loaded).
- The QMgr does not have the current version of the KDB loaded.
Since you provided the stack trace and all other aspects of key exchange appear to be good, Im going to take a wild guess and say the cause is #2 above. If so then it is easily fixed. You can use runmqsc to enter the command REFRESH SECURITY TYPE(SSL) which causes the QMgr to stop all SSL channels and flush the KDB from its cache. There is an equivalent command in WMQ Explorer found by right-clicking on the QMgr. Or just bounce the QMgr, which accomplishes the same thing. Either of these methods result in the QMgr reloading the KDB which gives it access to the new certificate.
UPDATE:
Sorry that was not the issue. Can you recreate the failure and look at the QMgrs error logs? You should see the error at the bottom of /var/mqm/qmgrs/<qmgrname>/errors/AMQERR01.LOG right after the failure.
You can also dump the certificate details on the client and QMgr to verify they match and are marked as trusted in the QMgrs kdb. You already know how to do this with keytool. Depending on your version of WMQ server, you can use gsk7capicmd or gsk8capicmd or with WMQ v7.1 runmqakm. First dump the QMgrs KDB using the -cert -list command, then dump the clients cert using the -cert -details and post the results as an update to your question.
The commands will give you help with the needed parameters. If you want the deep details, go to https://t-rob.net/wmq/ where you will find links to the GSKit 7 and GSKit 8 manuals about halfway down the page. The runmqakm command is a wrapper over GSKit 8 so if the QMgr is running WMQ v7.1 use the GSKit 8 manual.
ibm mq – IBM MQ Error Code 2397 using java SSL
First, please see my answer SSL connect to MQ using .net mq client SSLV3? where I provide an SSL implementation procedure that makes the process much easier.
In this case though the error message reveals the issue:
No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
As Umpathy notes in his answer, this is often due to selection of a ciphersuite in the QMgr that is no longer supported by default. Although it is possible to select the setting in the channel and the client, the QMgr will refuse to use it based on the settings of SSLFIPS, SSLSUITEB, environment variables, or the SSL stanza in the qm.ini file. Please see CipherSpec values supported in IBM MQ for the latest on which ciphers are supported and how to enable the deprecated ones.
You also ask Because I don’t have certificate of the CA, Where I Get certificate of the CA?
The choice to use self-signed certs is not a matter of whether you can find the CA signer for a given cert. If either side of the connection uses a CA-signed certificate, the other side must have the signer for that certificate in their trust store or kdb, even if its personal certificate is self-signed.
If either side is using CA-signed certificates there are a few ways to find the signers.
- Best way is to fetch the certificate for which you need a signer and dump the details. The
Issuer Distinguished Namewill tell you which signer was used. If the cert comes from a reputable CA, most likely it will also contain a URL pointing to the authoritative source for the signer certificate. - Second-best way is to ask the party who administers the remote node to look in the kdb or jks and extract the signer certs used for its personal cert. This is only for trusted parties though because anyone from whom you accept a signer certificate is trusted the same as a real CA. However, for the case that the remote node is a QMgr administered by someone in your own organization you can generally trust them to provide the legitimate signer certs.
Finally…
Note that if you are using self-signed certs, the other side must add your public key to their kdb or jks in order for you to connect. At the moment the two sides cannot agree on a protocol but as soon as they do they will validate each others’ certificates. At that point the debugging procedure I provided in the link above should prove extremely helpful.
#java #ssl #mq
#java #ssl #mq
Вопрос:
У нас есть один QM и один канал и много очередей, созданных для клиентов. Около 5 клиентов подключены к этому QM для своих транзакций. Каждые 5 клиентов подключены к своим соответствующим ОЧЕРЕДЯМ. В этом QM создан файл jks для SSL-соединения. Каждые 5 клиентов подключаются с помощью jks-файла SSL_RSA_WITH_RC4_128_SHA из своего javaClient. QM также настроен с SSLCIPH (RC4_SHA_US).
Теперь внезапно, без каких-либо изменений javaClient, 1 клиент не смог подключиться к настроенному QM. Все остальные могут подключаться к тому же QM без каких-либо проблем.
AMQERR01.LOG не регистрируется с каким-либо конкретным исключением или ошибкой
В журналах приложений говорится об общей ошибке исключения MQ как com.ibm.mq.MQException: MQJE001: код завершения ‘2’, причина ‘2397’
2397 — Спецификация шифрования<>набор не соответствует — есть ли какая-либо возможность?
мы включили трассировку (ТЕСТ strmqtrc -m.QM -t подробно -t все) и увидел журналы трассировки в path (C:Program Files (x86) IBM Websphere MQ trace) , но не смог получить никаких подробностей о том, почему не удалось установить SSL-соединение?
Мы выполнили еще одно упражнение, например, создали новый QM для проблемного клиента и протестировали без SSL и его работы. Когда мы включили SSL в новом QM и javaClient, тот же 2397 начал регистрироваться.
Может ли кто-нибудь помочь мне улучшить ведение журнала и трассировку в MQ, который может понять, почему 2397 выдает ошибку? Может ли кто-нибудь помочь мне улучшить ведение журнала и трассировку в Java, используя -D [-Djavax.net.debug=all] , который может понять, почему 2397 выбрасывает?
Версия MQ -> 7
Сервер MQ в -> Windows
из журналов трассировки
returning TEST.QM
Freeing cbmindex:0 pointer:24DDB540 length:2080
-----} TreeNode.getMQQmgrExtObject (rc=OK)
cbmindex:10
-------------} xcsFreeMemFn (rc=OK)
------------} amqjxcoa.wmqGetAttrs (rc=OK)
-----{ UiQueueManager.testQmgrAttribute
-------------{ Message.getMessage
testing object 'TEST.QM'
An internal method detected an unexpected system return code. The method {0} returned {1}. (AMQ4580)
checking attribute 'QmgrCmdLevelGreaterThan'
-------------} Message.getMessage (rc=OK)
for value '510'
-----------}! NativeCalls.getAttrs (rc=Unknown(C35E))
-----} UiQueueManager.testQmgrAttribute (rc=OK)
Message = An internal method detected an unexpected system return code. The method wmq_get_attrs returned "retval.rc2 = 268460388". (AMQ4580), msgID = AMQ4580, rc = 50014, reason = 268460388, severity = 30
result = true
---} TreeNode.testAttribute (rc=OK)
---{ TreeNode.testAttribute
-----{ QueueManagerTreeNode.toString
-----} QueueManagerTreeNode.toString (rc=OK)
testing object 'TEST.QM'
checking attribute 'OamTreeNode'
-----------{ NativeCalls.getAttrs
------------{ amqjxcoa.wmqGetAttrs
qmgr:2A7B32C8, stanza:2A7B32C4, version:1
for value 'true'
QMgrName('TEST.QM')
-----{ TreeNode.getMQQmgrExtObject
StanzaName('QMErrorLog')
testing object 'TEST.QM'
Full QM.INI filename: SOFTWAREIBMMQSeriesCurrentVersionConfigurationQueueManagerTEST!QM, Multi-Instance: FALSE
--------------} xcsGetIniFilename (rc=OK)
--------------{ xcsGetIniAttrs
---------------{ xcsBrowseIniCallback
FileType = (1)
----------------{ xcsBrowseRegistryCallback
xcsBrowseRegistryCallback
-----------------{ xusAddStanzaLineList
------------------{ xcsGetMemFn
checking attribute 'PluginEnabled'
component:24 function:15 length:2080 options:0 cbmindex:0 *pointer:24DDB540
------------------} xcsGetMemFn (rc=OK)
for value 'com.ibm.mq.explorer.oam'
RetCode (OK)
-----------------} xusAddStanzaLineList (rc=OK)
-----------------{ xusAddStanzaLineList
------------------{ xcsGetMemFn
-----{ UiPlugin.isPluginEnabled
component:24 function:15 length:2080 options:0 cbmindex:1 *pointer:24DDDFE8
------------------} xcsGetMemFn (rc=OK)
RetCode (OK)
-----------------} xusAddStanzaLineList (rc=OK)
testing plugin_id: com.ibm.mq.explorer.oam
-----------------{ xurGetSpecificRegStanza
-------{ PluginRegistrationManager.isPluginEnabled
Couldn't open key (QMErrorLog) result 2: The system cannot find the file specified.
Версия MQ 7.0.1.9
jdk1.8.0_181-i586
com.ibm.mq * версия jar
Спецификация -версия: 6.0.2.1
Реализация-Версия: 6.0.2.1 -j600-201-070305
Комментарии:
1. Изменилась ли версия Java (основная или второстепенная)? Ошибка, которую вы показываете, не имеет отношения к проблеме клиента. Пожалуйста, предоставьте полный 4-значный сервер и
com.ibm.mq*jarверсии вместе с выводомjava -version.2. <Версия MQ 7.0.1.9 >< <jdk1.8.0_181-i586 ><com.ibm.mq * Версия jar<> Спецификация -версия: 6.0.2.1<> Версия реализации: 6.0.2.1 -j600-201-070305>
3. Одинакова ли версия Java с рабочей и нерабочей?
4. Как 1.8.0_181 работал с тем же шифром на других хостах? Моим первоначальным подозреваемым был обновленный JRE, который больше не поддерживал старые шифры SSL V3. Почему вы используете MQ jars из версии, которая не поддерживалась почти 8 лет и была выпущена более 15 лет назад? Даже ваша версия диспетчера очередей не поддерживалась почти 5 лет и была выпущена 8 лет назад?
5. Банки версии 6 не поддерживали ничего, кроме sslv3 и tksv1.0.