【发布时间】：2015-11-19 19:26:08
【问题描述】：
我仔细阅读了13335419、8748089、4282405 和其他一些问题。他们指出，最可能的原因是嵌入空间。另一个答案是可能的证书问题。我以this tutorial 为指导。
我有一个真实的证书，而不是一个自我证书，就像在问题中一样。我也在使用最新的 JDK，1.8.0-60（64 位）。我卸载了所有其他 JDK。
电脑：
OS: Windows 7 64-bit
JDK Path: "C:\Program Files\Java\jdk1.8.0_60"
我尝试了几种技术来消除空间问题。从管理员命令提示符：
- 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（后跟）复制“C:\Program 文件\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 给我回了信：
我认为问题在于您以某种方式为 jarsigner.exe 指定了太多参数，或者其中一个参数以某种方式无效。我对 Java 和 Jarsigner 的了解有限，但我确实注意到您使用的别名似乎与我以前见过的格式不同（它似乎太短了几个字符）。您是否从第 4 步得到了那个别名字符串，那是整个字符串吗？
当我对命令执行 -help 时，参数将教程与 tee 匹配并且有意义。 我无法解释别名长度和格式差异。 有人告诉我使用 JDK 的“绝对最新版本”，我就是（1.8.0-60）。我提到了这个版本，他们对此表示同意。 步骤 3 和 4 显示相同的别名。也许当时编写本教程的人从 JDK 的一个版本中获得了别名 le-e76649fec-3a2f-4cda-8a6e-441c224481b，该版本以不同的方式计算别名，只是教程没有更新。 Comodo 是一家大公司，所以如果教程页面来自他们或 KSoftware 最近没有进行过练习，那么教程页面可能会被他们忽略。不过，从我收集到的信息来看，这些步骤似乎是合理的。
更新：
根据我与 EJP 的对话，this question 似乎适合签名者的链问题。
来自 Comodo/KSoftware 的回应： 正如我在评论中提到的，@Omikron 在最初的问题上是正确的。错误是从 KSoftware.net 的网站复制/粘贴。
还有 2 个其他问题。 2. Oracle/Java 工具链不支持 SHA-256 (SHA2) 只支持 SHA1。
- 即使您在订单上注明 SHA-128 (SHA-1)，Comodo 也会发出 SHA-256。他们对我说他们将停止/停止发布 SHA-128。
签名者的链错误是由 SHA2 引起的。这是他们对我的回应：
我理解您的犹豫，但我向您保证，这些天我已经处理了很多“链未验证”问题，这都与 SHA-256 移动有关。不过，我可以解决这个问题，只需按照我发送的那些说明进行操作，我们就会让你摆脱困境......我仍然有点困惑为什么 Jarsigner 不让你在命令行上传递该密码，但这就是在这一点上或多或少是次要的。我们仍然可以让您几乎立即签署 JAR 文件，并从不同的根重新发布。
FWIW，迁移到 SHA-256 和所需的新 RSA 根对 Java 来说是一团糟，因为它们在添加受信任的根方面非常、非常缓慢。这一举措已经为人所知几年了，最近一次JDK 版本是第一个解决这个问题的版本，甚至它也没有很好地解决这个问题。目前最好的选择是使用已识别的较旧的受信任根（在 2020 年之前仍然有效）。
我正在处理多个问题以使我的 jar 签名。
最后更新 我收到了来自 Comodo 的新密钥，并且没有问题地签署了我的 jar。
误解：我的原始证书和新证书都是 SHA-256。区别在于 CA。原来的是“COMODO RSA Code Signing CA”，而新的是“COMODO SHA-256 Code Signing CA”。两者的详细视图显示完全相同的算法。问题确实是 KSOftware 所说的。 RSA CA 还没有更新他们的立场。
【问题讨论】：
-
尝试将别名放在引号中。尝试不使用 tsa 和 sigalg 参数。尝试将其简化为可行的情况。我同意可能存在嵌入空间：别名之前的某些内容被视为别名。
-
进度：jarsigner.exe 不希望我指定 –storepass。我输入了类似（减去双引号）–storepass mypassword 之类的内容。该工具似乎不需要、不需要或不喜欢 -keypass 参数。别名周围的引号没有区别。我被要求输入密码，然后我收到警告：“jar 签名。警告：签名者的证书未经验证。”这是什么意思？
-
这意味着您需要将签名者的证书链导入您的密钥库文件，使用-trustcacerts。它将与签署的证书一起提供。您通常不会在单个密钥上设置密码，例如 JSSE 除了您自己手动编码之外，无法处理它们。
-
问题出在其他问题上，keytool -import -trustcacerts -alias root -file "path-to-crt.cer" -keystore "path-to-jks.jks"，产生“Certificate already存在于别名 下的密钥库中，这是有道理的，因为我已经将证书添加到了密钥库文件中。
-
是的，那是你的证书，但我说的是签名者的链。
标签： java code-signing keystore keytool jarsigner