I've been working on a Java webservice client. It works fine for everybody except for one customer who has this error:
class java.lang.IllegalArgumentException :
SSLv2Hello cannot be enabled unless at least one other supported version is also enabled
I can't reproduce the error. We're using the same server trying to test it, and it works fine for me and all of my collegues. The only thing different that we're using our certificate and the user is using his.
Tried System.setProperty("https.protocols", "SSLv3");
Then I got this:
class javax.xml.ws.WebServiceException :
Failed to access the WSDL at: https:something:someport/something/something?wsdl. It failed with:
No appropriate protocol (protocol is disabled or cipher suites are inappropriate).
The client is using:
JVM: 1.8.0_40
Operating System: Windows 7
I'm clueless how can i solve this, or what path to take to further explore the problem.
SSLv2Hello cannot come alone, it needs another protocol to be allowed (SSLv3, TLS,..)
Your code seems to work as you can test it almost anywhere with good results. It's then an environment problem on the faulty tester, by configuration or JDK version.
Check environment variables, java.security file (particularly jdk.tls.disabledAlgorithms key which can be empty for testing) , and deployment.properties file if any.
It's often a good idea to dump all environment properties during the client or server startup.
Related
I'm trying to connect to MQ queue manager which uses 1 way SSL using Java client. Even after following all the steps mentioned in various blogs, I am still getting MQJE001: Completion Code '2', Reason '2400' error.
Please find the java code we are using:
Copying and pasting steps without understanding what they're doing isn't the best way to proceed. The same applies to pasting code as image here.
As per 2400 (0960) (RC2400) error description:
A connection to a queue manager was requested, specifying SSL encryption. However, JSSE reported that it does not support the CipherSuite specified by the application.
Check the CipherSuite specified by the application. Note that the names of JSSE CipherSuites differ from their equivalent CipherSpecs used by the queue manager.
Also, check that JSSE is correctly installed.
So you're trying to use cipher suite which might be supported by MQ but it's not supported by your local Java installation. You could try using Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files or obtaining the JDK from your MQ machine which should have the this ECDHE_RSA_AES_256_CBC_SHA384 cipher suite installed.
More information:
TLSv2 with JDk8 Ciphersuites with MQ8?
IBM MQ testing with JMeter - Learn How
IBM MQ error 2400 means UNSUPPORTED_CIPHER_SUITE.
Depending on the JDK vendor (IBM/Oracle), you can enable CipherSuite mapping with Java system property com.ibm.mq.cfg.useIBMCipherMappings. Based on your screenshot you want to use ECDHE_RSA_AES_256_CBC_SHA384. If you use the Oracle JDK, you have to do this in Java:
System.setProperty("com.ibm.mq.cfg.useIBMCipherMappings", "false");
...
MQEnvironment.sslCipherSuite = "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384";
If you are using MQ 9.2, you can also simply configure cipher suite *TLS12ORHIGHER.
What you are specifying is the queue manager CipherSpec, below is the table from CipherSuite mapping IBM Docs page showing which CipherSuite to use depending on the Java provider.
CipherSpec Equivalent
CipherSuite (IBM JRE) Equivalent
CipherSuite (Oracle JRE)
ECDHE_RSA_AES_256_CBC_SHA384
SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
If you are not using IBM JRE then you must specify the java system property:
com.ibm.mq.cfg.useIBMCipherMappings=false
Our company has upgraded from TLS 1.0 to TLS 1.2. Before this, we used to download files using org.apache.commons.net.ftp.FTPClient.
Now we cannot connect to the server using FTPSclent and we get an exception:
org.apache.commons.net.ftp.FTPConnectionClosedException: Connection closed without indication
How can I correctly connect to the server.
Full stack trace:
First of all, turn on the SSL debug as the javadoc sugests and try to connect, then check the output (it logs by default to std out, you should redirect it to a file).
The sorter answer
Give a try to the -Dhttps.protocols=TLSv1.2 JVM argument (this should be passed to every java code that you are using during your investigation and you have to use the same JRE of course too).
If does not work, check the server certificate, that should be installed to the JRE's default keystore (cacerts) or your custom keystore that you may use.
If this does not help, install the JCE extensions (JRE could not handle a cert that has at least 2048 bit key without JCE).
If all of these steps are useless, you may have the same problem than this guy.
The longer version
I hope that you are using at least Java7 (see the table of the available protocols on each platform).
The first thing is, that the TLS protocols supported by the server and supported by your application have to have an intersect.
In this table you can find the default TLS protocols of the different JRE versions, this is important because your client uses very probably the default TLS of the JRE.
So after you have checked your JRE and found the supported TLS versions, you should check the applied cyphers.
You should test your connection using nmap:
nmap.exe --script ssl-enum-ciphers -p <port> <ftp host>
with this tool, you can list the TLS version and the used cyphers. The cypher list can be compared with the list provided by this small java code. This two lists have to have at least one common point in order to be able to communicate.
You can download the server's certificate using Portecle, that certificate should be installed in the keystore of your client JRE.
If you have found that they have intersection in TLS protocols and in cyphers too, you have the right cert in your keystore, you can test that they can communicate with
SSLPoke
If this works too, then the problem should be in FTPClient.
I have following situation - I want to get page content using https request and java agent. However, I'm getting following error message:
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: Certificate chaining error
I already imported internet certificates to my local notes cacerts file, but nothing changed.
However, when I'm running same code in Eclipse, using keystore with certificates downloaded from page I try to receive and it works fine.
I'm out of ideas, any suggestions will be appreciated!
===EDIT===
Dmytro Pastovenskyi's answer helped me, but additionally to get rid of protocol_version exception I had to use following code, setting version of TLS used:
System.setProperty("https.protocols", "TLSv1");
It seems nessesary to establish connection to some sites using 1.6 IBM JAVA.
I had same issue some times before.
It looks like IBM Domino server more strict when it check certificates. Our administrator who at the beginning said that chain is correct later found an issue with chain (and yes, it worked for .NET/JAVA and other platform, just not with Domino). Try to find some online tools that verify chain.
Before chain is fixed you can simply disabled certificate validation. I've an article how to do it (+ some other articles that may help you). Have a look here: Disabling certificate validation in Java
I've been wracking my brain on this problem, here, and suddenly thought to check if ANY cipher suites were available to the RMI Server. So, I put the following code in JUST BEFORE the RMI Registry is started:
msg("trustStore: "+System.getProperty("javax.net.ssl.trustStore"));
msg("trustStorePassword: "+System.getProperty("javax.net.ssl.trustStorePassword"));
msg("keyStore: "+System.getProperty("javax.net.ssl.keyStore"));
msg("keyStorePassword: "+System.getProperty("javax.net.ssl.keyStorePassword"));
msg("rmi.server.hostname: "+System.getProperty("java.rmi.server.hostname"));msg("supportedCipherSuites: "+System.getProperty("javax.rmi.ssl.client.supportedCipherSuites"));
msg("enabledCipherSuites: "+System.getProperty("javax.rmi.ssl.client.enabledCipherSuites"));
msg("debug: "+System.getProperty("javax.net.debug"));
(where msg just sends data via System.out.println.)
...And to my horror found that "supportedCipherSuites" is NULL!
What?!
I looked all over creation, "used the google", and haven't yet figured out how I'm supposed to populate my instalation with suitable cipher suites. ...I'm not looking for much special, just the basic ordinary stuff will do fine!
Arg!
P.S. Where does the RMI Registry's output from javax.net.debug go? Can't find it anywhere! Thanks....
You'll find the list of supported cipher suites in Oracle JRE 7 in the SunJSSE provider documentation: there are two tables for those enabled and disabled by default, respectively.
I wouldn't worry too much about System.getProperty("javax.rmi.ssl.client.supportedCipherSuites")) returning null: these system properties are for you to make settings, not for the JRE/RMI API to publish its current state. In addition, there is no mention of this system property in the documentation where javax.rmi.ssl.client.enabledCipherSuites is documented.
If you want to use specific cipher suites, set javax.rmi.ssl.client.enabledCipherSuites, don't read it.
Getting the javax.net.ssl.* properties won't necessarily tell you what the actual used values are (see this answer). For example a null javax.net.ssl.trustStore will still use the default truststore.
Same for javax.net.debug: it's for you to set and the Net/SSL API to use, not the other way around.
I'm trying to upgrade from BouncyCastle bcprov-jdk14-124.jar (oooold) to bcprov-jdk14-143.jar. When I replace the old jar with the new jar and build everything, my software will no longer establish an SSL connection, failing with a javax.net.ssl.SSLException: Received fatal alert: illegal_parameter. Googling for "bouncycastle javax.net.ssl.SSLException illegal_parameter" yields a whopping 4 results.
Any suggestions on where to start debugging this?
Additional context:
client is on WinXP
server on CentOS, using Oracle Application Server
The client is attempting to establish an SSL connection for an AXIS2 POST.
When the server uses bcprov-jdk14-143 and the client uses bcprov-jdk14-124, the POST succeeds, but when the client is upgraded to 143, I get this error
I am a little bit confused about your setup. Your error is from JSSE but BC doesn't provide JSSE. I assume the error is from server, which uses SunJSSE. You probably use BC's TLS API from client to make the TLS connection (check if you have TlsProtocolHandler).
If this is the case, getting everything working is already a miracle on Java 1.4, I wouldn't upgrade anything. Before Java 5, Sun's JSSE is partially hard-wired to SunJCE so you are practically using 2 JCEs at the same time on the server. I played with TLS from BC before and I never got it working so you are way ahead of me :)
Why do you need to upgrade BC? In my opinion, there is no reason to use BC at all if you are on Java 1.4 or later. However, it requires code changes to remove it if you use TlsProtocolHandler.
The specific error is caused by server sending down a list of compression methods. There is no way to get around that. Nobody supports compression but they all send down a list with only Null method.