We have a simple web application in Java running on WebLogic secured with SSL over https. The name of the server is dev-service1. Access to the web app using a browser with https works fine, however, with a standalone Java client we are getting the following error indicating that the "dev-service1" is not found in the client.jks file.
com.sun.xml.internal.ws.client.ClientTransportException:
HTTP transport error: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
No name matching dev-service1 found
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:121)
Do we have to export a new client.jks file from the server.jks file using Java's keytool?
You will need to add the self-signed certificate from the server into your clients truststore.
I would recommend using the InstallCert program that can be found in one of two places.
Quick note. I'm fairly sure that the above programs will NOT add the certificate from the server to your default truststore that ships with java. So you will have to set the -Djavax.net.ssl.trustStore and -Djavax.net.ssl.trustStorePassword VM Arguments in your command line that you use to start your client.
Related
I built a Web-Service application in Jdeveloper 11.1.1.7 and deployed it on weblogic 10.3.6 with all Key-store and SSL configuration.
SSl Configuration:
Use Server Certs : Checked
Two Way Client Cert Behavior: Client Certs Not Requested. [That is means it is one-way ssl.
Correct me if that wrong]
SSL Listen Port Enabled: Checked
Key-store Configuration:
Custom Identity and Custom Trust. The file path has been specified for those custom key store
A sample client application has been created and everything seems to be fine; I mean the client can not access the server application without specifying the trust store file location where the server certificate is stored and it is trusted at the client end.
By the server certificate I mean the same certificate that has been configured in server Key-store Configuration
for your information the client application referring to trust store as follow:
System.setProperty("javax.net.ssl.trustStore",[Trust-store location goes here]);
System.setProperty("javax.net.ssl.trustStorePassword", [password goes here]);
Till now nothing wrong. Next is the problem details:
For the purpose of testing I tried to access the deployed web-service application using the SoapUI (open source software). What is confusing is the request has been sent, accepted at the server and proceed without specifying any thing for server certificate nor trust store location in SoapUI project configuration !!
Why the SOAP request has been accepted from SoapUI without referring to server certificate? The request should be rejected in this case.
My experience with SoapUI is that it is quite lenient. For example, if it doesn't check if the CN of server certificate matches the fully qualified domain name in the URL. In your case, your server most likely uses a CA signed certificate. Most of the root and intermediate certificates of well known CA's (e.g. VeriSign/Symantec) are already included in the default truststores for most systems. If your server had used a self-signed certificate, then SoapUI would have incurred SSL error unless you import the self-signed certificates into the truststore of the host where SoapUI is running.
I was given a SOAP WS to work with.
They gave me the wsdl file from which I was able to create client stub (I've used wsdl2java utility within cxf).
With that wsdl I was also give a .keystore file and the thing is I do know know how to add it to my keytool (is this is even the right way of putting it?).
I've built a junit test that I run to test my client but I constantly get
HTTP transport error: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Where can I find an easy guide on what to do with this .keystore file?
Thanks
The error means that the server certificate could not be found in your truststore. Check the contents of the .keystore file to see whether it contains the server certificate (listed as trustedEntry in your truststore). If yes, set the following system properties (either using -D JVM parameter or System.setProperty()).
javax.net.ssl.trustStore=<<your .keystore>>
javax.net.ssl.trustStorePassword=<<keystore password>>
If these properties are not set, the default ones will be picked up from your the default location.[$JAVA_HOME/lib/security/jssecacerts, $JAVA_HOME/lib/security/cacerts]
To view the contents of keystore file, use
keytool -list -v -keystore file.keystore -storepass mypassword
To debug the ssl handshake process and view the certificates, set the VM parameter -Djavax.net.debug=all
If the web service requires 2 way SSL, the client needs to send its identity (picked up from your keystore). In this case, your .keystore will contain a privateKeyEntry which will be sent to the server during handshake process. To configure this, set the JVMM properties javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword to point to your keystore.
The next works for me:
Application server configuration. Apache Tomcat/7.0.52. server.xml: set clientAuth="true" in the https connector.
Application server configuration. Apache Tomcat/7.0.52. tomcat-users.xml: crate a user with the DN of the user as it appears in your certificate (subject)
Web service JAX-WS web service eclipse tutorial. Thanks Arpit! Add it a security constraint in the deployment descriptor (web.xml)
Client. Generated with apache-cxf maven plugin.
Main class:
HelloWorldImplService helloWorldImplService = new HelloWorldImplService();
HelloWorld helloWorld = helloWorldImplService.getHelloWorldImplPort();
SayHelloWorld parameters = new SayHelloWorld();
parameters.setArg0("World");
SayHelloWorldResponse helloWorldResponse = helloWorld.sayHelloWorld(parameters);
System.out.println(helloWorldResponse.getReturn());
Client JVM options:
-Djavax.net.ssl.trustStore=/xxxx/cacerts.jks -Djavax.net.ssl.trustStorePassword=xxxx -Djavax.net.ssl.keyStore=/xxx/user.jks -Djavax.net.ssl.keyStorePassword=xxxx
You can take a look here: Java SOAP client with certificate authentication
An excellent blog to help you understand the keystores and certificates imports required for HTTPS SSL handshake:
http://ruchirawageesha.blogspot.in/2010/07/how-to-create-clientserver-keystores.html
Hope it helps you to setup ur client keystore correctly in order to call the web services.
Good Luck!
How to create Tomcat keystore file using JAVA
I am creating a http connection to SSL enabled tomcat server but it generates error SSL Handshake failed
So I want to create a keystore at runtime as i will be contacting multiple SSL enabled servers (Don't know this approach will be successfull or not)
Please suggest a way to how to create a tomcat keystore file using java program or any other way to bypass SSL handshake
Where are you getting sslhandshake error exactly? While client wants to connect to tomcat server or while tomcat server is trying to connect to other servers for some purpose? And can you paste the exception trace?
In either case, it does not make any sense to create keystore programatically in a server but one can inspect java's keytool source code to play on keystores.
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/security/tools/KeyTool.java/
Look at the How-To guide SSL configuration on Tomcat's official site
http://tomcat.apache.org/tomcat-4.1-doc/ssl-howto.html
In my project,I have integrated Spring Security with CAS server authentication. Now my project is an http application where as the CAS server is an Https application. I was getting following exception after Spring Security and CAS integration: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
In order to solve this error ,I replaced CAS server usr\java\jre\lib\security\cacerts file with my local usr\java\jre\lib\security\cacerts file. After this step the error was gone.
Now I want to deploy my application to some other server. In this new server some other applications are also deployed which may be using different CAS authentication. I cannot directly replace my CAS server cacerts file with this new server cacerts file as in that other application deployed may fail.Right? Can anyone suggest what should I do so that cacerts can be merged,or what should be done? i got to know a command called as keytool but unable to understand how it could be used to merge cacerts file. I dont know how to get my CAS server .cer file,I got to know this could be used in merging,please suggest solution
There is a missunderstanding here.
cacerts is Java's default truststore containing all the trusted certificates for known CA's (Verisign etc). So java can by default trust these certificates same way that your browser does.
This truststore should be used when you want to connect to servers that are signed by these CAs.
In all other cases you are expected to use your own custom truststore so that you can trust specific servers.Actually this is the norm.
So what you should be doing is to load in your code your own truststore and provide that to Java's JSSE to use for authentication during handshake
I'm trying to configure a Client/Server app after setting up 2-way SSL using the java SSLRMIClientSocketFactory and SSLRMIServerSocketFactory. I know that to set the keystore and truststore on the client I need to set -Djavax.net.ssl.trustStore and -Djavax.net.sslkeyStore.
The way I understand it Java web start downloads the jnlp and verifies the jar and launches the Client java application in a sandbox that then connects to the server application over RMI. The problem is that when the application is run in this sandbox, the default truststore and keystore is not the same as what java web start uses. Instead there is no default keystore and the default truststore is $JAVA_HOME/jre/lib/security/cacerts
Is there a way to use the same truststore and keystore that javaws uses? Ideally I would like to use the same trusted certs and client certs that the browser uses (and by extension javaws). This way If the users configure their certificate through the Java Control Panel, then the application will use the same certificates.