Description of problem:

If the server certificate subject do not start with the Common Name the hostname is incorrectly parsed from the server certificate. 

In example, when using the following subject while generating the server certificate:
"C=CZ,L=Brno,O=Red-Hat-Inc.,OU=MRG-Messaging-01.v.CACS,CN=<hostname>",

following error is reported and the SSL handshake fails: 
javax.jms.JMSException: Error creating connection: SSL hostname verification failed. Expected : dhcp-124-101.lab.eng.brq.redhat.com Found in cert : Z.

It looks like that simply first three characters are stripped (expecting to be 'CN=') and the rest is considered as the hostname for verification (thus the character 'Z', because C=CZ -> Z)

There is a workaround for this issue. When the server certificate subject starts with the CN set to the expected hostname, then the hostname verification and whole the SSL handshake succeeds.
ie:
"CN=<hostname>,C=CZ,L=Brno,O=Red-Hat-Inc.,OU=MRG-Messaging-01.v.CACS"

Version-Release number of selected component (if applicable):
qpid-java-*-0.30-7

How reproducible:
100%

Steps to Reproduce:
1. generate a server certificate, do not place the CN on the first place in the certificate subject, ie:
   "C=CZ,L=Brno,O=Red-Hat-Inc.,OU=MRG-Messaging-01.v.CACS,CN=<hostname>"
2. configure (use the server certificate from step1.) and run the broker listening for SSL connections
2. run some example SSL client
3. SSL handshake failure due to hostname verification fail

Actual results:
If the sever certificate subject do not start with CN=<hostname>, the hostname verification fails.

Expected results:
The hostname is parsed correctly from the server certificate and SSL handshake succeeds when it matches the expected hostname. 

Additional info:
Notes:
1.) I'm not marking this issue as a blocker or high Severity because the workaround exists, but appropriate flags were set to request a documentation update.
2.) this issue do not appear when using qpid-java-*-0.32, so there may be some existing fix.
3.) This is not a regression. Retested with MRGM-3.1 gives the same result.