jarsigner "Only one alias can be specified" 3
jarsigner "Only one alias can be specified" 3
我仔细阅读了问题 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 作为指南。
我签发的是真实证书，而不是问题中的自我证书。我也在使用最新的 JDK，1.8.0-60（64 位）。我卸载了所有其他 JDKs.
计算机：
OS: Windows 7 64-bit
JDK Path: "C:\Program Files\Java\jdk1.8.0_60"
我尝试了几种技术来消除 space 问题。从管理员命令提示符：
- 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（后面跟着）copy "C:\Program
Files\Java\jdk1.8.0_60" C:\Documents\JDK2
命令行：
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
我通过查看证书详细信息验证了我的证书使用算法 SHA-2 (SHA-256)。当我将证书导出到 PFX 文件时，我尝试了检查框 1（包括路径中的所有证书）和框 3（扩展属性）的两种排列。我最初选择导出私钥。
我和密钥发行者谈过，他们认为别名应该是 39 个字符，但是我重新检查了发出该命令的命令，在反复尝试后，我得到了 37 个字符。
keytool.exe -importkeystore -srckeystore "C:\Documents\Signing\mypfx.pfx" -srcstoretype pkcs12 -destkeystore C:\SoftDev\JavaWorkspaces\myproject\Versions\Current64\mykeystore.keystore -deststoretype JKS
我使用上面提到的各种排列输入了上面指定的所有可执行文件（单独在上面列举的各种目录中并指定了完整路径。我尝试指定所有带引号和不带引号的文件名。
KSoftware 给我回信：
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?
当我对命令执行 -help 时，参数与教程相匹配并且有意义。
我无法解释别名长度和格式差异。
我被告知使用 JDK 的 "absolute latest version"，我是 (1.8.0-60)。我提到了版本，他们对此表示满意。
第 3 步和第 4 步显示相同的别名。也许当时编写教程的人获得了别名，le-e76649fec-3a2f-4cda-8a6e-441c224481b，在计算别名的 JDK 版本中，只是教程没有得到更新。 Comodo 是一家大公司，因此如果该页面源自他们或 KSoftware 最近没有经过练习，那么教程页面可能会被他们忽视。不过，从我收集到的信息来看，这些步骤似乎很合理。
更新:
根据我与 EJP 的对话，this question 似乎适用于签名者链问题。
来自Comodo/KSoftware的回应：
正如我在评论中提到的，@Omikron 在最初的问题上是正确的。错误是从 KSoftware.net 的网站上执行 copy/paste。
还有 2 个其他问题。
2. Oracle/Java 工具链不支持 SHA-256 (SHA2) only SHA1.
- Comodo 会发布 SHA-256，即使您在他们的订单上指定了 SHA-128 (SHA-1)。他们对我说他们将 discontinue/stop 发布 SHA-128。
签名者链错误是由SHA2引起的。这是他们给我的回复：
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).
为了让我的 jar 签名，我正在处理多个问题。
最后更新
我收到了来自 Comodo 的新密钥，并且毫无问题地签署了我的 jar。
误区：我的原证书和新证书都是SHA-256。区别在于 CA。原来的是"COMODO RSA Code Signing CA"，而新的是"COMODO SHA-256 Code Signing CA"。两者的详细视图显示完全相同的算法。问题确实是 KSOftware 所说的。 RSA CA 尚未更新他们的方面。
命令行中“keypass”和“storepass”之前的字符都是“en dashes”（ASCII码0x96，见https://en.wikipedia.org/wiki/Dash).它们应该是“hyphen-minus”（ASCII 代码 0x2D）。
这可以通过在十六进制编辑器中查看字符串来检查（如 HxD）：
由于字符错误，“-keypass”无法被 jarsigner 识别为参数，这会打乱整个命令，从而导致出现奇怪的错误消息。
类似问题：Certificate chain not found, but keystore contains private key
我仔细阅读了问题 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 作为指南。
我签发的是真实证书，而不是问题中的自我证书。我也在使用最新的 JDK，1.8.0-60（64 位）。我卸载了所有其他 JDKs.
计算机：
OS: Windows 7 64-bit
JDK Path: "C:\Program Files\Java\jdk1.8.0_60"
我尝试了几种技术来消除 space 问题。从管理员命令提示符：
- 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（后面跟着）copy "C:\Program Files\Java\jdk1.8.0_60" C:\Documents\JDK2
命令行：
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
我通过查看证书详细信息验证了我的证书使用算法 SHA-2 (SHA-256)。当我将证书导出到 PFX 文件时，我尝试了检查框 1（包括路径中的所有证书）和框 3（扩展属性）的两种排列。我最初选择导出私钥。
我和密钥发行者谈过，他们认为别名应该是 39 个字符，但是我重新检查了发出该命令的命令，在反复尝试后，我得到了 37 个字符。
keytool.exe -importkeystore -srckeystore "C:\Documents\Signing\mypfx.pfx" -srcstoretype pkcs12 -destkeystore C:\SoftDev\JavaWorkspaces\myproject\Versions\Current64\mykeystore.keystore -deststoretype JKS
我使用上面提到的各种排列输入了上面指定的所有可执行文件（单独在上面列举的各种目录中并指定了完整路径。我尝试指定所有带引号和不带引号的文件名。
KSoftware 给我回信：
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?
当我对命令执行 -help 时，参数与教程相匹配并且有意义。 我无法解释别名长度和格式差异。 我被告知使用 JDK 的 "absolute latest version"，我是 (1.8.0-60)。我提到了版本，他们对此表示满意。 第 3 步和第 4 步显示相同的别名。也许当时编写教程的人获得了别名，le-e76649fec-3a2f-4cda-8a6e-441c224481b，在计算别名的 JDK 版本中，只是教程没有得到更新。 Comodo 是一家大公司，因此如果该页面源自他们或 KSoftware 最近没有经过练习，那么教程页面可能会被他们忽视。不过，从我收集到的信息来看，这些步骤似乎很合理。
更新:
根据我与 EJP 的对话，this question 似乎适用于签名者链问题。
来自Comodo/KSoftware的回应： 正如我在评论中提到的，@Omikron 在最初的问题上是正确的。错误是从 KSoftware.net 的网站上执行 copy/paste。
还有 2 个其他问题。 2. Oracle/Java 工具链不支持 SHA-256 (SHA2) only SHA1.
- Comodo 会发布 SHA-256，即使您在他们的订单上指定了 SHA-128 (SHA-1)。他们对我说他们将 discontinue/stop 发布 SHA-128。
签名者链错误是由SHA2引起的。这是他们给我的回复：
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).
为了让我的 jar 签名，我正在处理多个问题。
最后更新 我收到了来自 Comodo 的新密钥，并且毫无问题地签署了我的 jar。
误区：我的原证书和新证书都是SHA-256。区别在于 CA。原来的是"COMODO RSA Code Signing CA"，而新的是"COMODO SHA-256 Code Signing CA"。两者的详细视图显示完全相同的算法。问题确实是 KSOftware 所说的。 RSA CA 尚未更新他们的方面。
命令行中“keypass”和“storepass”之前的字符都是“en dashes”（ASCII码0x96，见https://en.wikipedia.org/wiki/Dash).它们应该是“hyphen-minus”（ASCII 代码 0x2D）。
这可以通过在十六进制编辑器中查看字符串来检查（如 HxD）：
由于字符错误，“-keypass”无法被 jarsigner 识别为参数，这会打乱整个命令，从而导致出现奇怪的错误消息。
类似问题：Certificate chain not found, but keystore contains private key