I'm using Netty for asynchronous http(s) requests. When the url for the request is https I'm adding this to the pipeline:
SSLEngine engine = SecureChatSslContextFactory.getClientContext().createSSLEngine();
engine.setUseClientMode(true);
pipeline.addLast("ssl", new SslHandler(engine));
This works well, I get the response back and everything, but a warning is being written to the output saying: UNKNOWN SERVER CERTIFICATE, for example if I issue a request for: https://www.google.com this is what I get:
UNKNOWN SERVER CERTIFICATE: CN=www.google.com, O=Google Inc, L=Mountain View, ST=California, C=US
Since everything is still working it's not that much of an issue for me, but there are two things I would like to know:
Why do I get that warning? googles' certificate is a "well known" one, the browsers don't seem to warn about it. Should I somehow tell the ssl engine where to look for the certificates?
Can I somehow catch this warning at runtime instead of having this message printed out?
Thanks.
Check to make sure that the "trust store" is correctly identified to Netty when you do this, you may have to look at adding ${JAVA_HOME}/jre/lib/security/cacerts as a trusted store.
If that's not configured you probably won't be able to connect over SSL
Dave,
Take a look at the code sample in this thread: Set up Netty with 2-way SSL Handsake (client and server certificate)
I think that will help you with your keystore and truststore setup.
Related
I have an SSL client certificate. It was working with my app up until one of the Java updates happened at some point in the recent past (maybe as far back as a year). It works with web browsers. It works with curl.
For example, I can do this and it is fine:
curl --cert example.pem https://example.net
Now I cannot get this cert to work with Java. I've gone as far as trying a very minimal app, like SSLPoke from https://gist.github.com/4ndrej/4547029
Putting the cert into the client certs from ControlPanel doesn't do it.
Importing the .pem into a keystore and then pointing at that keystore with -Djavax.net.ssl.trustStore or .keystore doesn't do it.
All I get out of Java is:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
So I can't figure out what is wrong - the way I'm invoking Java? The place I'm putting the certificate? The way I've imported the certificate?
The debug output using -Djava.security.debug=all does not show it using the trustStore/keyStore I specify. It doesn't even show anything about the URL I'm trying to reach.
I'm out of ideas.
Your server is likely using an outdated SSL protocol, that Java is no longer allowing, by default, for security reasons.
Try running Java with this option (e.g. needed for older SQL Server instances):
-Djsse.enableCBCProtection=false
If that doesn't work, maybe the server is using SSLv3, so see this SO question for How to enable SSL 3 in Java.
If any of those work, they are workarounds need to downgrade the SSL security, so you are strongly encouraged to upgrade the server instead, and remove these workarounds again.
I created a java agent that needs to connect to an API internaly. The protocol used is HTTPS. When the agent tries to connect to the API it throws the following error:
com.ibm.jsse2.util: no trusted certificate found. This all is running on a Domino 9.0.1fp3 server. The SSL certificate is a self signed certificate with a custom certificate authority.
I tried the following solution http://www-01.ibm.com/support/docview.wss?uid=swg21588966 but to no success. Even when we restarted the server it does not correctly pick up the certificate chain. As a last resort we created a little java class that ignores SSL certificates that are self signed. But ofcourse this is not a great solution.
I was wondering if someone also encountered this issue and knows how to solve it.
Apparently IBM forgot to mention that you actually need to restart the whole server for this to work....
I have a certificate which i need to pass along with the SOAP Request in JMeter.
I have edited the system.properites file to add
javax.net.ssl.keyStore= path to keystore file
javax.net.ssl.keyStorePassword=password
I am still getting the error You need valid client certificate from DHW to access page.
Am I missing somethig here?
The same request is working well from SOAP_UI.
There is a lot that can be going wrong here.
Here is my guess though...
The server is most likely setup for mutual authentication. You can test this by running your java client with the following system property: -Djavax.net.debug=ssl
You should see the ssl handshake and see if the server is requesting a client certificate or not. The messaging will be VERY verbose and you will have to diligently look though the log output to see what is actually occurring.
Hopefully, in the output you will see a list of Certificate Authorities (CAs) that the server trusts. Your client's certificate MUST be signed by one of these CAs. If not, the client won't even attempt to send its client certificate.
If you have access to the server, you can create your own CA and then sign the clients certificate with that new CA and that will work. I actually just did that yesterday. :D
The issue is resolved. I was giving only single backspace instead of two backspaces as per java conventions. It works fine with this minor modification.
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 ?
I am using https to connect to an https server.
Specifically I am using apache httpclient and I configure the ssl context to use my keystore and truststore.
The https server I am using is IIS7 and is configured to require client authentication.
I think I have set it up properly.
Anyway, if I configure the httpClent's ssl context with a keystore (i.e. with client certificates) valid for IIS then there is no problem connecting.
Now my problem is the following:
If I do not configure the ssl context with any client certificate to send to IIS, there is no connection with the server. What makes me think though, is the fact that I was expecting to see some java exception in the code as a result of a hanshake failure alert.
Monitoring what is happening with wireshark, I could not see a certificate request from IIS to my application, but I noticed that after ServerHelloDone everything was encrypted.
I did not expect that. I think the handshake is usually in cleartext.
I used private key to decrypt traces and i saw a certificate request from IIS but after many starting and opening of new connections.
My app send back as a response a certificate of length 0 and IIS replies with a TLSv1 Finished.
After that the packets stop (i.e. seems that the communication ends).
I was expecting a handshake alert.
My question is, is this how it is supposed to work or at least how IIS works?
Or if I do not see the alert something is wrong with my use case?
Thanks
It sounds like IIS is only requiring client certificates for certain URLs (ie, for example.com/foo, but not example.com/bar).
In the initial handshake, it does not know which url you are requesting, so it does not require a certificate. When it sees that you are requesting a restricted resource (/foo), it then rehandshakes, requiring a certificate.
However, I would still expect a handshake_failure to occur.
As I was saying in an answer to this question, as far as I remember, IIS uses re-negotiation to get the client certificate. You should be able to change this behaviour using netsh and clientcertnegotiate=enable (depending on the version of IIS you're using).
You might also be interest in this similar question.
Failing to supply a certificate in response to a CertificateRequest isn't an SSL protocol error, so there is no handshake_error. 'Requiring' instead of just 'needing' client certificates is added-in by SSL libraries, and all they can do if you don't send one is just close the connection.