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....
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 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.
After a server change, I get nasty SSL warning in browsers (tested FF & Chrome), when loading an applet, used in an JavaEE Application (Serlvet API 3)
The warning says: "Certificate is not valid, and cannot used to identify the website"
The more detailed warning says: "The certificate authority, who provided the certificate, is not trusted." The messages are translated into english, so please excuse slight differences there. After this message, I get the message of Java, which shows that the Applet is ordinary signed (the dialog with the blue sign). So the Applet is working, only the warning message annoys.
Before I moved to another server, everything was fine and worked. No security warnings or anything else. The Applet is signed, by a certificate, which I requested from an CA. (rapidssl)
The old server environment was just a common web space, offered by 3rd party hoster. Now I moved to my own server, which utilizes XEN for hosting VMs. On one of that internal vm's, our webserver is deployed. According to that, I defined firewall rules to route traffic http/https to the vms.
Also the domain was ported, was purchased at old hoster, and the ip of new server is bound to domain.
I use Tomcat 7 as Application Server on an debian based OS.
In old environment, I could use the specified url in CN of my wildcard cert.(e.g. *.domain.com)
In new environment the basic message says: *.domain.com:port is not a trusted site.
I thought actually, that SSL Certs are independent of the used port. I've read that, on some research too. I also searched here in many threads, but the supposed answers didnt work for me.
The certificate and root cert. are imported to Java's own keystore cacerts. In Tomcat 7, I use the JSSE Implementation for SSL, with properly setup keystore files.
I've tried already this, but as im not that experienced with SSL/TLS Technology, the tried solutions maybe even wont solve my problem:
Disabling SNI in Tomcat 7 (dont work)
Adding Host aliases in server.xml (dont work)
Can anyone clarify, what the actual problem is, or has experienced the same issue ?
#edit: The are no error stacktraces in any logs, which I could provide here, also no exceptions gets thrown.
It came clear, thanks to Khanna111 Gaurav Khanna and jwv, that the certificate chain wasnt setup properly. I thought, if there were any problems with the certificate chain, that the browser will notify me about it. It isn't like that.
As we migrated from old hoster to new server, they provided only the certificates, but without the private key.
As im not that much experinced with SSL, I thought that importing the intermediary certs and the acquired cert is enough.. It is not :)
After stumbling on
intermediate-ca-certificate-in-java (link in comment), I've read this, which solved my problem: why doesn't java send the client certificate during SSL handshake? & external website:Import private key and certificate into Java Key Store (JKS)
I had certkey.key,publiccert.crt, intermediate_primary.cer and secondary_primary.cer Files.
The first step was, to convert the .key and .crt file to DER format, as mentioned in last link
via OpenSSL due to keytool's inability to import a key in an existing keystore
After converting to DER Format, I used the Tool ImportKey and created a new keystore with key/cert contained.
The second step was following the instructions of second link (Bruno's Answer), so it was copy&paste the certificate contents, into a single file. After importing the bundle of certificates into keystore, everything was fine.
I hope this can help anyone else, which is also not that familiar with SSL.
p.s. due to my lack of rep, i cannot mention all sites, I've used.. I'll provide them in comments
I'm trying to download a simple page from an SSL secured webpage. I'm using HtmlUnit for that task (which wraps around HttpClient).
The webpage I'm trying to download has a proper certificate signed by Verisign and Verisign certificate is present in cacerts file (it was there in first place but I even reimported whole certiciate chain there).
My application runs perfectly as stand-alone application using the same JVM that is used by Glassfish. However if I deploy it to glassfish I'm getting a classic certificate problem exception:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated,
com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:108)
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:597)
com.gargoylesoftware.htmlunit.HttpWebConnection.getResponse(HttpWebConnection.java:133)
com.gargoylesoftware.htmlunit.WebClient.loadWebResponseFromWebConnection(WebClient.java:1405)
com.gargoylesoftware.htmlunit.WebClient.loadWebResponse(WebClient.java:1324)
com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:303)
com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:385)
I've already tried disabling security manager in glassfish and that did not help.
What can be the cause of this weird behavior?
Thanks in advance.
I thought GlassFish used it's own magical keystore:
http://metro.java.net/guide/Configuring_Keystores_and_Truststores.html
Good luck!
If this is test or temporary code and you don't care to validate the certificate, try accepting all certs and host names. Using that SSLUtilities class:
SSLUtilities.trustAllHostnames();
SSLUtilities.trustAllHttpsCertificates();
You can import certificate chain into a truststore and set the following VM arguments:
-Djavax.net.ssl.trustStore="<path to truststore file>"
-Djavax.net.ssl.trustStorePassword="<passphrase for truststore>"
or override the truststore at runtime like:
System.setproperty("javax.net.ssl.trustStore","<path to truststore file>")
System.setproperty("javax.net.ssl.trustStorePassword","<passphrase for truststore>")
Keep in mind that both options will override default JVM truststore. So if you are hitting different sites with different certs, you may want to import all of them into one truststore.
I have a web service deployed on tomcat hosted on a remote server.
I have set it up such that it can be accessed only via HTTPS.
For this, I generated a Certificate Signing Request (CSR) and used it to get a temporary certificate from VeriSign.
My web service client is on my local machine. If I try to access the service it will throw a javax.net.ssl.SSLHandshakeException:unable to find valid certification path to requested target
If I install the certificate in to local Java's keystore, the issue will be resolved.
My question is if I install a valid SSL certificate from a CA in to my tomcat server,
will I get this client-side error even if I do not import the certificate to local key store?
No, you won't. JVM ships with root ca's by default. The older JVMs (1.5.xx version) don't have all root CA's, but if you have a certificate from Verisign it shouldn't be a problem.
Java has many root CA certificates already installed. As long as you use one of those popular CAs to get your certificate, the client will not receive an error.
While you should be fine, its a good idea to include not only the actual certificate for your site, but also the entire chain leading up to the root certificate. (Sometimes you'll bump into clients which are missing some intermediate certificates and this can cause annoying debugging problems.)