Although only confirmed on linux and solaris, this problem should be prevalant
on all platforms across all compilers. This bubbles up when using a TAO server,
TAO Imr, Java client running in an SSLIOP environment. Contact me at
john_c@ociweb.com for a tarred test app demonstrating this.

The problem stems from the line

const ACE_UINT32 TAG_SSL_ENDPOINTS = 0x54414f01U;

in SSLIOP_Endpoint.h. I didn't find this in the spec and only know that 
Ossamma added this sometime last year. When an SSLIOP TAO server creates 
an IOR the SSLIOP::profile creates a tagged component with the correct tag:

const IOP::ComponentId        TAG_SSL_SEC_TRANS = 20;

Somehow when the server is creating an IMrified IOR, it uses 
'TAG_SSL_ENDPOINTS' as the tagged componant ID. This as expected 
confuses the JacORB client which declares the server as being 
non-secure. A dirty work-around to this problem is replacing:

const ACE_UINT32 TAG_SSL_ENDPOINTS = 0x54414f01U;

with
const ACE_UINT32 TAG_SSL_ENDPOINTS = ::SSLIOP::TAG_SSL_SEC_TRANS;

in the SSLIOP_Endpoint.h. I haven't dug this much and hopefully will find time
soon to get back to this. If anyone wants to pin this down, I will be happy to
mail my test.

Ciju