Hi,
I have coded a method which creates and returns back the SSL Socket on the specified host and port(Two Way SSL). Now I will have to call webservices over this returned SSLSocket. Webservice is deployed on a different server. Would appreciate if anybody can guide me on this. Basically I am provided with the wsdl (webservice uri).
Thanks
Can you explain me further what do you mean by saying "You can return an HTTPS URL. "
Method coded by me will enable client authentication when supplied with a keystore file containg a private key/public certificate pair. The target HTTPS server will in its turn verify the certificate presented by the client in order to establish client's authenticity.
Later once the authenticity is established client will open up the socket for secure communication.
No. You should be doing all this over SSL. If SSL refuses to make the connection, that's it. If it succeeds, you already have a secure connection, why would you then go and open another one and have to start all over again? You don't need the 'method coded by me'; you just need the usual SSL handshake.
I suggest that you clarify your requirement before proceeding further.
Would appreciate if you can assist me on how to call a webservice through SSL connection.
Basically the scenario is as follows:
Need to esatblish two way ssl between servers (no browser or user interaction). A servlet deployed in a App server acts as a client and Webservice deployed in another server as a server. Now this servlet needs to establish a two way SSL connection from the Webservice server and call this webservice to get the required response.
Kindly guide me on this.
Please don't tell people there's no such thing as 2-way SSL. You are incorrect in saying so and can mislead others.
Standard (one-way) SSL requires that the server present a certificate to the client; when the client accepts the server's identity as presented in the certificate and a cipher is agreed upon, all data is encrypted.
In 2-way SSL, both the server AND the client must present certificates; first the server, then the client. If both parties accept the other's identity as presented in their certificates, they then agree on a cipher and all data is encrypted. 2-way SSL is referred to as SSL client authentication.
The fact is, Java currently provides poor support for 2-way SSL - one must code it at the Socket level and handle all un-chunking, decoding, inflating, etc. that SHOULD be handled by the underlying API, just as it is with HttpURLConnection.
Don't accuse me of being incorrect or misleading others when you can't even quote me accurately. Kindly read more carefully next time.
I most certainly did not say there was no such thing as 2-way SSL. What I said was 'there is no other kind' but obviously I was referring to full-duplex communications, not authentication.
What you are talking about is SSL with mutual authentication, which indeed I was already recommending to the OP. But you are mistaken about how it works. The cipher suite has already been chosen before the server requests the client certificate.
I don't know why you think Java has poor support for it. All you have to do is deploy a private-key certificate to the client's key store, set the appropriate system properties to tell Java about the keystore, and set needClientAuth=true at the server. From there you can just use an HTTPS URL in exactly the same way as an HTTP URL. Which does all the chunking for you.
