Send GET HTTPS request but get 403 forbidden response, why?

Question

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         


        

Answer 1

Your question contains the answer. Upon trying to access the URL you specified in Chrome, you get a big red warning "The site's security certificate is not trusted!". While you can manually override in a browser and ignore the warning, your code treats this as a security problem and a dead end. It even recommends you contact the server administrator.

If you are the server's admin, change the SSL cert to a valid one. if not, ask the admin to do it. Failing that, try accessing the HTTP (non-SSL) version of the site.

Answer 2

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:

• Remove the Content-Length header. It's a GET request, so it doesn't have an entity. Implying a 0-length entity might confuse the server.
• Try to set a User-Agent header to simulate the request as coming from a browser.
• More generally, look at the headers a browser that work would send and try to reproduce them. (Try 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).