Validated ssl certificate thowing exception when java app runs

Question

I am trying to add an validated SSL certificate to my java app. The Java app acts as a Transformation Service. It listens on a port at a specific URL. It Transforms the body of the request by string find and replace. The Java app then POST that transformed data off to an internal service.

I have added a Self Signed SSL certificate to the app. However this does not work too well. In SoapUI it works fine. When I try call it from a C# application using basicHttpBinding and a HttpWebRequest, I get the following error:

Unhandled Exception: System.Net.WebException: 
The underlying connection was closed: 
Could not establish trust relationship for the SSL/TLS secure channel. --->
System.Security.Authentication.AuthenticationException: The remote certificate 
is invalid according to the validation procedure.

So I removed that certificate and added a signed certificate. This certificate is currently attached to the domain where the java app is listening on. When I try and run the Java app I get the following exception:

java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing
implementation (algorithm: Default, provider: SunJSSE, class:   
com.sun.net.ssl.internal.ssl.DefaultSSLContextImpl)

Java code that sets the Key and Trust Store:

loadConfig();
loadTransforms();

// Set Trust/Key stores
System.setProperty("javax.net.ssl.keyStore", keyFile);
System.setProperty("javax.net.ssl.keyStorePassword", keyPassword);
System.setProperty("javax.net.ssl.trustStore", keyFile);
System.setProperty("javax.net.ssl.trustStorePassword", keyPassword);

TransformationServer server = new TransformationServer();
server.runServer(mode);

The certificates are stored inside the key and trust stores. Does anyone have any ideas?

Answer 1

Went about a different solution. I have added the config below to the WinForm App.

<system.net>
    <settings>
        <httpWebRequest useUnsafeHeaderParsing="true" />
    </settings>
</system.net>

So Java is still using a Self Signed Cert.

EDIT: There was something wrong with the line endings in the header of the request. It did not comply with some http RFC standard.