We have a java webstart application which is hosted a web server. The signer of the SSL certificate in the web server is not in the cacerts of the JRE, by default. Thus when we run
javaws https://blablah/our.jnlp
we get a Security Warning dialog saying the connection the website is untrusted. Is it possible to pass a custom truststore that contains the singer certificate to the javaws process? to avoid the warning?
I was hoping following would work
javaws -J-Djavax.net.ssl.trustStore=<path_to_custom_trusstore> https://blablah/our.jnlp
where custom_trusstore contains the signer certificate.
This does not seem to work. Warning still shows.
I know alternatively we can add the signer certificate from the Java Control Panel, but is there any other way?
have you tried to add the password?
-Djavax.net.ssl.trustStorePassword=storePassword
Related
I am trying to run git clone in Spring Tool Suite (eclipse) from local gitlab server.
I'm using HTTPS clone url and the server certificate is signed by our organization CA.
I'm getting the error: unable to find valid certification path to requested target.
The root certificate of the organization is in the Windows trusted certificates store.
I tried placing the git configuration in the path %USERPROFILE%\.gitconfig with the content:
[http]
sslBackend = schannel
I can see in STS that the configuration was loaded in the eclipse preferences, but the error is still there.
Any idea how to get git commands in STS / Eclipse to trust the Windows certificate store?
Thanks,
Eyal
found it...
I had to add to the java options in the SpringToolSuite4.ini
javax.net.ssl.trustStore=NUL
javax.net.ssl.trustStoreType=Windows-ROOT
Then java trusted the Windows keystore
I have installed the Jenkins plugin for the Play! framework: https://wiki.jenkins-ci.org/display/JENKINS/play-plugin
However, I run into a problem configuring that plugin. The Jenkins server doesn't have Play installed, so I tried to configure the auto-install, using the "Install automatically" option. Unfortunately, when I pass the URL to the Typesafe Activator's ZIP archive, I get a handshake failure.
The Jenkins server is a part of the Cloudbees cloud.
Any ideas on what is going wrong and how to deal with it?
EDIT: Changing "https" to "http" resolves the handshake problem. However, Play does not get installed on the Jenkins server. The build does not find the "activator" executable. I suspect this may be an issue with the Play plugin for Jenkins.
it seems your java cacerts is not having correct certificate. you may try following steps.
Step 1 : Get root certificate of https://www.google.com
Open https://www.google.com in a chrome browser.
Select Inspect from context menu(right clicking on page) and navigate to security tab
Click on view certificates
Click on top most certificate on hierarchy and confirm it is tailed with Root CA phrase.
drag and drop that image which you saw written certificate on desktop.
Thats it! you got your root certificate!
Step 2 : install certificate to your java cacerts
please verify you have system variable JAVA_HOME declared and you will perform these steps on that jre cacerts only!
Navigate to cacerts by JAVA_HOME/jre/lib/security/cacerts
Download and install keytool explorer it is available for all platforms
open cacerts in that tool and import cetificate by "import trusted certificate" button.
Save your changes (you may come across issue if it is mac and you do not have write access!)
Step 3 : Restart jenkins
You should not get ssl handshake problem now onwards.
Running Eclipse 3.6 and trying to get version 3.2.4 of the GWT plugin. I add the source and it results in the following:
Unable to read repository at https://commondatastorage.googleapis.com/eclipse_toolreleases/products/gpe/release/3.2.4/3.6/content.xml.
Unable to read repository at https://commondatastorage.googleapis.com/eclipse_toolreleases/products/gpe/release/3.2.4/3.6/content.xml.
com.ibm.jsse2.util.j: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
java.security.cert.CertPathValidatorException: The certificate issued by OU=Equifax Secure Certificate Authority, O=Equifax, C=US is not trusted; internal cause is:
java.security.cert.CertPathValidatorException: Certificate chaining error
I have the correct path, my local time on my machine is accurate/correct (I had read some about some odd timestamp issues with certs?), and I can't seem to find any information about this. I tried installing locally, and there are missing dependencies when I use a local archive. I am curious though, why is it trying to hit content.xml? There is no such file in the downloadable repo, and when I try to hit that URI, I get the following:
<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message></Error>
It's because the repository does not have a valid, i.e. trusted, certificate according to our SSL. You need to manually add the certificate as trusted, and then install the plugin.
On certain sites the certificate chain can not be built up to the trusted root certificate because this trusted root cert is not known to Windows. But if we visit such site using IE or Chrome, Windows automatically downloads (verified) the trusted root somewhere and silently installs it to Trusted Certificate Authorities storage. After this we can build the certificate chain up to the newly installed root. If we manually remove newly downloaded trusted root certificate from Windows storage, the chain can't be built again.
I know about Authority Information Access extension. The problem is that the topmost available certificate in the chain (the child of missing trusted root) does NOT have such extension included. And even if it had, Windows would not automatically trust the downloaded certificate.
So there must be some other source of knowledge about trusted roots. The question is - how can we use that source ourselves. The topmost available certificate is available here if anyone is interested in inspecting it.
This link http://support.microsoft.com/kb/931125 explains how Windows updates root certificates silently in Vista and 7.
I also stumbled on this multiple times. It can be reproduced easily using windows sandbox. If you use curl or similar certificates can not be verified. Only if you call WinHttpOpen the root certificate (if trusted) will be added to the root certificate store.
See this post
Certificates contain an extension called "Authority Information Access" which contains the details of the issuing CA. An example of the certificate used for "https://gooogle.com" is shown below. The browser reads this value, downloads the certificate from the URL provided and repeats the process up the certificate chain.
My test Tomcat 6 server has a self signed certificate. The manager webapp is accessible only via SSL, with this self signe certificate. When I try to deploy with the cargo-maven2-plugin, I get the error :
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I could probably add the certificate to the default Java keystore, but I would like to keep deployment as portable as possible and not require that everybody who needs to deploy the app to install the certificate. I would like to deploy the app by just having a checkout of the project, configuring the password to the app server and running Maven.
I could not find in the cargo documentation a way to ignore invalid certificates.
Can you point me in the right direction ?
I'm fairly ignorant on cargo specifically, but I've used this code to allow bad certs without errors in Java before, and it should work for you. Note that it's super insecure, but then again if you want to ignore invalid certs then pretty much any implementation is going to be super insecure.
http://ctasada.blogspot.com/2010/11/httpclient-use-self-signed-certificates.html