| Author |
Message
|
| David.Partridge |
 Posted: Tue Sep 09, 2008 1:33 am Post subject: MQ SSL trace on AIX |
 |
|
Master
Joined: 28 Jun 2001
Posts: 249
|
I used strmqtrc -m qmname -t ssl
This generated a file in /var/mqm/trace called AMQ.SSL.TRC, but it's in a binary format - how do I format it for reading it? dspmqtrc doesn't appear to understand this gskit created trace.
PS Yes, I know the docs say you can't format these, but I'm ever hopeful that there's an undocumented command to do it ...
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
 |
| jeevan |
| Posted: Tue Sep 09, 2008 8:20 am Post subject: Re: MQ SSL trace on AIX |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| David.Partridge wrote: |
I used strmqtrc -m qmname -t ssl
This generated a file in /var/mqm/trace called AMQ.SSL.TRC, but it's in a binary format - how do I format it for reading it? dspmqtrc doesn't appear to understand this gskit created trace.
PS Yes, I know the docs say you can't format these, but I'm ever hopeful that there's an undocumented command to do it ... |
Follow the instructions listed below to start, stop and format WebSphere MQ for AIX trace. Trace files are written to the directory /var/mqm/trace, so delete or relocate old trace files before beginning a new trace.
Start trace for every WebSphere MQ process:
strmqtrc -e
Or start trace only for one queue manager:
strmqtrc -m MY.QMGR
Or start a high detail trace for one queue manager:
strmqtrc -t all -t detail -m MY.QMGR
Or start a high detail wrapping trace and limit the file size to ~5MB:
strmqtrc -l 5 -t all -t detail -m MY.QMGR
End all tracing:
endmqtrc -a
Format the trace files:
dspmqtrc *.TRC
Or format wrapping trace files:
dspmqtrc *.TRC *.TRS
The trace formatter program converts binary files named AMQppppp.TRC (where ppppp is the process identifier or pid which created the file) into readable files named AMQppppp.FMT.
Hope this helps |
|
| Back to top |
|
|
| ranganathan |
| Posted: Tue Sep 09, 2008 8:55 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2008
Posts: 104
|
@Jeevan..
I guess David is talking about SSL trace here  ... and as he indicated we cant format them and see... is there any other command to do so ?! That's the concern here if im not wrong. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 09, 2008 9:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| David.Partridge |
| Posted: Tue Sep 09, 2008 11:32 pm Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
Yes, it is indeed the AMQ.SSL.TRC and AMQ.SSL.TRC.1 files I was bitching about not being able to format.
I do know about the statement in the docs that says "just send these unchanged to IBM". As it happens I managed to get enough out of viewing the trace using "more" to determine what was going wrong during the SSL handshake. But it was hard to get out what I wanted ...
I cannot for the life of me see why we should be denied the ability to format these into human readable form - they contain enormously valuable information for diagnosing SSL handshake problems.
Grrrr
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| Tibor |
| Posted: Wed Sep 10, 2008 1:44 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
David - SSL tracing is a #&@!, you are right! But where is your problem: on the client side or on the server side? When I have already had a client side SSL glitch, I switched on the SSL trace on a Java client, because MQ classes uses the Java SSL implementation.
HTH,
Tibor |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Wed Sep 10, 2008 4:01 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
I already had the Java SSL diagnostics from the client, and all that was telling me was that the server had rejected the connection, hence the need to get an SSL trace on the server side.
Once I'd done that I was *extremely* miffed to find the server side SSL trace was in a yucky binary format and that there wasn't any tool for formatting it documented (and maybe not even shipped).
As I said I did manage to get enough information out of the file to solve the problem but it should not have been as hard as it was. If the tools to format the SSL trace had been available, it would have taken me about two minutes to crack the problem, as compared to twenty minutes or so because the darn file was so hard to read.
C'mon IBM do the decent thing and give us the tools for formatting these traces.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| crossland |
| Posted: Wed Jul 25, 2012 7:14 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
| David.Partridge wrote: |
I already had the Java SSL diagnostics from the client, and all that was telling me was that the server had rejected the connection, hence the need to get an SSL trace on the server side.
Once I'd done that I was *extremely* miffed to find the server side SSL trace was in a yucky binary format and that there wasn't any tool for formatting it documented (and maybe not even shipped).
As I said I did manage to get enough information out of the file to solve the problem but it should not have been as hard as it was. If the tools to format the SSL trace had been available, it would have taken me about two minutes to crack the problem, as compared to twenty minutes or so because the darn file was so hard to read.
C'mon IBM do the decent thing and give us the tools for formatting these traces. |
Maybe it is wishful thinking, but has there been any progress on this?
Like yourself, I am in a similar position where there is plenty of information available on the client side and only a meaningless trace available on the server side. |
|
| Back to top |
|
|
| JasonE |
| Posted: Mon Jul 30, 2012 3:34 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| No - these traces are not generated by MQ, more a component they embed (GSKit) and the formatter for those traces is not publicly available. I know it doesnt help, but its even restricted within IBM so the chances of getting it as part of the product is pretty much zero. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 30, 2012 8:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
My motto on those is test:
- SSL does not work but without SSL no problem
- Test without any peer values, make sure cipherspec and ciphersuite + sslfips match
- Test with SSL peer and no OU values. Make sure to only ask for the other side's cert values
- Add first OU value (if multiple) if fail add OU values in reverse order
- repeat OU value test for the other end of the channel. Remember to only ask for the OU values of the cert on the other end of the channel.
have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
