I'm using WebLogic 9.2.2 on Solaris and trying to connect to an EJB service from my client using https. While I have confirmed the EJB is running on the remote machine, upon trying to connect from the WebLogic container, I get the exception
javax.net.ssl.SSLKeyException: [Security:090477]Certificate chain received from orma4 - 188.8.131.52 was not trusted causing SSL handshake failure.
(complete stack trace below). How do I begin to debug this problem? What do I need to configure on the remote machine in order to make the secure connection successfully?
Thanks, - Dave
weblogic.application.ModuleException: [HTTP:101216]Servlet: "HistoryInitServlet" failed to preload on startup in Web application: "nps_history_gui.war".
Make sure the parameters you are passing like https, host, port, query string in your client method match the certificate that you have installed on your server. During the initial attempt to connect and create the ssl connection there is a handshake between the server and client where your SSL cert. public keys are exchanged and then verified by passing the data encrypted with the public key and then the data is decrypted with your clients or server's private key. If during the initial hanshake when this connection is being established one of the sides does not have a valid cert configured this will fail. Also note a secure random number is passed during the sllcontext.init() before a socket is created, this is created by default if one is not passed but sometimes creates a delay in the sll connection on the server side if it wasn't configured..
When debugging anything you can start with checking the top of your stacktrace for exceptions and then googling what those exceptions mean. Also try to follow the code through the stack trace to see if any assumptions that you have made about variables being set or null are not false. Check that all of your database and server connections are setup correctly and the keystore and certificates are correctly installed. Try putting print statements in likely places where the code is failing to pinpoint the exact place that the code generates the exception. Although the stacktrace also usually provides line numbers if these are not hitting in the wrong spots they can be helpful.