ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » SSL cipher and certificate relation

Post new topic  Reply to topic
 SSL cipher and certificate relation « View previous topic :: View next topic » 
Author Message
kordi
PostPosted: Wed Jan 27, 2016 5:22 am    Post subject: SSL cipher and certificate relation Reply with quote

Centurion

Joined: 28 May 2012
Posts: 145
Location: PL

Hi all,

I have a problem I don't understand occuring between mq client and mq server, both 7.5.0.4 version.

I am in the midddle of replacing SHA-1 to SHA-2 certificates. I updated both client's and server's trust store with new root certificates. Client has new SHA-2 certificate while server is still using old SHA-1. Both trust stores has appropriate root certificates to validate remote certificate.

When I set up SSLCIPH to TLS_RSA_WITH_AES_256_CBC_SHA256 on SVRCONN and CLNTCONN channels, I started receiving following errors in q manager log and connection couldn't be estabilish:

Code:

AMQ9633: Bad SSL certificate for channel '????'.

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

The channel is '????'; in some cases its name cannot be determined and so is
shown as '????'. The remote host is 'xxx (10.10.10.10)'. The channel
did not start.

The details of the certificate which could not be validated are '????'.

The certificate validation error was 0.
ACTION:
Check which of the possible causes applies on your system. Correct the error,
and restart the channel.


When I changed SSL Authentication attribute from Required to Optional on Queue Manager I started receving these errors:

Code:

AMQ9637: Channel is lacking a certificate.

EXPLANATION:
The channel is lacking a certificate to use for the SSL handshake. The channel
name is 'XXX.CHANNEL' (if '????' it is unknown at this stage in the SSL
processing).

The remote host is 'host (10.10.10.10)'.

The channel did not start.
ACTION:
Make sure the appropriate certificates are correctly configured in the key
repositories for both ends of the channel.



When I changed SSLCIPH to TRIPLE_DES_SHA_US I was able to set up connection between client and q manager.

Can somebody explain me why I am facing these issues?

It is worth mentioning that few of sender channels are using TLS_RSA_WITH_AES_256_CBC_SHA256 cipher and working fine.

Thanks in advance!


Last edited by kordi on Fri Jan 29, 2016 4:18 am; edited 1 time in total
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Jan 27, 2016 5:55 am    Post subject: Reply with quote

Grand High Poobah

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

Perhaps because you are thinking that an SSL cipherspec maps to an SSL ciphersuite?...

The truth is that an SSL cipherspec maps to a object composed of both an SSL ciphersuite and SSL_FIPS_REQUIRED object...

Hope it helps
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
kordi
PostPosted: Wed Jan 27, 2016 7:26 am    Post subject: Reply with quote

Centurion

Joined: 28 May 2012
Posts: 145
Location: PL

Thanks for quick reply.

Any idea how can I make it working?
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Jan 27, 2016 10:02 am    Post subject: Reply with quote

Grand High Poobah

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

, try and find out what works, then add levels of complexity...


_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
kordi
PostPosted: Fri Jan 29, 2016 2:34 am    Post subject: Reply with quote

Centurion

Joined: 28 May 2012
Posts: 145
Location: PL

Well, I tested it with Queue Manager which already has new SHA-2 certificate, so both client and server were using certificate signed by the same CA. And it works.

I don't understand however why Queue Manager having old SHA1 certificate works with TLS cipher during QMGR <-> QMGR connection while the same QMGR having client <-> QMGR doesn't, throwing above errors :/

Here is the situation:


Last edited by kordi on Tue Feb 02, 2016 4:21 am; edited 1 time in total
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Jan 29, 2016 5:55 am    Post subject: Reply with quote

Grand High Poobah

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

Now the plot thickens...
O.K. Did you check the keysize on both client and server side where it works and where it fails?

Is there a different algorithm being used where it succeeds as to where it fails?
(server and client definitions of the algorithms).

Was a different algorithm requested at server cert creation time? (server with old cert vs server with newer cert)

For the old certificate, did you try and restrict yourself to a TLS cipher spec supporting SHA-1? SHA-2 is not likely to be supported if the cert is not up to par...


_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
kordi
PostPosted: Fri Jan 29, 2016 6:23 am    Post subject: Reply with quote

Centurion

Joined: 28 May 2012
Posts: 145
Location: PL

The problem is I don't know the rules, the principles for establishing SSL connection between two parties having different certificates signed by different CA, different key size, different signing algorithm :/ Without that knowledge I can only guessing.

I also dont have access to QMGR2 to see certificate details however I can check different TLS_RSA_* ciphers, thats a good tip, thanks. After all however, I can come to conclusions which may be wrong though...
Back to top
View user's profile Send private message
tczielke
PostPosted: Fri Jan 29, 2016 8:54 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

What language is the client written in? C, .Net, Java, etc?

If the client is Java, what kind of JVM are you using (e.g. IBM, Oracle, etc.)?
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
kordi
PostPosted: Sat Jan 30, 2016 12:02 pm    Post subject: Reply with quote

Centurion

Joined: 28 May 2012
Posts: 145
Location: PL

I was using amqsputc to test the connection, so that was C client.
Back to top
View user's profile Send private message
tczielke
PostPosted: Sat Jan 30, 2016 1:50 pm    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

One thing you could do is take the personal certificate from the client key.kdb and put it into the queue manager key.kdb with a label like client_cert, and then run the following runmqakm command against the queue manager key.kdb.

runmqckm -cert -validate -db key.kdb -label client_cert

This will cause the client personal cert to be validated against the signer certs that are in the queue manager key store. If that does not pass, it should hopefully provide some clues as to why.

It would also be good to do the reverse validate test with the queue mangager personal cert in the client keystore.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
kordi
PostPosted: Tue Feb 02, 2016 4:16 am    Post subject: Reply with quote

Centurion

Joined: 28 May 2012
Posts: 145
Location: PL

tcziele Thanks for the hint but since I am able to establish the connection between client and server I guess certificates are fine and remote parts are able to validate them.

I was trying with different ciphers and this one works fine:
TLS_RSA_WITH_AES_256_CBC_SHA

I guess because server has SHA-1 certificate and for that reason he is not able to handle cipher using SHA-2 hash algorithm. But I may be wrong.

Still it is a mystery and I need to figure out why one of the sender channels of q manager is running TLS_RSA_WITH_AES_256_CBC_SHA256...

...and I think I found the answer
Quote:
"Digital certificates signed using the MD5 algorithm are rejected when the TLS 1.2 protocol is used."

https://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q010240_.htm

But it is still a puzzle I am able to use MD5 certificate for sender channel using TLS1.2
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Security » SSL cipher and certificate relation
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
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.