Develop Reference

sslv2 and sslv3 compatability or a cert issue?

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.

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.

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 ?

ClientRequest accept all certificates

I'm using the ClientRequest library to perform a 'GET' request however I'm running into a certificate error:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:397) [jsse.jar:1.7.0_40]
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.jboss.resteasy.client.core.executors.ApacheHttpClient4Executor.execute(ApacheHttpClient4Executor.java:182) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1]
Since this is just a test environment, I want to be able to ignore or accept all certificates over https. (I know this defeats the purpose of ssl.) Any pointers in the right direction is much appreciated!
ClientRequest request = new ClientRequest(someURL.toString());
ClientResponse<SomeClass> response = null;
response = request.get(SomeClass.class);
response.getEntity();

Since you're using Apache HTTP Client, with a certificate that's not trusted by default, this exception has the same cause as "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed" in most other uses of SSLSocket (see this answer for details): essentially, it's an indication that your certificate isn't trusted.
Instead of ignoring the error (by adding specific code to bypass any certificate validation, code you may forget about when you get closer to the release deadline), import your custom certificate in your truststore. For example, create a local copy of the cacerts file bundled with your JRE, use keytool to import your custom certificate, and point the javax.net.ssl.trustStore system property (and related properties) to that file when you start your JVM.

SSLPeerUnverifiedException: peer not authenticated WITH VALID CERTIFICATE

I have https certificate signed by Geo Trust. All browsers opens my site very well. My app authorizing through https, and most time everything OK. But sometimes users can't connect and have error:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(Unknown Source)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at org.greencubes.downloader.Downloader.downloadFile(Unknown Source)
at org.greencubes.lil.Launcher.<init>(Unknown Source)
at org.greencubes.lil.Launcher.main(Unknown Source)
Last user had windows 7 x86 and java 1.7_45u. It happens on random OSs and random java updates, i don't know the reason. Sometimes it's not happening, but usually if user have such error nothing can help.
I can not add certificate to user's keysore as this is user application.
Target url is auth.greencubes.org (empty response must return 403), you can check it.

So, i found a problem with help of one of my users. The problem in that Kaspersky Antivirus (or may be some other antiviruses/firewalls too, ESET NOD may be) inspecting encrypted connections by replacing SSL certificates, and default java keystore has no certificate of Kaspersky CA (cause it is generated on installation of antivirus).
First solution is to disable inspecting encrypted connections or inspection connections at all (web-antivirus functionality) or disabling antivirus.
The right solution is try to use Windows's KeyStore, where Antiviruses's CA Certificate was added by antivirus itself. It can be done by setting JVM parameter:
-Djavax.net.ssl.trustStoreType=Windows-ROOT
(It must be "Windows-ROOT", not "Windows-MY"!)
Or by executing this code when app starts (in main() function preferable):
System.setProperty("javax.net.ssl.trustStoreType", "Windows-ROOT");
You just need to be sure that it's windows system, so command-line argument is not general-purpose solution.
This code can be used to be sure that windows key store is present and valid:
if(System.getProperty("os.name").toLowerCase().contains("windows")) {
try {
KeyStore ks = KeyStore.getInstance("Windows-ROOT");
ks.load(null, null);
System.setProperty("javax.net.ssl.trustStoreType", "Windows-ROOT");
} catch(Exception e) {
// Ignore: windows keystore is bad, left default
}
}

Receiving SSLHandshakeException: handshake_failure despite my client ignoring all certs

I have a Java program that connects to a webserver using SSL/TLS, and sends various HTTP requests over that connection. The server is localhost and is using a self-signed cert, but my code is using custom TrustManagers, and ignores invalid certificates. It has worked perfectly until now.
The only difference on the server is that it used to run jboss 6 and is now running jboss 7. I'm not sure if this is a configuration issue, or whether there is a problem with my code, but I get the same errors if I try to connect using other Java-based programs like WebScarab or ZAP.
In any case, is there anything I can do to my code to get around this problem? Here is the error in full:
Received fatal alert: handshake_failure
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source)
Here are the debug messages before the failure:
main, WRITE: TLSv1 Handshake, length = 75
main, WRITE: SSLv2 client hello message, length = 101
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT: fatal, handshake_failure

So I found the problem. There might be a bug in Java, but the client seems to initiate a TLSv1 Handshake, but then sends an SSLv2 client hello message, at which point the server rejects the connection.
This happens even if you create your SSLContext with an instance of TLS:
SSLContext sslContext = SSLContext.getInstance("TLS");
The solution is to set a system property before any connection attempts are made:
System.setProperty("https.protocols", "TLSv1");
There are probably other solutions to it, but this one worked for me.

The info you provide is very little as well as your stack trace.
I'll take a guess here.
What I suspect is that in the new server the protocol is TLSv1 while your clients try to connect with SSLv3 (or less) and as a result the handshake fails.
Change you clients to use higher version of TLS
or
Make your webserver support SSLv3 as well. I know how to do this in Tomcat but not in JBoss.
If this doesn't work update the post with more info (and a full stack trace).
You should enable ssl debug info -Djavax.net.debug=ssl

Was this ever resolved?
I had the exact same problem, essentially I was receiving a handshake exception immediately following the clientHello. So The chain of events was
I would present my certificate to the server
Server would imediately respond with a handshake failure. (I would not even get a Server Hello back).
Eventually I found that the server was requiring a stronger encryption/decryption algorithm than what I Was supplying in the initial handshake phase (Ie. Client and Server could not agree on a mutual encryption algorithm to use for the ssl communication).
I need to install the Unlimited Java JCE (Java Cryptography Extension Policy). There are export rules on using this, so if you ship your code overseas that may have implications..however this is what solved my problem.
This link explains how to install the updated policies
http://suhothayan.blogspot.com/2012/05/how-to-install-java-cryptography.html
This was also a great link that helped me understand exactly what was going on
https://support.f5.com/kb/en-us/solutions/public/15000/200/sol15292.html#id
This may or may not be the issue, but when the handshake fails immediately after the client Hello, it looks like the client and the server can not agree on something (in many cases its the encryption algorithms that they will mutually need to communicate).

You are seeing this error most probably because the keystore that your JBoss 6 had access to is not accessible to your JBoss 7 instance.
What I would recommend is the following.
Your self-signed server certificate must be imported into a truststore
keytool -import -alias gridserver -file server.crt -storepass $YOUR_PASSWORD_HERE -keystore server.keystore
Add the following properties to your run.conf
-Djavax.net.ssl.keyStoreType=pkcs12
-Djavax.net.ssl.trustStoreType=jks
-Djavax.net.ssl.keyStore=clientcertificate.p12
-Djavax.net.ssl.trustStore=server.keystore
-Djavax.net.debug=ssl # very verbose debug. Turn this off after everything looks good.
-Djavax.net.ssl.keyStorePassword=$YOUR_PASSWORD_HERE
-Djavax.net.ssl.trustStorePassword=$YOUR_PASSWORD_HERE

The stack trace is from you client code and your client 'Received [a] fatal alert'. In other words, the SSL error happened in Jboss, not your client.
Your client side custom TrustManagers have therefore nothing to do with it. My wild guess is that your new Jboss 7 is configured to require client certificate and your client did not present any.
To debug your SSL connection, use openssl and try this:
openssl s_client -connect jboss.server.com:443
or is it is an SSLV3 server
openssl s_client -connect jboss.server.com:443 -ssl3
This should print a lot of interesting information.

I think this is related to a Java 7 bug. It is hard to be sure without more details.

For me solution was : System.setProperty("https.protocols", "TLSv1.1,TLSv1.2");

HANDSHAKE_FAILURE alert received

I am writing a Java client (on weblogic 10.3) to invoke a secure web service.
I have been provided with a client certificate which I have installed in cacerts, DemoIdentity.jks and DemoTrust,jks
In my weblogic I have set up keystore as DemoIdentity and DemoTrust.
In weblogic console I have set
"Two Way Client Cert Behavior:" as "Client Certs requested but not enforced".
and for "SSL Listen Port enabled:" I have checked the checkbox.
I get the below exception while trying to access the web service:
] FaultActor [null] Detail [<detail><bea_fault:stacktrace xmlns:bea_fault="http:
//www.bea.com/servers/wls70/webservice/fault/1.0.0">javax.net.ssl.SSLHandshakeEx
ception: [Security:090497]HANDSHAKE_FAILURE alert received from ************** Check both sides of the SSL configuration for mismatches in supported ciphers, supported protocol versions, trusted CAs, and hos
tname verification settings.
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireException(Unknow
n Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireAlertReceived(Un
known Source)
at com.certicom.tls.record.alert.AlertHandler.handle(Unknown Source)
at com.certicom.tls.record.alert.AlertHandler.handleAlertMessages(Unknow
n Source)
at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown S
ource)
at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Sou
rce)
at com.certicom.tls.record.ReadHandler.processRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknow
n Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Un
known Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.io.OutputSSLIOStreamWrapper.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65
)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at java.io.FilterOutputStream.flush(FilterOutputStream.java:123)
at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.j
ava:158)
at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.
java:363)
at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLC
onnection.java:37)
at weblogic.wsee.connection.transport.TransportUtil.getInputStream(Trans
portUtil.java:85)
at weblogic.wsee.connection.transport.http.HTTPClientTransport.receive(H
TTPClientTransport.java:271)
at weblogic.wsee.connection.soap.SoapConnection.receive(SoapConnection.j
ava:485)
at weblogic.wsee.ws.dispatch.client.ConnectionHandler.handleResponse(Con
nectionHandler.java:179)
at weblogic.wsee.handler.HandlerIterator.handleResponse(HandlerIterator.
java:287)
at weblogic.wsee.handler.HandlerIterator.handleResponse(HandlerIterator.
java:271)
at weblogic.wsee.ws.dispatch.client.ClientDispatcher.handleResponse(Clie
ntDispatcher.java:213)
at weblogic.wsee.ws.dispatch.client.ClientDispatcher.dispatch(ClientDisp
atcher.java:150)
at weblogic.wsee.ws.WsStub.invoke(WsStub.java:87)
at weblogic.wsee.jaxrpc.StubImpl._invoke(StubImpl.java:339)
at sips_cn_contract.PaymentService_Stub.processPaymentWebInit(Unknown So
urce)
at uk.gov.gateway.payments.SipsStartupController.handleRequest(SipsStart
upController.java:73)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:45)
at org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:485)
at org.springframework.web.servlet.FrameworkServlet.serviceWrapper(Frame
workServlet.java:342)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServl
et.java:318)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run
(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecuri
tyHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.jav
a:300)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.jav
a:183)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.doIt(WebAppServletContext.java:3686)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.run(WebAppServletContext.java:3650)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authenticate
dSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:
121)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppS
ervletContext.java:2268)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletC
ontext.java:2174)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.j
ava:1446)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
</bea_fault:stacktrace></detail>]; nested exception is:
However in firefox, i have added the certificate, and when i view the wsdl of the web service.It prompts me with the certificate and after i click ok, it renders the wsdl file for secure web service.
Anybody has idea what should I do to make the client working using Java?

I think that the real problem is that Weblogic is not using standard Sun HTTPS implementation provided by JDK, but rather uses its own, as apparent on this line:
at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:37)
The standard Sun implementation class is called javax.net.ssl.HttpsURLConnection.
As a result, the certificate policy is different inside Weblogic than in a standalone Java program. I just discovered this debugging a similar problem.
This page advises to use a Sun implementation instead of Weblogic:
http://webtech-kapil.blogspot.com/2010/06/javalangclasscastexception.html
They advice to start WL with the following flag:
-DUseSunHttpHandler=true
which will use standard Sun's implementation of SSL. However, I personally have not tried this yet.
Thanks,
Igor

You have likely not imported your certificate and key correctly. You can test your keystore by adding the following to a JUnit or something similar:
static {
System.setProperty("javax.net.ssl.keyStoreType", "pkcs12"); // or whatever
System.setProperty("javax.net.ssl.keyStore", "c:/folder/mycert.p12");
System.setProperty("javax.net.ssl.keyStorePassword", "mypassword");
System.setProperty("javax.net.debug", "ssl");
}
The javax.net.debug property set to ssl will print your certificate chain and all other SSL logging, which can be helpful. You'll want to add the certificate, etc. to your application container like you already have in production.
Try debugging with SSL and see what comes of that. More than likely you just need to configure weblogic correctly. Check to see if there are custom SSL endpoint configurations (i.e. when URI is /test/test use keyStore XYZ).