by
zvika
tags:
1 comments

 

Say you want to invoke a remote web service deployed on a server that requires SSL. Say, the maintainers of the server couldn't (ot could not be bothered) getting a real, shiny, authetic, SSL certificate signed by a real CA. Or - more likely - let's say you are the one developing the service and the service consumer, and you don't have a valid certificate for each of your development machines (as you may know, ssl certificates are specific to a machine).

Problem: your http client used to access the service will never pass the ssl handshake.

Solution: see here: http://devcentral.f5.com/weblogs/joe/archive/2005/07/06/1345.aspx for a real life saver

1

Comments

shlomo
21:11 Jun 21st
"Say, the maintainers of the server couldn't (ot could not be bothered) getting a real, shiny, authetic, SSL certificate signed by a real CA" What does it matter if its a self signed certificate, a certificate generated by VerSign or one that was generated by my own CA (EJBCA)? Isnt it true that for the client, the server that is using them is the same? or am I missing your point here? "Or - more likely - let's say you are the one developing the service and the service consumer, and you don't have a valid certificate for each of your development machines (as you may know, ssl certificates are specific to a machine)." Again, unless I am missing something, I have *DIFFERENT* production/development machines working with *the same* certificate, now days you can design it that way. Why do you say that the certificates are machine specific? last but not least, why would I want my HTTP client access an HTTPS server? am I not defying the purpose of SSL?