I'm in the process of creating a simple Mule flow in Anypoint Studio - it polls a directory periodically, and when a file is placed in the directory it sends it to an SFTP server. However, when the application starts negotiating a secure connection with the server, it fails with this error:
java.io.IOException: Error during login to username#host:
Session.connect: java.security.InvalidAlgorithmParameterException: DH
key size must be multiple of 64, and can only range from 512 to 8192
(inclusive). The specific key size 2047 is not supported
The stack trace references several files from the jsch library. The solutions in previous questions recommended upgrading to Java 8, using a different version of jsch, or editing the jsch jars themselves. My Mule server (version 3.9.0 EE) is already on Java 8, I've tried a few different versions of jsch, and editing the jars is not practical, since this application will be deployed to a few different environments.
I'm able to log in to the sftp server using the same credentials as the application via WinSCP. A coworker has tried modifying a working flow to use the same credentials to move the same file, and they get the same error. Here is the XML of my flow:
<flow name="ClCoFlow">
<file:inbound-endpoint path="${file.from}"
moveToDirectory="${file.backup}" responseTimeout="10000"
doc:name="Get File to Transfer" />
<logger
message="#[flowVars.originalFilename] being moved to #[flowVars.moveToDirectory]"
level="INFO" doc:name="File In" />
<sftp:outbound-endpoint exchange-pattern="one-way"
host="${sftp.host}" port="${sftp.port}" path="${sftp.path}" user="${sftp.user}"
password="${sftp.password}" responseTimeout="10000" doc:name="SFTP" />
<logger message="#[flowVars.originalFilename] sent to sftp service"
level="INFO" doc:name="File sent" />
</flow>
Thanks in advance for any help you can provide
EDIT
Though Mule is built on Java, and Mule applications are built behind the scenes using Java and Spring, there is no writing of actual Java code involved in creating a Mule flow.
Changing the provider seems to be the way to go here. Unfortunately, there is no way to do so with Mule connectors, so we kind of have to re-write the sftp connector in plain Java. After downloading the bouncycastle .jars, put them in src/main/app/lib, then add them to the build path. You should be able to import them (for some reason I had to import org.python.bouncycastle.jce.provider rather than org.bouncycastle.jce.provider). At the top of my code I put :
Security.insertProviderAt(new BouncyCastleProvider(), 1);
and when the flow runs, the dh key is properly negotiated and no errors are thrown.
Related
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.
I wrote a simple app to send email to our smtp server. Java version is 1.8.0_101
Our server use only TLSv1.2. I wrote a simple app to send email to our server. I build this soft as jar and run it. It works normally and java use default tls version which is 1.2 on jdk1.8. Then I wrote a web service that accept request and send email to out smtp server. I use tomcat v9.0(also tested v7 and v8) I build war file and put the tomcat web app folder. But when I call my web service I got the below error
Could not convert socket to TLS.
Remote host closed connection during handshake
Then I realized that java does not use TLSv1.2 and use TLSv1. I tried lots of solution but no ones helped me. I could not change TLS version. Is there any way to change TLS version? Do I change this config on java side or tomcat?
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 having a application which when i run standalone runs well.
This application sends an XML to a server and listens for the reply from that server which is again an XML.This works WELL when running STANDALONE.
But when i run this application inside an web application it gives me follow error:
RSA Secret Premaster Error
I am using apache-tomcat,java-6(GWT).
Can anyone guide me on this issue..Thanks!!
I expect that this problem happens when your application is establishing an SSL (e.g. HTTPS) connection. To get more hints to what the root cause is, you need to print the complete stacktrace to see the nested chain.
If you do a Google search for "RSA premaster secret error" you will see lots of forum postings about this. A common thread of these postings seems to be that some IDE is being used to launch the web server or client, and the IDE is stuffing up the child JVM's bootclasspath in a way that causes the crypto libraries to break.