Hi folks,
I need to call a secured web service (https). using Java (or even any other prog lang).
Do I need to do any extra steps rather than the usual steps to create a client for HTTP web service?
EDIT: please I need answer to this question too : If not, So how my client do decrypte the encrypted message sent from the web service??
Thanks
For the most part, HTTP clients will “just work” with HTTPS.
Of course, the only way to know for sure is to try it: take your favourite HTTP client and change the URL from http:// to https://.
The Java URL api should handle this for you. There may be issues with certificates if the server certificate signer is not part of the standard Java CA set, but that's unlikely (and not too hard to fix).
Other languages will almost certainly have similar support.
The socket layer will handle all encryption and decryption for you.
If your web-service doesn't require client-certificate authentication, there's not so much to change (except the trust managers/trust stores, but you may tend to use the same ones for your overall application).
If your service wants client-certificate authentication, you'll need extra configuration steps. For example, if you're using Axis, you could try this approach: http://stackoverflow.com/questions/3712366/choosing-ssl-client-certificate-in-java/3713147#3713147
(How this is done will depend on the language and the framework you're using.)
EDIT: Regarding "If not, So how my client do decrypte the encrypted message sent from the web service?", this is done by the SSL/TLS stack. Most HTTP libraries that support HTTPS will use the platform's SSL/TLS stack (JSSE in Java) more or less transparently: that's where the encryption/decryption will occur. If you're using a web-service framework, it's likely to have an API to configure the SSL/TLS trust settings (or which client-certificate to use), although it's also likely to use the system's default if you don't do anything.
Note that your question is about web-services secured with HTTPS, which only implies transport-level security (which is more or less transparently handled by the SSL/TLS stack of the platform you'll be using). Some web-services can also be secured using message-level security, in which case the framework on both client and server side will need to support this. This will certainly require more configuration. (In some cases, you may find message-level security implemented in conjunction with transport-level security, that is, exchanging signed or encrypted payload on top of HTTPS.)
Theoretically no. Https is basically HTTP over SSL/TLS. So, since both SSL/TLS are located in the Transport Layer, everything should work exactly the same way as HTTP. Now, you are going to have to get a certificate for the server.
Nothing needs to be done on your end. The transport layer handles it all automatically, with no hassle for your application layer. This means, your program doesn't tell the difference between regular HTTP and HTTPS.
It should just work, as others have noted, unless you have self signed your certificate on the server. In that case, java will complain and you will need to import the server key into your local clientside keystore. This is obviously not a great solution if you need to deploy the client software to many places as you would need to do this on each deployed client. In this case you would want to get a proper certificate on the server.
You can trust any certificate in java with the code from here: http://www.exampledepot.com/egs/javax.net.ssl/TrustAll.html but that does leave you open to man in the middle attacks so it is purely for development.
If the client is a Windows .NET app, you can trust all SSL certificates with this code:
// Trust all SSL certificates
System.Net.ServicePointManager.CertificatePolicy = new TrustAllCertificatePolicy();
It will complain that this is deprecated and offer an alternative but this does work.