sslv2 and sslv3 compatability or a cert issue?

Question

I have a unix script running in server "CCC" from which am calling a servlet running in another server "GGG".(The server GGG is a secure server, having extra firewalls compared to normal server)

Also, the CCC is a ETL server, which is having a JRE. The script is calling the servlet using http, since I rule is applied, so redirection is happening to https, and the port no is also changing.

And am getting a bad certificate error, when i try to invoke the servlet.

The servlet URL when given in normal IE or chrome is giving me a valid response, am able to hit the server GGG.

The error am getting is :

javax.net.ssl.SSLHandshakeException: bad certificate
    at com.ibm.jsse.bg.a(Unknown Source)
    at com.ibm.jsse.b.a(Unknown Source)
    at com.ibm.jsse.b.write(Unknown Source)
    at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
    at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:139)
    at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpConnection.java:827)
    at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1975)
    at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
    at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397)
    at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
    at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
    at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
    at com.tgt.task.client.TaskClient.doGet(TaskClient.java:153)
    at com.tgt.task.client.TaskClient.runClient(TaskClient.java:91)
    at com.tgt.task.client.TaskClient.completeTask(TaskClient.java:68)
    at com.tgt.task.client.TaskClient.main(TaskClient.java:53)

So, initially i checked the certs in cacerts for CCC server, it is having all the root certs, except the cert issued to the URL.

We found the issue started after the BIG IP cert renewal for the URL, i have followed up with my network team to have a look into the issue, they have confirmed that traffic from server CCC is going through fine to GGG passing the firewalls.

So captured the traffic when we tried to invoke the URL, we got the below:

client  server  SSLV2   282 Client Hello
server  client  SSLV3   1631    Server Hello
server  client  SSLv3   433 Certificate
client  server  SSLV3   190 Alert(Level: Fatal, Description: Bad Certificate)

Can you let me know is the issue because of the SSL versions used by the client and the server ?

or some other thing that i missed out in my analysis.

I even tried to import the cert for the URL in to cacerts in server CCC, but i got the errors:

keytool error: java.lang.Exception: Input not an X.509 certificate

So , i took the PKCS7 cert for the URl and tried to convert it into .cer and tried to import, but got the same error.

Please narrow down the error to a simple reproducible use case (does it happen without redirection?). This sounds like a Rube Goldberg machine at the moment. — Martin Konecny, Jun 05 '14 at 05:25
Nope, without redirection to https, we cannot invoke the servlet. I agree with your comment, but i want to know why am getting a bad certificate error ? — user3709612, Jun 05 '14 at 05:41
Some additional information would help in pinning down the solution. When you use a browser to access GGG, are you using the IP address or the domain name? When CCC accesses GGG, does it use the IP address or the domain name? — Warren Dew, Jun 05 '14 at 06:37
It looks like you're using an IBM JRE. Have you tried with an Oracle JRE to see if it made any difference? — Bruno, Jun 05 '14 at 11:38

score 0 · Answer 1 · answered Jun 05 '14 at 07:14

0

If it works with the browser, but not with a script, it has often to do with Server Name Indication (SNI). With SNI you can have multiple hosts with different certificates behind the same IP address. While all current browser support SNI, other implementations might not or might not enable SNI by default. If the client fails to use SNI on a site with multiple certificates behind the same IP it just gets the default certificate, which is often the wrong one.

I don't which Java version you are running, but I suggest you determine your version and then google of how to use SNI with your version. From my understanding SNI was enabled only in Java version 7.

answered Jun 05 '14 at 07:14

Steffen Ullrich

114,247
10
131
172

The Java version is "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM AIX 5L for PowerPC (64 bit JVM) build caix64142-20080515 (SR11) (JIT enabled: jitc)) – user3709612 Jun 05 '14 at 16:53
This would be Java 2 - I don't think you will get SNI working with this old version. And it probably stopped being supported long ago. – Steffen Ullrich Jun 05 '14 at 18:04

score 0 · Answer 2 · edited May 23 '17 at 12:20

I have checked the captured network packet and found that the URL is providing the correct certificate to the server CCC as per the SSL configuartions at BIG IP end, the client CCC is not able to validate it. And returning a bad certificate message.

here i tried openssl and tried the command:

s_client -connect host:443
verify error:num=20:unable to get local issuer certificate
verify error:num=27:certificate not trusted
verify error:num=21:unable to verify the first certificate

`No client certificate CA names sent`
 SSL handshake has read 1745 bytes and written 304 bytes
 New, TLSv1/SSLv3, Cipher is RC4-SHA
 Server public key is 1024 bit
 Compression: NONE
 Expansion: NONE
 SSL-Session:
Start Time: 1402019174
Timeout   : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)

I guess my server is not sending the complete trust chains list, as a result, client is not able to validate it.

Am not sure whether my analysis is correct or not, also i referred the below post:

OpenSSL: unable to verify the first certificate for Experian URL

If i need to send my server to send the complete trusted chain list, where i need to change the settings ? at BIG Ip end, or at server end ?

sslv2 and sslv3 compatability or a cert issue?

2 Answers2