java code-signing keystore keytool jarsigner

jarsigner "Only one alias can be specified" 3

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:

mklink /D C:\Documents\JDK "C:\Program Files\Java\jdk1.8.0_60"
mklink /J C:\Documents\JDK1 "C:\Program Files\Java\jdk1.8.0_60"
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.

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.

Solution

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):

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.