当前位置： 文江博客话题详情

jarsigner：此 jar 包含其证书链未经验证的条目

发布于 2024-12-19 17:50:15 字数 3622 浏览 2 评论 0原文

我正在尝试对 JAR 文件进行代码签名并使用 JDK 1.7u1。我们获得了 GoDaddy 代码签名证书，我按照此处的说明（方法 1）进行操作：http://help.godaddy .com/article/4780

JAR 签名正常，但是每当我尝试运行命令时： 使用 JDK 1.7u1 在我签名的 JAR 上使用 jarsigner -verify 我得到以下输出：

s        180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
      [CertPath not validated: null]

         342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
        6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
           0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm      2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
      [CertPath not validated: null]


  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

Warning: 
This jar contains entries whose certificate chain is not validated.

我还在 JDK 1.6u26 上使用与上面相同的 JAR 尝试了 jarsigner -verify 命令，并且1.6u14 回来后一切正常。 （以下输出来自 1.6u26）。

         180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF
         342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
        6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
           0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm      2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      [KeyUsage extension does not support code signing]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]


  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

我是否缺少为 JDK 1.7 正确签名 JAR 所需执行的额外步骤？

原文

I'm trying to code sign a JAR file and am using JDK 1.7u1. We acquired a GoDaddy Code Signing certificate and I followed the instructions (Approach 1) here: http://help.godaddy.com/article/4780

The JAR signs fine, however whenever I try to run the command:
jarsigner -verify on my signed JAR using JDK 1.7u1 I get the following output:

s        180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
      [CertPath not validated: null]

         342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
        6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
           0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm      2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
      [CertPath not validated: null]


  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

Warning: 
This jar contains entries whose certificate chain is not validated.

I also tried the jarsigner -verify command using the same JAR as above on JDK 1.6u26 and 1.6u14 and it came back as being fine. (Output below from 1.6u26).

         180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF
         342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
        6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
           0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm      2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      [KeyUsage extension does not support code signing]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]


  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

Am I missing an extra step I need to take to get the JAR signed properly for JDK 1.7?

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（8）

云归处 2024-12-26 17:50:15

我一直遇到同样的问题，如果它可以帮助其他人，问题在于 jarsigner 如何找到密钥库。

为了解决这个问题，请执行以下操作：

jarsigner -verify -keystore xxxx.jks mysignedjar.jar

I have been having the same issue and if it can help others the problem is in how jarsigner finds the keystore.

In order to fix the issue do:

jarsigner -verify -keystore xxxx.jks mysignedjar.jar
回复 原文
蘑菇王子 2024-12-26 17:50:15

您没有错过任何东西，而且您绝对不是唯一遇到这个问题的。经过近 12 个小时的努力，我发现问题的根源在于将 JDK 1.7 的二进制文件与旧版本的 Java（例如 JRE-1.6）混合在一起。更准确地说，keytool 附带 JRE，而 JDK 附带 keytool 和 jarsigner< /代码>。

因此，为了解决该问题，我从系统中完全卸载了 JDK-1.7 并安装了 JDK-1.6 Update 30。现在，如果我执行 jarsigner -verify -verbose -certs blah.jar ，它会生成 jar verify ，而不会发出任何警告，我相信这正是您所期望的。

You are not missing anything and you are definitely not alone with this problem. After a struggle of almost 12 hours, I figured out that the root of the problem lies in mixing binaries from JDK 1.7 with an older version of Java such as JRE-1.6. To be more precise, keytool comes with JRE, while JDK ships with both keytool and jarsigner.

So, to resolve the issue, I have completely uninstalled JDK-1.7 from my system and installed JDK-1.6 Update 30. Now, if I would do jarsigner -verify -verbose -certs blah.jar it would produce jar verified without any warning which I believe is what you expect.

回复 原文
梦境 2024-12-26 17:50:15

这只是一个您可以忽略的警告。

如果您确实不想忽略它，请在验证时告诉 jarsigner 您的密钥库在哪里。

jarsigner -verbose -verify -keystore ${KEYSTORE_PATH} ${YOUR_JAR_FILE}

这只是 JDK 7 中的一个新功能。

It's just a warning you can ignore.

If you really don't want to ignore it then tell jarsigner where your keystore is when you verify.

jarsigner -verbose -verify -keystore ${KEYSTORE_PATH} ${YOUR_JAR_FILE}

This is just a new feature in JDK 7.

回复 原文
过去的过去 2024-12-26 17:50:15

我对“DigiCert SHA2 Assured ID Code Signing CA”也有类似的问题。所有 Oracle Java 版本以及 OpenJDK 的行为都是相同的。 Digicert 支持将我重定向到此页面，但此处的任何说明都没有帮助我完成验证过程。

我正在尝试签署一个小程序，因此我需要它也可以在浏览器中进行验证，因此向 jarsigner -verify 提供密钥库路径的技巧不适用。

主要问题似乎是使用 SHA2 而不是 SHA1 操作证书时 keytool 中的错误，因为应用于 SHA1 证书的相同步骤列表始终有效，但对我来说从未适用于 SHA2。在我看来，keytool 无法检测导入到 jks 的证书的“可链接性”，因此 jarsigner 不会将正确的证书链嵌入到签名的 jar 中，只有最终的证书存储在 META-INF/myalias 中。改为 RSA 文件（可通过 openssl pkcs7 -in myalias.RSA -print_certs -inform DER -out certs.crt 进行验证）。

Digicert 建议“...我们有时会看到根第一次实际上未正确或完全导入的问题，但再次运行指向根的导入命令可以解决此问题”，即使如此对我的情况没有帮助。

由于无法向 keytool 明确说明链中的证书，我决定使用 openssl 构建一个链并像这样导入它：

cat TrustedRoot.pem DigiCertCA2.pem my.crt  >chain
openssl pkcs12 -nodes -export -in my.crt  -inkey my.key -out tmp.p12 -name myalias -certfile chain
keytool -importkeystore -destkeystore mykeystore.jks -srckeystore tmp.p12 -srcstoretype PKCS12

此后 mykeystore.jks 似乎只包含我的证书，而不包含 DigiCertCA2或通过 keytool -list 命令列出的根，但使用 -v （详细）它会公开链深度及其证书：

~/$ keytool  --list --keystore mykeystore.jks  -v|grep -e chain -e Certificate\\[
Enter keystore password:  123456
Certificate chain length: 3
Certificate[1]:
Certificate[2]:
Certificate[3]:

这就是 jarsigned 正确签署 jar 所需的内容，即嵌入正确的证书链并使 jar 也可供最终浏览器用户验证。

I had similar problem with the "DigiCert SHA2 Assured ID Code Signing CA". All oracle java versions as well as OpenJDK behaved the same. Digicert support redirected me to this page, but nothing stated here had helped me with the verification process neither.

I am trying to sign an applet, so I need it to be verifiable also in the browser, so the trick with providing the keystore path to jarsigner -verify is not applicable.

Main problem seems to be a bug in keytool when operating with certs using SHA2 instead of SHA1, because the same list of steps applied on SHA1 certs always works and never worked for SHA2 for me. It appears to me, that keytool is not capable of detecting the "chainability" of certificates imported to jks and thus jarsigner does not embed proper certs chain into the signed jar, there is only the final certificate stored in the META-INF/myalias.RSA file instead (verifiable by openssl pkcs7 -in myalias.RSA -print_certs -inform DER -out certs.crt).

Digicert suggested "...we sometimes see issues with the Root not actually being imported correctly or fully the first time, but running an import command that points to the Root again can fix this", even this did not help in my case.

As there is no way to say explicitly to keytool what certs are about to be in a chain, I've decided to build a chain using openssl and import it like this:

cat TrustedRoot.pem DigiCertCA2.pem my.crt  >chain
openssl pkcs12 -nodes -export -in my.crt  -inkey my.key -out tmp.p12 -name myalias -certfile chain
keytool -importkeystore -destkeystore mykeystore.jks -srckeystore tmp.p12 -srcstoretype PKCS12

After this mykeystore.jks appears to contains only my certificate, not DigiCertCA2 or the Root when listed by keytool -list command, but with -v (verbose) it discloses chain depth and its certs:

~/$ keytool  --list --keystore mykeystore.jks  -v|grep -e chain -e Certificate\\[
Enter keystore password:  123456
Certificate chain length: 3
Certificate[1]:
Certificate[2]:
Certificate[3]:

And this is what jarsigned needs to sign the jar properly, i.e. to embed proper certs chain and make jar verifiable also for final browser user.

回复 原文
习惯成性 2024-12-26 17:50:15

我发现，如果您使用 JRE 1.7.0_21 对 Jar 文件进行签名并使用较低版本的 JRE 1.7.0 进行验证，也会打印消息“This jar contains itemswhichcertificate chain is not validated”。

结论：无需降级到Java 1.6，只需使用相同的jarsigner版本进行签名和验证即可。

I found that the message "This jar contains entries whose certificate chain is not validated" is also printed if you sign the Jar file using JRE 1.7.0_21 and verify it with a lower version of JRE 1.7.0.

Conclusion: no need to downgrade to Java 1.6, simply use the same jarsigner version for both signing and verification.

回复 原文
因为看清所以看轻 2024-12-26 17:50:15

这是 JDK 7+ 中的安全机制。当签署没有时间戳的 jar 时，这会打印警告，可以使用 -tsa 标志传递。如果 jar 没有时间戳，它将在超过其有效期后停止工作。

如果您正在构建 Android 目标，并且使用高于 1.7.0_51 的 JDK，则始终会打印此警告。 Android 通常建议通过 30 年有效期，因此可以 100% 忽略此警告，除非您的商业计划是允许用户在 2046 年使用相同的 .apk。

这是该功能的票证，目的是鼓励时间戳，我相信一定会有效果。 http://bugs.java.com/view_bug.do?bug_id=8023338 。

This is a security mechanism in JDK 7+. This prints the warning when signing jars without a timestamp, which can be passed with a -tsa flag. If a jar has no timestamp, it will stop working past its validity date.

If you are building an Android target, this warning will always print if you are using a JDK newer than 1.7.0_51. Android generally recommends passing 30 years validity, so this warning can be 100% ignored unless you business plan is to allow users to use the same .apk in 2046.

Here is the ticket for the feature, the purpose is to encourage timestamping, which I believe will be effective. http://bugs.java.com/view_bug.do?bug_id=8023338.

回复 原文
相思故 2024-12-26 17:50:15

如果您的证书来自 Entrust，请确保您使用的是较新的根证书。

http://www.entrust.net/knowledge-base/technote。 cfm?tn=7875

问题：

您收到一条错误消息，指出您的 SLL 证书
由于缺少基本约束字段，验证失败。

解决方案：

2009年，Entrust重新发布了2048位根证书，包括
基本约束字段 (cn=Entrust.net 证书颁发机构
(2048)，有效期至 2029 年 7 月 24 日)。 Entrust 已停止推出
通过 Windows 和 Java 中的根更新获得原始 2048 位根
（从1.6版本更新22开始）。更新后的根证书
包含基本约束可以在这里找到：

https://www.entrust.net/downloads/binary/entrust_2048_ca.cer

If your certificates are from Entrust, make sure you are using the newer root certificate.

http://www.entrust.net/knowledge-base/technote.cfm?tn=7875

Problem:

You receive an error message that states your SLL certificate
validation has failed due to a missing Basic Constraints field.

Solution:

In 2009, Entrust re-released the 2048-bit root certificate to include
the Basic Constraints field (cn=Entrust.net Certification Authority
(2048), valid to 7/24/2029). Entrust has stopped pushing out the
original 2048-bit root through root updates in Windows and Java
(starting from version 1.6 update 22). The updated root certificate
containing Basic Constraints can be found here:

https://www.entrust.net/downloads/binary/entrust_2048_ca.cer

回复 原文
请恋爱 2024-12-26 17:50:15

当您创建/导出证书到 p12（由 jarsigner 使用）时，请确保选择以下选项（例如，如果使用 Internet Explorer 向导导出），则需要在导出向导中选择以下选项。

“导出私钥”
“如果可能的话，将所有证书包含在认证路径中”
在选项 .PFX 或 PKCS #12 下选中“导出所有扩展属性”。

如果您一开始就正确创建了 p12，那么 jarsign 不需要特殊的努力。

When you create/export your certificate to a p12 (used by the jarsigner) make sure you ensure the following is selected (for example if you export using Internet explorer wizard) you will need to select the following in the export wizard.

"Export the private key”
“Include all certificates in the certification path if possible”
“Export all extended properties” checked under the option .PFX or PKCS #12.

If you create the p12 properly in the first place then jarsign requires no special effort.

回复 原文
~没有更多了~

关于作者

花想c

暂无简介

文章
评论
25 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

饮湿

文章 0 评论 0

明月

文章 0 评论 0

02

文章 0 评论 0

hs1283

文章 0 评论 0

风向决定发型

文章 0 评论 0

落花浅忆

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文