2

I perused questions 13335419, 8748089, 4282405, and a few others. They indicated that the most likely cause is an embedded space. Another answer was a possible certificate problem. I used this tutorial as a guide.

I had a real certificate issued, not a self certificate, like in the question. I am also using the latest JDK, 1.8.0-60 (64-bit). I uninstalled all other JDKs.

Computer:

OS: Windows 7 64-bit
JDK Path: "C:\Program Files\Java\jdk1.8.0_60"

I tried several techniques to eliminate the space issue. From an admin command prompt:

  1. mklink /D C:\Documents\JDK "C:\Program Files\Java\jdk1.8.0_60"
  2. mklink /J C:\Documents\JDK1 "C:\Program Files\Java\jdk1.8.0_60"
  3. mkdir C:\Documents\JDK2 (followed by) copy "C:\Program Files\Java\jdk1.8.0_60" C:\Documents\JDK2

Command line:

jarsigner.exe –keypass <key password> -keystore C:\SoftDev\JavaWorkspaces\myproject\Versions\Current64\mykeystore.keystore –storepass <store password> -tsa http://timestamp.comodoca.com/rfc3161 -digestalg SHA2 C:\SoftDev\JavaWorkspaces\myproject\Versions\Current64\build\bin\myproject.jar 31843016-4ab3-11e5-9ba9-0015170bee96

I verified that my certificate uses algorithm SHA-2 (SHA-256) by viewing the certificate details. When I exported the certificate to a PFX file, I tried both permutations of checking box 1 (include all certificates in path) and box 3 (extended properties). I selected to export the private key initially.

I talked to the key issuer and they thought the alias should be 39 characters, however I rechecked the command to issue that and on repeated attempts, I got 37 characters.

keytool.exe -importkeystore -srckeystore "C:\Documents\Signing\mypfx.pfx" -srcstoretype pkcs12 -destkeystore C:\SoftDev\JavaWorkspaces\myproject\Versions\Current64\mykeystore.keystore -deststoretype JKS

I entered all executable files specified above using the various permutations mentioned (by itself in various directories enumerated above and with the full path specified. I tried specifying all file names with and without quotes.

KSoftware wrote me back:

I think the problem is that you're somehow specifying too many arguments to jarsigner.exe or one of the arguments is invalid somehow. My knowledge of Java and Jarsigner are limited but I do notice that the alias you're using seems to be of a different format than ones I've seen before (it appears to be too short by a few characters). Did you get that alias string from Step 4, and is that the entire string?

The arguments match the tutorial to the tee and make sense, when I did a -help on the commands. I cannot explain the alias length and format difference. I was told to use the "absolute latest version" of the JDK, which I am (1.8.0-60). I mentioned the version and they were okay with that. Steps 3 and 4 show the same alias. Maybe the person that wrote the tutorial at the time obtained the alias, le-e76649fec-3a2f-4cda-8a6e-441c224481b, in the from a version of the JDK that computes the alias differently and just the tutorial did not get updated. Comodo is a large company, so possibly the tutorial page slipped their radar, if the page originated from them or KSoftware did not go through the exercise recently. The steps seem sound, though, from what I gathered.

Update:

Based on my conversation with EJP, this question seems appropriate for the signer's chain problem.

Response from Comodo/KSoftware: @Omikron was right on the original problem, as mentioned in my comment. The mistake was doing a copy/paste from KSoftware.net's website.

There were 2 other problems. 2. The Oracle/Java tool chain does not support SHA-256 (SHA2) only SHA1.

  1. Comodo issues SHA-256 even if you indicate SHA-128 (SHA-1) on their order form. They stated to me that they will discontinue/stop issuing SHA-128.

The signer's chain error is caused by the SHA2. Here is their response to me:

I understand your hesitation but I assure you I've dealt with the 'chain not validated' problem a lot these days, and it's all related to the SHA-256 move. I can fix that, though, just follow those instructions I sent and we'll get you squared away... I'm still a bit baffled as to why Jarsigner isn't letting you pass that password in on the command line but that's more or less secondary at this point. We can still get you signing JAR files almost immediately with a re-issue from a different root.

FWIW, the move to SHA-256 and the new RSA roots needed has been a total mess with Java because they are extra, extra slow in adding trusted roots in. This move has been known for a few years now and the latest JDK release is the first that addressed it, and even it didn't address it very well. The best bet for right now is to use an older trusted root already recognized (which is still valid until 2020).

I was dealing with multiple issues to get my jar signed.

LAST UPDATE I received the new key from Comodo and that signed my jar with no issues.

Misunderstanding: Both my original and new certificates are SHA-256. The difference is the CA. The original one is "COMODO RSA Code Signing CA", whereas the new one is "COMODO SHA-256 Code Signing CA". The detail view for both show the exact same algorithm. The problem really is what KSOftware said. The RSA CA did not update their side yet.

Community
  • 1
  • 1
Sarah Weinberger
  • 15,041
  • 25
  • 83
  • 130
  • Try putting the alias in quotes. Try it without the tsa and sigalg arguments. Try to reduce it to a case that works. I agree that there is probably an embedded space: something before the alias is being seen as the alias. – user207421 Aug 25 '15 at 22:52
  • Progress: jarsigner.exe does NOT want me to specify the –storepass. I typed in something like (less the double quotes) –storepass mypassword. The tool does not seem to want, need, or like the -keypass argument. Quotes around the alias make no difference. I get asked for the password, and then I receive the warning: "jar signed. Warning: The signer's certificate is not validated." What does that mean? – Sarah Weinberger Aug 25 '15 at 23:11
  • It means you need to import the signer's certificate chain into your keystore file, with -trustcacerts. It would have been supplied along with the signed cert. You don't normally have passwords on individual keys, as for instance JSSE has no way of coping with them other than hand coding on your part. – user207421 Aug 25 '15 at 23:18
  • The problem is something else as, keytool -import -trustcacerts -alias root -file "path-to-crt.cer" -keystore "path-to-jks.jks", yields "Certificate already exists in keystore under alias <31843016-4ab3-11e5-9ba9-0015170bee96>", which makes sense as I already added the certificate to the keystore file. – Sarah Weinberger Aug 25 '15 at 23:35
  • Yes, that's your certificate, but I'm talking about the signer's chain. – user207421 Aug 25 '15 at 23:41
  • The original problem remains a mystery. I ran your exact command here with dummy passwords and I got the expected `jarsigner error: java.lang.RuntimeException: keystore load: C:\SoftDev\JavaWorks paces\myproject\Versions\Current64\mykeystore.keystore (The system cannot find the path specified)`. Rather than the syntax error you got. DId you maybe have spaces in your passwords? That's the only difference. – user207421 Aug 26 '15 at 00:11
  • Ksoftware asked me that too. I had no spaces, funny characters, or anything like that. Think like abcxyz as the password. Your command line fragment "\JavaWorks pacs\" seems to have an embedded space. For the record, having to do a mdlink or something like that on the default installation is nuts. Additionally, I had quite a few errors today. Each different error depended on what I did. I checked the jar file and my jar file was not signed, even though to the contrary. – Sarah Weinberger Aug 26 '15 at 03:14
  • Bizarre. The space in my command must be a cut and paste error cutting from the command window. – user207421 Aug 26 '15 at 03:37
  • I'd encourage you to use an IDE or Maven etc for tasks like this, rather than the command line. – user207421 Aug 26 '15 at 04:29

1 Answers1

5

The characters in the command line before "keypass" and "storepass" are both "en dashes" (ASCII code 0x96, see https://en.wikipedia.org/wiki/Dash). They should be "hyphen-minus" (ASCII code 0x2D) instead.

This can be checked by viewing the string in a hex editor (like HxD):

enter image description here

Because of the wrong character, "-keypass" is not recognized as a parameter by jarsigner and this messes up the whole command, which leads to strange error messages.

Similar problem: Certificate chain not found, but keystore contains private key

Community
  • 1
  • 1
Omikron
  • 4,072
  • 1
  • 27
  • 28
  • Addendum: 2 other problems. 1) SHA2 is not a supported hash algorithm. I need to use SHA1. 2) I received an email from KSoftware/Comodo, who stated that the "signer's certificate chain" error is the result of the Comodo issuing the key as SHA-256 rather than the required SHA-128. Oracle is slow to update their tool chain. Comodo had to reissue the code. – Sarah Weinberger Aug 26 '15 at 15:45
  • @SarahWeinberger Regarding point 1): `-digestalg SHA256` would have been correct, I didn't see that. SHA256 is the default since Java7, btw. – Omikron Aug 26 '15 at 16:02
  • That was a very good catch and thought to paste the code into a text editor. FWIW, I copy and pasted the code for Step 5 at http://certhelp.ksoftware.net/support/solutions/articles/17164-how-do-i-sign-and-timestamp-a-java-jar-file- and saw the problem. It seems that the original code saw Microsoft Word at some point, as Word does this sort of thing. – Sarah Weinberger Aug 26 '15 at 16:03
  • @OImikron I just tried " -digestalg SHA256" and saw "jarsigner error: java.security.NoSuchAlgorithmException: SHA256 MessageDigest not available". Taking the digestalg argument out still yields the warning (error, really): "The signer's certificate chain is not validated." – Sarah Weinberger Aug 26 '15 at 16:07
  • @SarahWeinberger Oops, `-digestalg SHA-256` – Omikron Aug 26 '15 at 16:12
  • @SarahWeinberger I just wanted to say that SHA2 algorithms _are_ supported by jarsigner/keytool. `-digestalg` and even `-sigalg` are not related to the chain issue. – Omikron Aug 26 '15 at 16:30
  • I just updated my question at the end, see "Last Update". My original and now new certificates are both SHA-256 based. The difference is the CA. I just did not understand KSoftware's comment to me fully until now. Their default CA, "COMODO RSA Code Signing CA" has a problem with Java. Their older CA works. I was also misunderstanding that I would see a Digital Signature in the properties dialog of file explorer. One has to use jarsigner to view the signature. – Sarah Weinberger Aug 26 '15 at 17:04
  • Here is the response from KSoftware regarding the two CAs: "The difference between the root certificates is platform recognition. Sun added the COMODO SHA-256 Code Signing CA root in to their trusted list late last year but not the other for some reason. They are the same as far as level of authority goes so you can still use that certificate for Authenticode signing too (for Windows EXE files and such)." Additionally, KSoftware updated the tutorial page, so copy and paste now works. – Sarah Weinberger Aug 26 '15 at 17:30