My Scenario:
I have 2 different keystores(A.jks and B.jks) which are used for SSL connections to two different servers. These keystores work from the command line when doing "smoke-tests".
Using an EAP server, if the call to web-service A (Using A.jks) happens before web-service B(Using B.jks), then web-service A is successful and web-service B is unsuccessful - resulting with SSLHandshakeException. This error also happens when the order is reversed..ie. call to web-service B (Using B.jks) happens before web-service call A(Using A.jks), then web-service B is successful and web-service A is unsuccessful.
Question: What would cause the KeyStores loaded in the Server context to override each other?
Wildfly/ EAP does not play well with multiple TrustStores. Add the Certs. to one TrustStore and load that. This solution worked for me.
Related
I need to create a Java based XML web service client which is deployed in IBM WAS server which calls web service hosted by external system. Here 2 way ssl authentication mechanism should be there.
Configuration team has already set up the below things in quality environment of client and web service appservers:
At WAS server in which my web service client exists:
server certificate in the trustStore
client certificate is available in the keystore
At App server in which actual WebService exists:
server certificate in the keyStore
client certificate is available in the trust store
Coding:
we Auto generated classes using WSDL file provided by WS provider.
called the WS method normally like there is no 2 way ssl authentication mechanism in place.
problem: we are getting a connection exception when calling web service method from WS Client.Seems we have trouble with the 2 way ssl mechanism.
Full StackTrace Image as requested:
Assumptions:
we assumed that the entire handshake process of 2 way SSL process happens automatically when the web service call is done normally from the client.
Queries:
Is our assumption correct that entire handshake process happens
automatically here especially client sending its certificate ?
Do we need to specify at code level in java any details of path of
trust Store or KeyStore before calling the web service method to enable client to send its certificate ?
If Yes for Qn 2 do we need to set below properties in code as mentioned in some reference links
before calling WS method in client:
System.setProperty("javax.net.ssl.keyStore", "path/to/your/key");
System.setProperty("javax.net.ssl.keyStorePassword", "your-keystore- password");
System.setProperty("javax.net.ssl.trustStore","path/to/your/trust/keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "your-truststore-password");
Any suggestions/advice are highly welcome as we are stuck with this since few days.Its the first time we are working on web services which need 2 way SSL.
I'm consuming a web service in a java class standalone and it works fine.
I deployed that class as a part of a web-app in tomcat apache and it works fine.
Then, I deployed it in a glassfish server and I get this error:
WSS1601: Transport binding configured in policy but incoming message was not SSL enabled
I have several weeks stuck here. Seems like some glassfish setting doesn't accepts that my web-app uses a web service that works through HTTP (this is, and has to be the case).
The webservice client was made with the web service client wizard tool of netbeans (it uses wsimport-JAX-WS). More details on the error trace from the server:
com.sun.xml.wss.impl.XWSSecurityRuntimeException: WSS1601: Transport binding configured in policy but incoming message was not SSL enabled
at com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:125)
Has anybody else faced this issue?
Any help or ideas appreciated.
EDIT: I tried generating the stubs using the axis2 tool and it works great, so i'm sensing some kind of error in jax-ws when used in glassfish.
I guess you are trying to access the service enables with SSL. Try invoking the service with https also you have to install the valid SSL certificate in the client JDK.
The following link explain how to obtain and install a signed certificate :
https://docs.oracle.com/cd/E19798-01/821-1794/aeogl/index.html
Good luck :)
Background:
I am working on a project that involves the client to authenticate itself (via client certificate). We are trying to launch a third party app which first authenticates the client cert and then launches its app.
We are using Java and SSL hanshake, and our client server is Weblogic 10.x. The client certificate is in PKCS12 format (cannot change this)
This is the piece of code for presenting the certificate:
System.setProperty("javax.net.ssl.keyStore","MyPath/cert.pfx");
System.setProperty("javax.net.ssl.keyStorePassword","MyPwd");
System.setProperty("javax.net.ssl.keyStoreType","PKCS12");
url.openConnection();
Now all this works pretty well from a standalone. The problem starts when we put this on weblogic. Sometimes it works, sometimes 'Client certificate not present' (http 403.7) is returned. I have tried various combinations (including configuring custome keystore on weblogic console) but nothing seems to work. Any idea why would weblogic altogether ignore the SSL settings (it doesnt throw an error even if I set keystore to a non-existent file)? System.setProperty for SSL just appears useless on weblogic!
In Weblogic 12c you also need add the parameter -DUseSunHttpHandler=true in order to tell the weblogic server to use the Sun Http Handlers instead of its own. Therefore you need the following Java VM parameters:
-Djavax.net.ssl.keyStore=MyPath/cert.pfx
-Djavax.net.ssl.keyStoreType=PKCS12
-Djavax.net.ssl.keyStorePassword=MyPwd
-DUseSunHttpHandler=true
Finally found the solution! Weblogic seems to over-ride the keystore configurations if it is done through Java as above. The thing that worked for me was to configure the SSL settings on JVM level, at web-logic start-up.
To make it work, I just added these Java options in the start-script for weblogic:
-Djavax.net.ssl.keyStore=MyPath/cert.pfx
-Djavax.net.ssl.keyStoreType=MyPwd
-Djavax.net.ssl.keyStorePassword=PKCS12
Restarted web-logic and SSL has been working great since then :)
I am connecting to a WCF web service with a Java client I am constructing. Someone else has already successfully built WCF clients to connect to this service. The WSDL available via HTTP provides Message Level Security. The WSDL available via HTTPS uses both TLS and Message Level Security. I understand that using TLS on top of Message Level Security is basically dual-encrypting, but that is a key requirement.
Since I can connect to the HTTP service correctly, I believe I have all the trust store and key store issues resolved.
I am connecting to the service using Metro 2.1.1. I have built the client in both Eclipse and Netbeans. I fetch the WSDL from the HTTP site, and using wsimport (with the -extensions flag) I build and execute the clients successfully.
When I fetch the WSDL using the HTTPS site I can again build both clients successfully. But when I execute them - I get the following error:
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: An error occurred when verifying security for the message.
at com.sun.xml.ws.fault.SOAP12Fault.getProtocolException(SOAP12Fault.java:225)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:122)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy43.request(Unknown Source)
The only difference between the two WSDLs (the one fetched via HTTP and the other via HTTPS) is the reference in the WSDL to HTTPS:// vs. HTTP://.
I do not have easy access to the WCF service logs - normally there is a 3-6 hour delay between when I request a set of logs and when I can view them.
My question is has anyone encountered a similar circumstance - and is there something I am blatantly missing here? Is there something in a NetMon or Wireshark trace I can look for to see that the issue is? I have been struggling with this for days - any help would be most appreciated.
If you have access to the service configuration try disabling security context on the endpoint you're using:
<message establishSecurityContext="False" clientCredentialType="UserName"/>
You can read more about security context token (SCT):
Security Context Token
Message security knobs
Java client for WCF service with wsHttpBinding over SSL
The scenario is around calling an external SSL SOAP web service from within Mirth. The web service is requires an SSL/TLS connection along with a client certificate.
The intention is to use the built-in SOAP Sender Destination to call the remote secure web service, and somehow include that client certificate.
I understand that you first need to install that client certificate into the Java runtime. This may be within the Java runtime's certificate store or the Jetty certstore.
The platform:
Windows 2003 SP2
Mirth 1.8
Java jre1.5.0_09
Question: what configuration steps (Mirth, JRE certificate stores, etc.) would you suggest to successfully have a Mirth SOAP Sender include a client certificate (*.cer) when calling a web service secured by SSL?
The Java runtime, or more specifically, the Sun JSSE provider, will present a client certificate if some system properties are set. You can read details in the JSSE Reference Guide, but the important properties are javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword.
There are a few drawbacks to this approach. First, setting the key store password as a system property makes it accessible to any code running in that process—although this can be controlled if a SecurityManager is installed. Second, these settings will be used for any SSL sockets created through the "default" SSLContext. If you need different credentials for different endpoints, you'll need a Mirth-specific solution.
No starting point was specified in the question, but if starting from scratch, the easiest approach is to create a new Java Key Store ("JKS" format) and generate a new key pair and a CSR. After sending the CSR to the CA and getting a certificate back, import it into the same key store. That key store is ready to use.
If a certificate is already available, it is likely to be in a stored with its corresponding private key in PKCS #12 format (.p12 or .pfx file). These can be used directly by a Java application, but the javax.net.ssl.keyStoreType property will need to be set to "PKCS12"
Mirth 1.8 cannot send a client cert when calling a SOAP web service.
I'm late a bit here for this but actually there is a possibility that it could. By sending a few config parameters to the JVM you could get the underlying SOAP engine to switch to HTTPs and provide the proper certificate.
refer to this question for details on which parameters to set for configuring the VM
Java HTTPS client certificate authentication
you will notice there are quite a few things to take care of. Normally HTTPs and client authentication should "just work" once you configured your certificates appropriately. BUT there are some servers out there that are not so friendly to B2B style clients so you have to watch out.
Using JDK 6_21 and a few tweaks with the certificate I was able to get one of them servers to behave but it was long and painful on our side for something that takes about 15 minutes to configure properly on the server.
here is another question that address this very issue (client side authentication towards unfriendly servers).
Client SSL authentication causing 403.7 error from IIS