Your LDAP server is probably using an untrusted, self-signed SSL certificate, thus requiring you to add its certificate into cacerts.LDAP is working via SSL in case 1. Ergo either he has already done that or it isn't self-signed. No other possibility.
I don't believe it is a client cert, otherwise you would had added it into a separate keystoreThat is exactly what he has done. That's why he is setting javax.net.ssl.keyStore, which is what is causing this problem. Read his post.
So you can just create your cloud keystore with key pair and just add the LDAP server's certificate as a trusted cert to it.And this is real nonsense. You don't add trusted certificates to keystores. You add them to truststores.
I guessWhy? My reply of 9/03/2011 09:17 still seems the most likely to me. Ignore the confusion created above.
When LDAP is connecting with SSL, an SSLContext would get created and stays in the JVMCorrect.
So in the 2nd phase, when we add keystore elements in system properties for cloud operation, they don't get added in the same SSLContext.They don't get added to any SSLContext. The system properties are only read once, and that already happened when you made the LDAP connection. So 'changing them afterwards has no effect', as I already said in my first reply above, 9/03/2011 00:05.
Is there any way we can fetch existing SSLContext and add keystore object into it.No there isn't, but as that isn't the problem it's irrelevant.
And how to attach this context manually into webservice axis2 api call.And you would still have to solve that problem, and I don't know how to do it.