Below is the URL I send to the WS after the handshake is done
\"https://ekp.truefriend.com/COVIWeb/gate/AutoAuthentication.aspx?UserID=DP0001&BackUrl
As I was saying in a comment to another answer, this has nothing to do with trusting the server's certificate or not. If you get an HTTP response, even if it's a 403, that means that the HTTP connection was established, which also means that the underlying SSL/TLS connection was established. If your client doesn't trust the server certificate, the SSL/TLS connection will close before any HTTP traffic happens.
I'd try a few things:
Content-Length
header. It's a GET
request, so it doesn't have an entity. Implying a 0-length entity might confuse the server.User-Agent
header to simulate the request as coming from a browser.Accept
header as well, that might be the cause of your problem with Chrome.)EDIT: (other potential problem, more likely to be the cause)
If you urlstring
variable really contains "https://ekp.truefriend.com/COVIWeb/gate/...
", that's where the problem comes from.
When you send an HTTP GET the request should be like this:
GET /COVIWeb/gate/... HTTP/1.1
Host: ekp.truefriend.com
Not:
GET https://ekp.truefriend.com/COVIWeb/gate/... HTTP/1.1
(that's only for requests via a proxy, and doesn't apply to the HTTPS requests anyway.)
If you're using HTTP 1.0, you won't use the Host
header, but it shouldn't really matter (unless that host serves multiple virtual hosts, which it can do, even over HTTPS). Consider using HTTP/1.1 if you can, although you may have to deal with closing the connection (content-length or chunked encoding perhaps).