| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| SSL keysize differs |
« View previous topic :: View next topic » |
| Author |
Message
|
| HugoB |
 Posted: Fri Oct 07, 2005 3:46 am Post subject: SSL keysize differs |
 |
|
Acolyte
Joined: 26 Jun 2001
Posts: 67
|
Qmgr A;
Assigned KEYA (1024 bits) (this is the private key)
added to the store the public key of Qmgr B (2048 bits)
Qmgr B:
Assigned KEYB (2048 bits) (this is the private key)
added to the store the public key of Qmgr A (1024 bits)
If i start the channel on Qmgr A, the people on site B claim
that the handshake goes OK, and then the channel drops down.
If I look in my logging on Qmgr A I get this log;
10/7/2005 13:18:39
AMQ9690: The public key in the issuer's certificate has failed to validate the
subject certificate.
EXPLANATION:
The public key in the issuer's certificate (CA or signer certificate), is used
to verify the signature on the subject certificate assigned to channel
KLTASSL.MQHUBT1.CH. This verification has failed, and the subject certificate
therefore cannot be used. The WebSphere MQ error recording routine has been
called.
ACTION:
Check that the issuer's certificate is valid and available, and that it is up
to date. Verify with the certificate's issuer that the subject certificate and
issuer certificate should still be valid. If the problem cannot be resolved
then use the standard facilities supplied with your system to record the
problem identifier and save the generated output files, and then contact your
IBM support center. Do not discard these files until the problem has been
resolved.
All intermediate certs are applied. And in the internet explorer (yes windows on Qmgr A) all certs are valid.
But still the above error. Could this be due to the fact that one cert is 1024 bits and the other 2048 ?
Btw the connection is from company A to company B, via a VPN internet tunnel. |
|
| Back to top |
|
 |
| PGoodhart |
| Posted: Fri Oct 07, 2005 6:15 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
I know this may seem a bit off point, but if you are using VPN tunneling, then why are you using MQ SSL? Most VPN tunneling solutions are already wrapped in a very good SSL based encryption. (You might save yourself some work and some overhead.) I am pretty sure you do not need to have certs of the same size. Most likely someone doesn't have the cert parameters quite right.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 07, 2005 7:32 am Post subject: Re: SSL keysize differs |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| HugoB wrote: |
Qmgr A;
Assigned KEYA (1024 bits) (this is the private key)
added to the store the public key of Qmgr B (2048 bits)
Qmgr B:
Assigned KEYB (2048 bits) (this is the private key)
added to the store the public key of Qmgr A (1024 bits) |
Notwithstanding what PGoodhart said, which you should relate to, there are a number of common problems with setting up MQ and SSL:
1. Did you make sure (100% sure!) that those are indeed certs with private keys? You can see this in the little tool that manages mq cert stores by looking for a small golden key; you should also make sure you "assign" it.
2. I've never worked the way you did, though I think it should work; What I normally do is issue a CA public cert and then two private certs signed by this CA, then I distribute the CA cert to both QMs and one private cert to each.
3. Do these channels work without SSL? This is always a good thing to check.
4. How did you create these certs? Some tools, for some reason, when encountering errors still create the certs, but with faults. So you'd better make sure they were created properly and with private keys included.
That's all I can think of, keep us posted. |
|
| Back to top |
|
|
| HugoB |
| Posted: Sat Oct 08, 2005 2:46 am Post subject: |
|
|
Acolyte
Joined: 26 Jun 2001
Posts: 67
|
Ok , yes SSL and next to this VPN is a bit weird and overdone.
The reason is simple, this is a mutual agreement for both comapanies.
Company A wants only things to the outside world by using VPN.
Company B doesn't care VPN or not, as long as MQ talks SSL.
And, there lies the problem, I can't test the channels without SSL, since
company says, NO, use SSL. Even for tests they don't want to disable
the SSL.
The keys were made with IBM KeyManager that Java tool, shipped with
the IBM HTTP daemon/server. I generated the CRS and posted this to
verisign. And got the certificate, later on I updated the intermediate
certs of verisign on my machine, and so did the other company.
Though company B claims that the SSL handshake on their side goes
OK.
What can I tweak with the cert parameters ?
And could you give me a sample ?
Thnx so far floks |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 08, 2005 6:37 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| HugoB wrote: |
| And, there lies the problem, I can't test the channels without SSL, since company says, NO, use SSL. Even for tests they don't want to disable the SSL. |
That doesn't make any sense at all, it's just a 1 min test...
| HugoB wrote: |
| The keys were made with IBM KeyManager... |
Sadly I am unfamiliar with this tool, maybe someone else here knows it. What about what I asked you, did you "assign" the certificates? Are they marked with the golden key? Did you try doing it the way I suggested (a CA public cert)?
If you've never configured SSL before, I *strongly* advise that you practice it on some test system - this has to be experimented with a bit afore it works. There's a redbook called "MQ v5.3 Security in an Enterprise Envioronment" (sg246814.pdf) - you might want to check it out.
| HugoB wrote: |
| Though company B claims that the SSL handshake on their side goes OK. |
I didn't quite get what you mean by this, first of all SSL handshake is two-sided, second - how do they know it "went ok"? Unless they have a sniffer I don't see how they may know this.
It seems to me that due to politics, you are in for some trouble/headaches; i've had some experience with cases such as this, and I found that what I needed to use most is oration, not problem-solving skills. If you're not assertive about getting the minimum working conditions (for example, the ability to test non-ssl channels, access to their error logs etc) this simple problem (I am convinced it is simple, like forgetting to put a cert to trust store etc) will take you weeks to solve; especially since it sounds like you're dealing with people with no MQ knowledge, and some acute form of paranoia.
If reading the redbook doesn't help, post here how you assigned the certs to the qm step-by-step, and how they did it too, maybe you forgot something...
That's it, no more long posts for me!  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Oct 08, 2005 8:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Did you actually read the error message?
Did you actually *verify* that the cert issuer has signed the cert you are using?
Can you use the same certs to establish an ssl connection with a local qmgr?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HugoB |
| Posted: Sat Oct 08, 2005 11:07 am Post subject: |
|
|
Acolyte
Joined: 26 Jun 2001
Posts: 67
|
jefflowrey and hopsala;
Hopsala I agree with you, they should allow to disable the ssl
and verify the working without SSL. But as you say paranoia mabye.
I dit a lot of tests with trial certs and self signed certs, and no problem with that.
I know the redbook too. And as stated in my first post, I did assign my cert to the Qmgr.
Why company B claims the handshake goes ok is a bit hazy to me too.
Since it's both way. I do fully agree with you.
Please do post long posts 
Monday i will verify your procedure with the golden key etc.
jefflowrey,
For sure i did read my error message.
And yes i did verify that my certificate was signed by Verisign, otherwise
I would see this in the cert properties from within Internet Explorer.
Though I have to admit I'm not an SSL certificate guru.
I can not test all of this local, since i haven't got the private key of company B. This is valid otherwise why use SSL 
All fine and well, it's weekend, monday maybe more.
Thnx a lot so far. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Oct 08, 2005 11:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Are you sure that their public key is properly signed?
Can you create, test, and send them a temporary public/private key pair for testing, to ensure that it's not a problem with their key?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
