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.
Related
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
When I build with Export Signed Application Package in Eclipse, and I use the keystore I created the first time, it works.
Now I'm trying to use ANT to build the release APK (not debug), but, when I try to install the new APK on my real phone (not emulator), it trhows an existing package by the same name with a conflicting signature and I can't install.
Of course, this means that the signature is incorrect, or something simialar with the password.
This is the info I put in local.propeties
sdk.dir=D:\\Documents\\Applications\\Android SDK
key.store=D:\\Projects\\myProject\\signature_key
key.alias=two words
key.store.password=PasswordUsing$and%
key.alias.password=PasswordUsing$and%
Yes. The key.alias has 2 words (my mistake, but it's late now)
1) Is the format valid? Should I use quotes for the alias? Should I escape $ or % characters in the password?
2) What format should I use in local.properties to make the keystore/password be valid?
3) Is there something I'm missing?
This is perfectly normal behaviour if you have previously loaded the debug version of your app on your phone. The OS recognises the package as being already present and refuses to install the release version which has been signed with a different key.
You must uninstall the debug version first, then install the release one.
If you are wanting to deploy your app to the Play Store, you will need to create your own keystore (not re-use the debug keystore the tools use to build your app by default).
Export your project using the Export Wizard (right-click on the project, Android, Export...)
When going through this Wizard, there is a selection to generate a keystore, go through that, and save the resulting keystore files (somewhere safe, if you lose these, you will NEVER be able to deploy your app again to the Play Store).
I think you should skip ANT, and instead use the Wizard GUI.
Also - keep in mind if you deploy a debug build, you will need to uninstall it, before deploying your officially signed APK.
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
I've been trying to solve this problem for 3 days now and I simply can't find a solution.
So, I have downloaded the Jruby-complete-1.7.3 jar. After which, I have attempted to install the gem 'nokogiri' using the basic method:
java -jar jruby-complete-1.7.3 -S gem install nokogiri
In addition, I have a separate jar which was created using the Gem-In-A-Jar method. Note that this extra jar is only a result of trying to fix the problem below.
In both cases, when I test it out via the irb, it shows me the following:
require 'nokogiri'
=> true
Now, the problem arises when I try to use the jruby jar in an applet within my web application. To be specific, I'll mention that I can load the jar itself and interact with it from my applet, if I don't try to access any gem files (specifically nokogiri in this case). However, to make this happen, I am required to sign the jar.
If the jar is unsigned, it fails to work, as my Ruby instance fails to be created. When it is signed, it works fine.
The issue is that once the jar is signed, I attempt to call the same command I did before, and I get the following error:
require 'nokogiri'
LoadError: load error: nokogiri/nokogiri -- java.lang.RuntimeException:
(LoadError) class "nokogiri.EncodingHandler$INVOKDER$s$1$0$get"'s signer
information does not match signer information of other classes in the same
package.
I've been searching around quite a bit in regards to the cause and potential solutions to this error, but I am unable to figure out why the gem itself is causing it. While using the Gem-In-A-Jar method, I did use the same key to sign the gem_jar.
UPDATE: Turns out I was wrong. Each gem installed comes with its own jar file within the lib directory. These jars need to be signed with the same key. After doing so, the above issue was resolved. However, the one below remains.
Additionally, when I attempt to run it in my web-application, I get the following message:
classpath:/META-INF/jruby.home/lib/ruby/shared/rubygems.rb:396 warning:
can't canonicalize loaded names due to security restrictions; disabling
I assume this is the exception thrown when the error mentioned above occurs, but I can't say for sure.
I would sincerely appreciate anyone that can tell me what I've done wrong, or provide suggestions on how to fix it. If I have phrased the question wrong or have not provided enough information, do let me know.
Thanks
One solution is to use the SDK tools to strip the signatures from every Jar and digitally sign them all freshly.
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