SSL jdbc connection fails with Diffie-Hellman (DH_ANON) cipher suites - ssl

I am trying create an SSL enabled connection to the Oracle database 11g (Release 11.2.0.1.0) using jdbc. I just want to use SSL for encryption only and not authentication, which is why I am using the Diffie-Hellman anonymous cipher suites, but it is failing.
I totally understand that anonymous cipher suites are not advisable and inherently insecure against man-in-the-middle attacks and probably I will not use it in production. But I would still like to find out what is wrong with my implementation that is preventing the ssl connection. Following is the excerpt of the code
String url = "jdbc:oracle:thin:#(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=<IP>)(PORT=2484))(CONNECT_DATA=(SERVICE_NAME=<service_name>)) )";
Properties props = new Properties();
props.setProperty("user", "hr");
props.setProperty("password", "hr");
props.setProperty("oracle.net.ssl_cipher_suites", "(SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_RC4_128_MD5, SSL_DH_anon_WITH_DES_CBC_SHA)");
// commented out since Diffie-Hellman cipher suite should not require trust store or key-store, but the connection works only if I uncomment it.
//props.setProperty("javax.net.ssl.trustStore", "/truststore/cwallet.sso");
//props.setProperty("javax.net.ssl.trustStoreType", "SSO");
Connection conn = null;
try {
//Security.insertProviderAt(new oracle.security.pki.OraclePKIProvider(),3);
Class.forName("oracle.jdbc.OracleDriver");
conn = DriverManager.getConnection(url, props);
System.out.println("conn " + conn);
} catch (Exception e) {
e.printStackTrace();
}
IN sqlnet.ora I added the following to make sure client is not authenticated and client server uses the same cipher suite:
SSL_CLIENT_AUTHENTICATION = FALSE
SSL_CIPHER_SUITES=(SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_WITH_RC4_128_MD5,SSL_DH_anon_WITH_DES_CBC_SHA)
However when I run the code I get the following error:
java.sql.SQLRecoverableException: IO Error: The Network Adapter could not establish the connection
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:419)
at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:538)
at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:228)
at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:521)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
at oracle.bi.modeling.Test.createConnection(Test.java:50)
at oracle.bi.modeling.Test.main(Test.java:18)
Caused by: oracle.net.ns.NetException: The Network Adapter could not establish the connection
at oracle.net.nt.ConnStrategy.execute(ConnStrategy.java:375)
at oracle.net.resolver.AddrResolution.resolveAndExecute(AddrResolution.java:422)
at oracle.net.ns.NSProtocol.establishConnection(NSProtocol.java:686)
at oracle.net.ns.NSProtocol.connect(NSProtocol.java:246)
at oracle.jdbc.driver.T4CConnection.connect(T4CConnection.java:1056)
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:308)
... 8 more
Caused by: oracle.net.ns.NetException: Unable to initialize ssl context.
at oracle.net.nt.CustomSSLSocketFactory.getSSLSocketFactory(CustomSSLSocketFactory.java:327)
at oracle.net.nt.TcpsNTAdapter.connect(TcpsNTAdapter.java:110)
at oracle.net.nt.ConnOption.connect(ConnOption.java:130)
at oracle.net.nt.ConnStrategy.execute(ConnStrategy.java:353)
... 13 more
Caused by: oracle.net.ns.NetException: Unable to initialize the trust store.
at oracle.net.nt.CustomSSLSocketFactory.getTrustManagerArray(CustomSSLSocketFactory.java:415)
at oracle.net.nt.CustomSSLSocketFactory.getSSLSocketFactory(CustomSSLSocketFactory.java:311)
... 16 more
Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:771)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
at java.security.KeyStore.load(KeyStore.java:1185)
at oracle.net.nt.CustomSSLSocketFactory.getTrustManagerArray(CustomSSLSocketFactory.java:406)
... 17 more
Caused by: java.security.UnrecoverableKeyException: Password verification failed
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:769)
... 20 more
If do specify the trust store, then the connection works fine when I uncomment the following lines:
props.setProperty("javax.net.ssl.trustStore", "/truststore/cwallet.sso");
props.setProperty("javax.net.ssl.trustStoreType", "SSO");
But Diffie-Hellman cipher suite should not require truststore or keystore. So what am I doing wrong?
I do see the following in one of oracle docs:
http://docs.oracle.com/cd/B28359_01/network.111/b28530/asossl.htm#i1009717
"There is a known bug in which an OCI client requires a wallet even when using a cipher suite with DH_ANON, which does not authenticate the client."
However I am not using OCI client. Instead I am using JDBC (ojdbc6.jar). Does the same exist even in JDBC? If so what is the work around to use Diffie-Hellman cipher suite?
Thanks
Joyjit

Related

JMeter: "javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake" while recording in JMeter [duplicate]

I am getting javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake exception when I try to do HTTPS Post of a web service through internet. But same code works for other internet hosted web services. I tried many things, nothing is helping me. I posted my sample code here. Can anyone please help me to resolve this problem?
public static void main(String[] args) throws Exception {
String xmlServerURL = "https://example.com/soap/WsRouter";
URL urlXMLServer = new URL(xmlServerURL);
// URLConnection supports HTTPS protocol only with JDK 1.4+
Proxy proxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress(
"xxxx.example.com", 8083));
HttpURLConnection httpsURLConnection = (HttpURLConnection) urlXMLServer
.openConnection(proxy);
httpsURLConnection.setRequestProperty("Content-Type","text/xml; charset=utf-8");
//httpsURLConnection.setDoInput(true);
httpsURLConnection.setDoOutput(true);
httpsURLConnection.setConnectTimeout(300000);
//httpsURLConnection.setIgnoreProxy(false);
httpsURLConnection.setRequestMethod("POST");
//httpsURLConnection.setHostnameVerifier(DO_NOT_VERIFY);
// send request
PrintWriter out = new PrintWriter(
httpsURLConnection.getOutputStream());
StringBuffer requestXML = new StringBuffer();
requestXML.append(getProcessWorkOrderSOAPXML());
// get list of user
out.println(requestXML.toString());
out.close();
out.flush();
System.out.println("XML Request POSTed to " + xmlServerURL + "\n");
System.out.println(requestXML.toString() + "\n");
//Thread.sleep(60000);
// read response
BufferedReader in = new BufferedReader(new InputStreamReader(
httpsURLConnection.getInputStream()));
String line;
String respXML = "";
while ((line = in.readLine()) != null) {
respXML += line;
}
in.close();
// output response
respXML = URLDecoder.decode(respXML, "UTF-8");
System.out.println("\nXML Response\n");
System.out.println(respXML);
}
Full stacktrace:
Exception in thread "main" javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:946)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1091)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
at com.labcorp.efone.vendor.TestATTConnectivity.main(TestATTConnectivity.java:43)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:482)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
... 8 more
Actually, there are two scenarios here. When I work as a standalone Java program I am getting the above exception. But when I try to execute in weblogic application server, I am getting the below exception: Any clue what could be the reason?
java.io.IOException: Connection closed, EOF detected
at weblogic.socket.JSSEFilterImpl.handleUnwrapResults(JSSEFilterImpl.java:637)
at weblogic.socket.JSSEFilterImpl.unwrapAndHandleResults(JSSEFilterImpl.java:515)
at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:96)
at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:75)
at weblogic.socket.JSSEFilterImpl.write(JSSEFilterImpl.java:448)
at weblogic.socket.JSSESocket$JSSEOutputStream.write(JSSESocket.java:93)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.java:192)
at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:433)
at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:37)
at com.labcorp.efone.service.impl.WorkOrderServiceImpl.processATTWorkOrder(ATTWorkOrderServiceImpl.java:86)
at com.labcorp.efone.bds.WorkOrderBusinessDelegateImpl.processATTWorkOrder(WorkOrderBusinessDelegateImpl.java:59)
at com.labcorp.efone.actions.ATTWorkOrderAction.efonePerformForward(ATTWorkOrderAction.java:41)
at com.labcorp.efone.actions.EfoneAction.efonePerformActionForward(EfoneAction.java:149)
at com.labcorp.efone.actions.EfoneAction.execute(EfoneAction.java:225)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:751)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:844)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:280)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:254)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:136)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:341)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at com.labcorp.efone.security.EfoneAuthenticationFilter.doFilter(EfoneAuthenticationFilter.java:115)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3367)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3333)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2220)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2146)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2124)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1564)
at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:254)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:254)
Exception: java.io.IOException: Connection closed, EOF detected
Java 7 defaults to TLS 1.0, which can cause this error when that protocol is not accepted. I ran into this problem with a Tomcat application and a server that would not accept TLS 1.0 connections any longer. I added
-Dhttps.protocols=TLSv1.1,TLSv1.2
to the Java options and that fixed it. (Tomcat was running Java 7.)
I faced the same problem and solved it by adding:
System.setProperty("https.protocols", "TLSv1,TLSv1.1,TLSv1.2");
before openConnection method.
Not an answer yet, but too much for a comment. This is clearly not a server cert problem; the symptoms of that are quite different. From your system's POV, the server appears to be closing during the handshake. There are two possibilities:
The server really is closing, which is a SSL/TLS protocol violation though a fairly minor one; there are quite a few reasons a server might fail to handshake with you but it should send a fatal alert first, which your JSSE or the weblogic equivalent should indicate. In this case there may well be some useful information in the server log, if you are able (and permitted) to communicate with knowledgeable server admin(s). Or you can try putting a network monitor on your client machine, or one close enough it sees all your traffic; personally I like www.wireshark.org. But this usually shows only that the close came immediately after the ClientHello, which doesn't narrow it down much. You don't say if you are supposed to and have configured a "client cert" (actually key&cert, in the form of a Java privateKeyEntry) for this server; if that is required by the server and not correct, some servers may perceive that as an attack and knowingly violate protocol by closing even though officially they should send an alert.
Or, some middlebox in the network, most often a firewall or purportedly-transparent proxy, is deciding it doesn't like your connection and forcing a close. The Proxy you use is an obvious suspect; when you say the "same code" works to other hosts, confirm if you mean through the same proxy (not just a proxy) and using HTTPS (not clear HTTP). If that isn't so, try testing to other hosts with HTTPS through the proxy (you needn't send a full SOAP request, just a GET / if enough). If you can, try connecting without the proxy, or possibly a different proxy, and connecting HTTP (not S) through the proxy to the host (if both support clear) and see if those work.
If you don't mind publishing the actual host (but definitely not any authentication credentials) others can try it. Or you can go to www.ssllabs.com and request they test the server (without publishing the results); this will try several common variations on SSL/TLS connection and report any errors it sees, as well as any security weaknesses.
A first step to diagnose the issue is by starting the client - and if you are running the server yourself, a private test instance of the server - by starting Java with the VM option:
-Djavax.net.debug=all
See also https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https
I encountered a similar problem with glassfish application server and Oracle JDK/JRE but not in Open JDK/JRE.
When connecting to a SSL domain I always ran into:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
...
Caused by: java.io.EOFException: SSL peer shut down incorrectly
The solution for me was to install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files because the server only understood certificates that are not included in Oracle JDK by default, only OpenJDK includes them.
After installing everything worked like charme.
JCE 7: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html
JCE 8: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
I think you are missing your certificates.
You can try generating them by using InstallCerts app. Here you can see how to use it:
https://github.com/escline/InstallCert
Once you get your certificate, you need to put it under your security directory within your jdk home, for example:
C:\Program Files\Java\jdk1.6.0_45\jre\lib\security
Let me know if it works.
I ran into a similar issue and found I was hitting the wrong port. After fixing the port things worked great.
In my case, I got this problem because I had given the server a non-existent certificate, due to a typo in the config file. Instead of throwing an exception, the server proceeded like normal and sent an empty certificate to the client. So it might be worth checking to make sure that the server is providing the correct response.
I experienced this error while using the Jersey Client to connect to a server. The way I resolved it was by debugging the library and seeing that it actually did receive an EOF the moment it tried to read. I also tried connecting using a web browser and got the same results.
Just writing this here in case it ends up helping anyone.
You May Write this below code insdie your current java programme
System.setProperty("https.protocols", "TLSv1.1");
or
System.setProperty("http.proxyHost", "proxy.com");
System.setProperty("http.proxyPort", "911");
Thanks to all for sharing your answers and examples. The same standalone program worked for me by small changes and adding the lines of code below.
In this case, keystore file was given by webservice provider.
// Small changes during connection initiation..
// Please add this static block
static {
HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier()
{ #Override
public boolean verify(String hostname, SSLSession arg1) {
// TODO Auto-generated method stub
if (hostname.equals("X.X.X.X")) {
System.out.println("Return TRUE"+hostname);
return true;
}
System.out.println("Return FALSE");
return false;
}
});
}
String xmlServerURL = "https://X.X.X.X:8080/services/EndpointPort";
URL urlXMLServer = new URL(null,xmlServerURL,new sun.net.www.protocol.https.Handler());
HttpsURLConnection httpsURLConnection = (HttpsURLConnection) urlXMLServer .openConnection();
// Below extra lines are added to the same program
//Keystore file
System.setProperty("javax.net.ssl.keyStore", "Drive:/FullPath/keystorefile.store");
System.setProperty("javax.net.ssl.keyStorePassword", "Password"); // Password given by vendor
//TrustStore file
System.setProperty("javax.net.ssl.trustStore"Drive:/FullPath/keystorefile.store");
System.setProperty("javax.net.ssl.trustStorePassword", "Password");
I encountered this problem with Java 1.6. Running under Java 1.7 fixed my particular rendition of the problem. I think the underlying cause was that the server I was connecting to must have required stronger encryption than was available under 1.6.
I had the same error, but in my case it was caused by the DEBUG mode in Intellij IDE. The debug slowed down the library and then server ended communication at handshake phase. The standard "RUN" worked perfectly.
I run my application with Java 8 and Java 8 brought security certificate onto its trust store. Then I switched to Java 7 and added the following into VM options:
-Djavax.net.ssl.trustStore=C:\<....>\java8\jre\lib\security\cacerts
Simply I pointed to the location where a certificate is.
I was using the p12 which I exported with Keychain in my MacBook, however, it didn't work on my java-apns server code. What I had to do was to create a new p12 key as stated here, using my already generated pem keys:
openssl pkcs12 -export -in your_app.pem -inkey your_key.pem -out your_app_key.p12
Then updated the path to that new p12 file and everything worked perfectly.
How you would solve it is by going to
Settings
Search"Network"
Choose "Use IDEA general proxy settings as default Subversion"
As per https://kb.informatica.com/solution/23/Pages/69/570664.aspx adding this property works
CryptoProtocolVersion=TLSv1.2
With base at TLSv1.2 ALERT: fatal, handshake_failure I obtained after debug with this thread previos answer
-Djavax.net.debug=all
I went to https://www.ssllabs.com/and observed that the web server required a SSLv3 connection deprecate at june 2015, and deprecated at JDKu31 Release notes
I edited the ${java_home}/jre/lib/security/java.security at the line
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024,
EC keySize < 224, 3DES_EDE_CBC, anon, NULL
to
jdk.tls.disabledAlgorithms= RC4, DES, MD5withRSA, DH keySize < 1024,
EC keySize < 224, 3DES_EDE_CBC, anon, NULL
As a final step I got this error
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target [javax.net.ssl.SSLHandshakeException]
I fixed this intalling the cert with the java keytool, following this answer PKIX path building failed” and “unable to find valid certification path to requested target”
I get this error when specifying a https url and in the same url explicitly specifying an http port (instead of an https port). Removing the explicit port :8080 solved the issue for me.
Adding certificates to Java\jdk\jre\lib\security folder worked for me. If you are using Chrome click on the green bulb [https://support.google.com/chrome/answer/95617?p=ui_security_indicator&rd=1] and save the certificate in security folder.
I faced the same issue once. I think its because of the URL
String xmlServerURL = "https://example.com/soap/WsRouter";
Check whether its a proper one or not ??
javax.net.ssl.SSLHandshakeException is because the server not able to connect to the specified URL because of following reason-
Either the identity of the website is not verified.
Server's certificate does not match the URL.
Or, Server's certificate is not trusted.
This is what solve my problem.
If you are trying to use debugger make sure you breakpoint is not on URL or URLConnection just put your breakpoint on BufferReader or inside while loop.
If nothing works try using apache library http://hc.apache.org/index.html.
no SSL, no JDK update needed, no need to set properties even, just simple trick :)

ssl enabled oci connection - unknown cipher suite 157

I am trying to make an ssl based oci connection to Oracle 11g ssl enabled database using OBIEE BI server and Admin tool. The wallet and all required configurations are in place. However the connection establishment fails and in the sqlnet trace file I get the following error.
(12184) [25-OCT-2015 12:45:21:521] ntzcsgtab: INTERNAL ERROR - unknown cipher suite 157.
(12184) [25-OCT-2015 12:45:21:521] ntzcsgtab: failed with error 543
(12184) [25-OCT-2015 12:45:21:521] ntzcsgtab: exit
(12184) [25-OCT-2015 12:45:21:521] ntzini: Could not initialize Cipher Suite table.
(12184) [25-OCT-2015 12:45:21:521] ntzini: failed with error 543
I am not specifying any particular cipher suite in sqlnet.ora either in client or database, and using the default ones.
Next I tried to create jdbc connection using oci driver (using oracle instant client) and using same wallet, in a simple java client program. I was able to successfully establish the SSL enabled connection.
So it seems like Oracle client inside OBIEE might be missing some feature to handle SSL based connection. Any idea how to fix this?
Thanks in advance

WebSphereMQ with HermesJMS

I use WebSphereMQ v7.1 and HermesJMS v1.14 SoapUI.
I set up everything to connect this apps without SSL and they work fine.
The problem is, when I try to connect with SSL. I set below params:
SSLCipherSuite: SSL_RSA_WITH_3DES_EDE_CBC_SHA
channel, hostName, port, queueManager,
transportType: 1
and in hermes.bat I added trustStore and keystore.
In WMQ I have set: TRIPLE_DES_SHA_US on channel. On this page-> http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.1.0/com.ibm.mq.doc/ja34740_.htm
I see that I match CipherSpec and CipherSuite correct.
What is wrong?
UPDATE
Below error from Hermes
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2397;AMQ9641: Remote CipherSpec error for channel 'channel1'. [3=channel1]
at com.ibm.mq.jmqi.remote.internal.system.RemoteConnection.analyseErrorSegment
(RemoteConnection.java:4322)
at com.ibm.mq.jmqi.remote.internal.system.RemoteConnection.receiveTSH
(RemoteConnection.java:2902)
at com.ibm.mq.jmqi.remote.internal.system.RemoteConnection.initSess
(RemoteConnection.java:1440)
at com.ibm.mq.jmqi.remote.internal.system.RemoteConnection.connect
(RemoteConnection.java:1115)
at com.ibm.mq.jmqi.remote.internal.system.RemoteConnectionPool.getConnection
(RemoteConnectionPool.java:350)
at com.ibm.mq.jmqi.remote.internal.RemoteFAP.jmqiConnect(RemoteFAP.java:1599)
On this page -> http://www-01.ibm.com/support/docview.wss?uid=swg21614686 I find that solution for this problem is:
Ensure that there is a cipher suite set on the client matching the
cipher spec on the queue manager's server connection channel.
but as I mentioned earlier I matched CipherSpec and CipherSuite correct.
Are using an Oracle JRE/JDK? I had the same issue and wrote about it here: http://www.capitalware.com/rl_blog/?p=3074
The simplest solution is to use IBM's JRE/JDK.

How to find out which cipher suites are supported by the FTP client via SSL/TLS?

I am running an FTP server based on Apache MINA/FTP and I keep getting the following exception when trying to connect in SSL mode:
javax.net.ssl.SSLHandshakeException: no cipher suites in common
I have verified that the cipher suites are set correctly on the client side like this:
SSLServerSocketFactory serverSocketFactory = (SSLServerSocketFactory)
SSLServerSocketFactory.getDefault();
String[] cipherSuites = serverSocketFactory.getDefaultCipherSuites();
SslConfigurationFactory sslConfigFactory = new SslConfigurationFactory();
sslConfigFactory.setKeystoreFile(keyStoreFile);
sslConfigFactory.setKeystorePassword(keyPass);
sslConfigFactory.setEnabledCipherSuites(cipherSuites);
sslConfigFactory.setSslProtocol("SSL");
SslConfiguration sslConfig = sslConfigFactory.createSslConfiguration();
sslFactory.setSslConfiguration(sslConfig);
Listener listener = sslFactory.createListener();
serverFactory.addListener("SSL-listener", listener);
So, how do I verify that the cipher suites used on the client side match the ones that are provided on the server side?
I am using FileZilla and Cyberduck for testing, but I haven't found anything in the settings of these clients that would tell which cipher suites are supported.
I found it useful to set the sysproperty javax.net.debug="ssl" at start time of the JVM and then watch stdout for a detailed report.

Accepting runtime-specified SSL certificates for Web Services requests in WebLogic 11g

In our application we need to call several Web Servervices based on URL's and trusted SSL certificates that are stored in database. Those certificates are self-signed but we cannot add them in the WebLogic truststore. This is 2-way SSL but our server refuses the remote certificate.
What is the right way to do this?
(The rest of the question describes what we already tried.)
In WebLogic 10g we used to do the following:
WlsSSLAdapter adapter = new WlsSSLAdapter();
try {
// setup for client certificate
adapter.setKeystore(…);
adapter.setClientCert(…);
// setup for accepting the remote certificate
adapter.setTrustManager(new TrustManager() {
#Override
public boolean certificateCallback(X509Certificate[] paramArrayOfX509Certificate, int paramInt) {
return paramArrayOfX509Certificate[0] == expectedCertificate;
}
});
} catch (Exception e) {
throw new RuntimeException(e);
}
((weblogic.wsee.jaxrpc.StubImpl) servicePort)._setProperty(weblogic.wsee.jaxrpc.WLStub.SSL_ADAPTER, adapter);
However in WebLogic 11g it appears that even if the TrustManager is called (which we checked by using a debugger), WebLogic refuses the certificate:
<validationCallback: validateErr = 16>
< cert[0] = Serial number: 9232073310112809071929676484517784211
Issuer:C=US, ST=MyState, L=MyTown, O=MyOrganization, OU=FOR TESTING ONLY, CN=mestoudi2
Subject:C=US, ST=MyState, L=MyTown, O=MyOrganization, OU=FOR TESTING ONLY, CN=mestoudi2
Not Valid Before:Tue Nov 01 14:33:31 CET 2011
Not Valid After:Sun Nov 02 14:33:31 CET 2031
Signature Algorithm:MD5withRSA
>
<weblogic user specified trustmanager validation status 16>
<Certificate chain received from mestoudi2 - 10.142.0.23 was not trusted causing SSL handshake failure.>
<Validation error = 16>
<Certificate chain is untrusted>
<SSLTrustValidator returns: 16>
<Trust status (16): CERT_CHAIN_UNTRUSTED>
<NEW ALERT with Severity: FATAL, Type: 42
java.lang.Exception: New alert stack
at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown Source)
at com.certicom.tls.record.handshake.ClientStateReceivedServerHello.handle(Unknown Source)
…
I think the first difference occurs on the line weblogic user specified trustmanager validation status 16 where in WebLogic 10g the value was 0 instead of 16.
If we check "Use JSSE SSL" in the WebLogic administration console (which switches the implementation to com.sun.net.ssl instead of com.certicom.tls), the TrustManager is not called at all.
We also tried to configure the TrustManager by implementing a javax.net.ssl.X509TrustManager that we set on a weblogic.wsee.connection.transport.https.HttpsTransportInfo passed to the stub using
((weblogic.wsee.jaxrpc.StubImpl) servicePort)._setProperty(TRANSPORT_INFO, transportInfo);
But it is not called either – however it works for setting up a proxy for example.
We are generating the stubs using the clientgen Ant task (weblogic.wsee.tools.anttasks.ClientGenTask).