带有签名战争文件的 osgi 安全性答案

【问题标题】：osgi security with signed war file带有签名战争文件的 osgi 安全性
【发布时间】：2013-10-13 22:18:17
【问题描述】：

谁能帮帮我？

我想在我的应用程序中使用 osgi 安全性。因此，我编写了一个安全包，它授予所有由我的密钥库签名的包。我的一个包是一个战争文件（Bundle10）。如果我启动部署了war包的服务器（带有felix的glassfish），我会得到一个java.lang.SecurityException：

Exception while processing WEB-INF/classes/com/xy/SomeClass.class inside 
file:/tmp/osgiapp430591893594363740/WEB-INF/lib/Bundle10.jar of size 2.111

java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:221)
at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:176)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:288)
at java.util.jar.JarVerifier.update(JarVerifier.java:199)
at java.util.jar.JarFile.initializeVerifier(JarFile.java:327)
at java.util.jar.JarFile.getInputStream(JarFile.java:395)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.getEntry(InputJarArchive.java:244)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:166)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)

我使用 maven jasigner 插件对捆绑包进行了签名。

【问题讨论】：

我得到了 WEB-INF/classes/ 中每个类的异常，但是应用程序运行没有任何问题。

标签： security osgi war jarsigner

【解决方案1】：

异常告诉您清单主要部分的 signers.sf 中的摘要不正确。这是包含 OSGi 元数据的部分。所以看起来这个WAR在签名后就变成了一个bundle？

签名相当复杂。清单包含 2 个部分，一个 main 部分和 jar 中每个资源的一个部分。这些资源部分中的每一个都以 Name: 属性开头，该属性标识资源的路径。当您要签署 JAR 时，您首先为每个属性创建清单和资源部分，其中资源部分包含资源的一个或多个摘要（SHA、MD5 等）。

您可以有多个签名者，因此您必须为每个签名文件选择一个名称。在此签名文件中，您再次拥有一个主要部分和许多资源部分。在主要部分中，您必须拥有一项或多项

X-Digest-Manifest-Attributes: <X digest of manifest main section>

X 可以再次成为使用的摘要算法之一。清单中的资源部分必须包含清单中相应资源部分的摘要（不是资源！）。

      MANIFEST.MF               <>.SF
      +--------------+  
 Main |Bundle-Sym .. |    <---  X-Digest-Manifest-Main-Attributes: 345678...
      |Bundle-Vers.. |   
      +--------------+ 
 Name |Name: a.class |    <---  Name: a.class
      |X-Digest: 56A5|          X-Digest:  4789...
      +--------------+
      |Name: b.class |    <---  Name: b.class
      |X-Digest: ACE |          X-Digest:   65123...
      +--------------+

简而言之，您的主要清单部分未正确签名。您要么在 .SF 文件中缺少 -Digest-Manifest-Main-Attributes，要么（很可能）在计算 OSGi 标头之前计算过它。

如果您使用的是 bnd，则可以直接从 bnd 对包进行签名。

【讨论】：

如何使用 maven-bundle-plugin (bnd) 对包进行签名，或者如果在计算 OSGi 标头之前已计算问题，如何解决该问题
我用 maven 构建了 war 文件并用 jarsigner 手动签名，但我又得到了异常！？
验证 JAR 时会发生什么？ jarsigner -verify file.war
我得到“jar 验证”。
如果我在 felix 中部署捆绑包，我会从问题中得到例外情况

【解决方案2】：

问题是由 GlassFish WAB 安装过程引起的。如果 WAB 在 WEB-INF/classes 目录中包含松散的类文件，它们将被打包到一个新的 JAR 文件中。这会破坏签名。

在我看来，这是一个 GlassFish 错误。我创建了一个 GlassFish 错误票：https://java.net/jira/browse/GLASSFISH-20861

解决方法：将您的松散类文件打包成一个 JAR 文件并将其放入 WEB-INF/lib 目录中。然后将 JAR 文件添加到 Bundle-ClassPath MANIFEST.MF 条目。

【讨论】：