In those cases the typical System properties to set up the keystore and password will apparently not work. You can of course pass the properties as part of the java command line that starts the JVM but you can do the same programatically of course.
System.setProperty("javax.net.ssl.keyStore", "keystore path"); System.setProperty("", "keystore password"); System.setProperty("javax.net.ssl.keyStoreType", keystore type);
You will be tempted to get into a really complicated solution.
However there is a simple approach around this problem. If you are contraint about having just one keystore to host multiple certificates that should not be a big issue. After all it is a key "store". All you need to do is import all your certificates and keys in just one keystore following a procedure like the one I described before.
Again what you need to have clear is how you deal with your keys which might be encrypted with a password and that password must be the same you use for your keystore. At that point if you have let us say just one case for a key using a password you can just use the same for your keystore. If not then negotiate a new common password with your service providers. This is after all your client key, yes it is private but it is private to you. A simple phone call and an agreement on the new password will make the trick. Do not use an email for that though!
We recently spent several days troubleshooting issues like this just because I was relying on "that was already tested and it did not work". It demanded a new developer to take over the task so he could start fresh and try the most basic stuff. Simpler is after all better.
As always log traces are your friend when Google is not. Be sure to activate them for SSL when you are dealing with certificate issues: