I am trying to create a Confluence plugin. I have been following theses instructions.
However when I run the atlas-create-confluence-plugin command maven throws SSL errors trying to get resource from https://m2proxy.atlassian.com/repository/public/.
alt text http://img46.imageshack.us/img46/6281/mavenssl.jpg
Do I need to change a setting in my configuration?
System setup: Windows Vista, with Apache Maven 2.1.0 (r755702; 2009-03-18 19:10:27+0000)
Accessing a repository over SSL is not really a Maven issue (which uses HttpClient under the hood and at the end classes from the java.net package), this is a pure Java issue: the certificate of the remote repository has to be trusted i.e. the CA root certificate for this certificate has to be in the cacerts file bundled in the JRE or you need to establish a chain of trust manually.
In the particular case of https://m2proxy.atlassian.com/, the certificate has been issued by DigiCert CA.
The odd part is that recent JDKs (Java 5u15 or later or Java 6u5 or later, see Bug ID:6647251) have a CA root certificate for DigiCert. So, with a recent JDK, things should just work (unless you have a proxy doing some black magic like in this issue).
If you are using an older JDK and can't upgrade, export the certificate from your browser, use keytool to add it to a trust store and setup Java to use this trust store (using the javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword system properties). See the Maven mini guide and/or this blog post for more details on how to do this.
But the easiest way would be to use a recent JDK.
OK this looks like I got the question wrong.
For some reason maven was not downloading the maven-confluence-plugin-3.0.5.jar file. I had to manually download this file from the URL and add it in the correct location .m2 directory.
After that the whole process worked fine.
In most cases, Pascal's answer is the way to go. However, if you're building Maven itself, it doesn't work (as of Maven 3.2.3, at least), because ant fails to pass the necessary javax.net properties when it calls the MavenCli class to let Maven build the remainder of Maven.
The solution to this problem is to modify the build.xml file in the root of the maven source directory, and add these lines to the maven-compile target:
<arg value="-Djavax.net.ssl.trustStore=/path/to/trustStore" />
<arg value="-Djavax.net.ssl.trustStorePassword=TrustStorePassword" />
in windows doing the following helped with command line execution
SET MAVEN_OPTS=-Djavax.net.ssl.trustStore="C:\Program Files\Java\jdk1.8.0_201
jre\lib\security\cacerts"
the error I got was as follows
Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
(one could also adjust mvn.cmd...)
hope this hepls
Related
I am unable to create Maven projects and none of the dependencies are getting downloaded. Whenever I am creating new project, I am receiving below error screenshot:
Eclipse Error
Also, none of the maven commands are working, like mvn clean. Getting below error:
Maven Error
Unable to find valid certification path to requested target
This is usually a sign that someone or something is intercepting HTTPS traffic, and is messing with the certification path.
I have this problem with my company's network because our Cyber team use a magic HTTPS sniffing tool that replaces the certificate of the site you're trying to access with the company's certificate so that traffic can be monitored. (Forgive my noddy explanation)
If you're not behind a corporate proxy or a proxy owned by someone who you know manages your internet connection, then you may have security issues that are way beyond the scope of what I'm explaining here!
Anyway, the solution for me was to go to the URL maven is trying to download from (in your case, https://repo.spring.io ) and download the certificate from your web browser (this varies by browser type, but you can google 'how to download certificate from mybrowser.
You can then add that certificate to your local JDK certificate store. Here are the Oracle instructions for installing a root CA in your truststore: https://docs.oracle.com/cd/E19906-01/820-4916/geygn/index.html
jarsigner is not working in java , therefor the build fails
[signjar] jarsigner: unable to sign jar: no response from the Timestamping Authority. When connecting from behind a firewall an HTTP or HTTPS proxy may need to be specified. Supply the following options to jarsigner:
[signjar] -J-Dhttp.proxyHost=<hostname>
[signjar] -J-Dhttp.proxyPort=<portnumber>
[signjar] or
[signjar] -J-Dhttps.proxyHost=<hostname>
[signjar] -J-Dhttps.proxyPort=<portnumber>
There is no error in the project build path. All the dependencies are imported in the build path.
Here's the problem as I understand it:
Your are attempting to build a project with an Ant "build.xml" file.
You are running the build from within Eclipse.
You are running Eclipse in a VM that has no internet access.
The build fails during JAR signing when jarsigner attempts to talk to a time stamp authority (TSA). Internet access is required to talk to a TSA.
Also I am not sure why is this error encountered.
It is because you are trying to use signature timestamps, and your build system doen't have direct internet access, and you haven't provided a http or https proxy in the appropriate fashion for jarsigner to use.
There are a couple of ways to solve this. (The following is based on the documentation. I haven't tested this.)
If you have an internet proxy available:
The simplest way is to edit the "signjar" task in your "build.xml" and add "tsaproxyhost" and "tsaproxyport" attributes as described in the Ant manual.
If you are building on the command line1, you should just be able to follow Ant instructions for Proxy Configuration. (There are two approaches ...)
If you are running the build using Eclipse, then you could find the Eclipse "runner" configuration that is used to run Ant, and then add command line as per the previous bullet.
(I think that the error message that talks about -J-D... options is coming from the jarsigner utility itself. That advice is only directly applicable if you are running jarsigner directly from the command line. That is, of course, another option.)
If you don't have a working proxy (or you are just fed up) the other alternative is to edit the "signjar" task to disable signing. Removing the "tsaurl" and "tsacert" attributes should do it.
Disabling timestamps will give you a signed JAR without signature timestamps. The significance is explained by the Oracle Signature Timestamp Support documentation:
"Prior to J2SE 5.0, the signature generated by jarsigner contained no information about w hen the signature was generated. With no other information available, systems/deployers (including users of the Java Plug-in) often based their validity assessment of a signed JAR file on the validity of the signing certificate. When the signing certificate expires, systems/deployers conclude that the signature, and hence, the JAR file, has expired. Because signing certificates typically expire annually, this caused customers significant problems by forcing them to re-sign deployed JAR files annually.
Starting in J2SE 5.0, jarsigner can generate signatures that include a timestamp, thus enabling systems/deployer (including Java Plug-in) to check whether the JAR file was signed while the signing certificate was still valid. In addition, APIs were added in J2SE 5.0 to allow applications to obtain the timestamp information."
1 - I recommend you download and install a free-standing Ant, so that you can run builds from command line.
I am using gradle to build an Android project. When I try to run the build task, I get the following exception:
Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Digging a little bit into it, I discovered that the problem is that I can't authenticate the site because I don't have the certificate in my cacerts file.
For some reason, the gradle wrapper can't GET this particular xml file. However, when I run:
curl https://jitpack.io/com/github/afollestad/material-dialogs/core/0.8.5.7/core-0.8.5.7.pom
I get a response with the XML content. If I open google chrome, I can also access the content and I can even check out the certificate.
I downloaded the certificate from jitpack.io and added to my cacerts file using this tutorial:
http://nerd-ability.blogspot.com.es/2013/01/tech-how-to-fix-sslpeerunverifiedexcept.html
For some reason, it looks like my JVM is not recognizing it.
For testing purposes, I even used the groovy task described in the tutorial to retrieve the xml, but it didn't work, I get the same error.
Can you help me to debug this?
Thank you.
PS: I checked the expiration date of the certificate it is still valid (I downloaded it today)
A little worried your being MITM'd but if you don't care then you could just download using http instead of https
$ curl http://jitpack.io/com/github/afollestad/material-dialogs/core/0.8.5.7/core-0.8.5.7.pom
I am using the libgdx project creator (gdx-setup.jar) to setup a new project. However, I am using a proxy connection on my Windows machine to access the internet and the gdx-setup.jar isn't able to detect the settings, thus I cannot download the required jar files and generate any project. How and where do I change the java proxy settings so that I am able to achieve this?
PS: I have already tried to edit the settings under Control Panel->Java->Network Settings but to no avail.
From Gradle's manual: 12.3. Accessing the web via a proxy
You may need to create a $HOME/.gradle/gradle.properties file. For example:
systemProp.http.proxyHost=10.0.0.1
systemProp.http.proxyPort=8080
systemProp.http.proxyUser=
systemProp.http.proxyPassword=
systemProp.http.nonProxyHosts=*.some.domain.com|localhost
IMPORTANT: There are separate settings for HTTPS.
systemProp.https.proxyHost=www.somehost.org
systemProp.https.proxyPort=8080
systemProp.https.proxyUser=userid
systemProp.https.proxyPassword=password
systemProp.https.nonProxyHosts=*.nonproxyrepos.com|localhost
Then, just run setup like this:
java -Dhttp.proxyHost=10.0.0.1 -Dhttp.proxyPort=8080 -Dhttps.proxyHost=10.0.0.1 -Dhttps.proxyPort=8080 -jar gdx-setup.jar
This works for me, behind a HTTP Proxy. Change it with your proxy settings.
Later, import your projects into Eclipse. And make sure your Eclipse Network Proxy is OK too.
Here is a working solution:
http://badlogicgames.com/forum/viewtopic.php?t=16414&p=70348
For windows 7, gradle.properties is under C:\Users\USER_NAME.gradle\ (or create one if not exist)
Steps:
1. prepare gradle.properties file with following content
org.gradle.daemon=true
org.gradle.jvmargs=-Xms128m -Xmx1500m
org.gradle.configureondemand=true
systemProp.http.proxyHost=
systemProp.http.proxyPort=8080
systemProp.https.proxyHost=
systemProp.https.proxyPort=8080
run the jar through the same proxy
java -Dhttp.proxyHost=**** -Dhttp.proxyPort=** -Dhttp.proxyUser=******** -Dhttp.proxyPassword=**** -jar gdx-setup.jar
If you run gdx-setup.jar from the command line, you should be able to tell the JVM to use the proxy settings using http.proxyHost and http.proxyPort.
See: How do I set the proxy to be used by the JVM for more information.
The command line would be something similar to:
java -Dhttp.proxyHost=10.0.0.1 -Dhttp.proxyPort=8080 -jar gdx-setup.jar
I was able to workaround this problem using Eclipse with proxy configured in
Window -> Preferences -> Network Connections
I think it should be possible also in other IDEs or even Gradle (if you install it manually), provided that they have properly configured proxy.
This is because the Project Creator creates the whole directory structure, classes, etc., it fails later, when trying to download Gradle.
What I did after it failed is I went to Eclipse, I chose 'Import as Gradle project' and then clicked the Build Project button.
This downloaded Gradle and all the needed jars.
Where can I find a reference list/chart that shows the included root ssl certs included in each version Java VM/JDK?. Meaning-- for every version of the sdk/jre.
This info is generally in the \java ver\lib\security directory. But I am looking for a chart/list that shows all version of Java.
I am NOT trying to find out how to know the certs for a VM that I have. Meaning, shows the certs for a specific VM I have installed locally. What I am looking for is an online reference that shows what root ssl certs Sun/Oracle 'baked in' to the Java VM for every version of Java. This question has nothing to do with adding certs to a keystore, or web browsers, or how to obtain a certificate from a third party.
As a second related question (kinda); does anyone have the same info above but for the 'baked in' root certs that are for all popular browsers and versions?
Cert vendors usually scatter this info on their sites. But what I need is a simple chart that you can see: for a browser/version-- what roots certs are baked in.
Cheers!
Will--
11/8/2013 11am update:
I did more research on this and found no place online that has this info. So I started to think about it from the perspective of how it might be possible to get this info yourself in a non-painful way. Here's is where i ended up:
1) Get access to all versions of the cacerts file from some kind of sun/ora source code repository. Then affiliate those file versions somehow with what jdk version they would have shipped with. Then programatically use the keytool to obtain all the certs for each version of the file. Voila... the data I seek.
But-- I was unable to find any repository git/subversion/cvs/blah that has the cacerts file revision history all the way back.
2) Use the newest java 8 bundled cert file as a starting point, and then use the date each cert was added (keytool provides that) as a way to figure out what would have been there at any moment in time in the past (i.e.: older java versions).
But-- This wont work. Because I found out sometimes certs are removed. That is, some certs that would have been in the 1.6_x jdk don't get 're-upped' and included in later versions of the cert file. I actually proved this by diffing a 1.5_X certs file to a 1.6_x cert file. Technically I didn't diff the two files, I actually diffed that certs that were in the files.
3) Download all vers sdk (the whole darned thing) and essentially do the same thing as step 1 above. This might work, but is way painful. I didn't attempt this.
So... no love so far