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=http%3a%2f%2fgw.truefriendtest.com%2fCOVIWeb%2fApproval%2fForms%2fForm.aspx%3fmobileyn%3dY%26piid%3d96482621-6cc4-401c-a6f9-5ba6cb7ce26f%26wiid%3d425a9bc9-8607-4898-9158-ed9170da1d89%26fmpf%3dWF_A_DRAFT_PAPER01%26fmrv%3d0%26fiid%3d749526BE-B208-4987-B751-2DD0FC03F0F6%26fmid%3d24f6765d-69d1-429f-b0da-b540a064f0e2%26scid%3ddc4378f1-7edd-4d69-8fe4-5867ed32c8b9"
What it should do is redirecting the browser to BackUrl page given in the url. It display correct result in IE8 despite the certificate problem. In PC version of Chrome it display some code of the HTML. In Android, I get 403 Forbidden error.
HTTP/1.1 403 Forbidden ( The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. )
I use this method to stream data
try{
URL url = new URL(urlString);
HttpsURLConnection.setDefaultHostnameVerifier(new FakeHostVerifier());
TrustManager[] trustAllCerts = new TrustManager[]{
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
Log.d("SSLDemo", "getAcceptedIssuers");
return null;
}
public void checkClientTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
Log.d("SSLDemo", "Check Client Trusted");
}
public void checkServerTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
Log.d("SSLDemo", "Check Server Trusted");
}
}
};
SSLContext sc = SSLContext.getInstance("TLS"); //"TLS"
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
int port = 443;
SSLSocketFactory factory = HttpsURLConnection.getDefaultSSLSocketFactory();
socket = (SSLSocket)factory.createSocket(url.getHost(), port);
socket.startHandshake();
/**
* Connection Method
*/
String method = "GET";
String os = method + " "+urlString+" HTTP/1.0\r\n";
os += "Content-Length: 0";
os += "\r\n\r\n";
((SSLWeb)this.caller).updateRequest(urlString, method);
Log.i("TESTWEB", os);
BufferedWriter wout = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
wout.write(os);
wout.flush();
wout.close();
rd = new BufferedReader(new InputStreamReader(socket.getInputStream()));
//********* Not using thread
StringBuffer buff = new StringBuffer();
char[] buffer = new char[1024];
while(rd.read(buffer) > -1) {
buff.append(buffer);
Log.i("TESTWEB", "read buffer :" + String.valueOf(buffer));
}
Log.i("TESTWEB", "read line :" + buff.toString());
//**********
}catch(Exception e){
Log.e("TESTWEB", "Connecting error", e);
e.printStackTrace();
}
Is there something wrong with my code? I thought the problem was with the URL parameter, but it work in browser 🙁
I’ve been finding a way around the problem for the last three days now, no luck so far.
EDIT: This is FakeHostVerifier class that used to skip the certificate validation process. Isn’t this correct?
public class FakeHostVerifier implements HostnameVerifier {
@Override
public boolean verify(String hostname, SSLSession session) {
return true;
}
}
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-Lengthheader. It’s aGETrequest, so it doesn’t have an entity. Implying a 0-length entity might confuse the server.User-Agentheader to simulate the request as coming from a browser.Acceptheader as well, that might be the cause of your problem with Chrome.)EDIT: (other potential problem, more likely to be the cause)
If you
urlstringvariable 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:
Not:
(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
Hostheader, 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).