私の Java プログラムは jar ファイルにパッケージ化されており、外部の jar ライブラリである bouncy castleを利用しています。私のコードは正常にコンパイルされますが、jar を実行すると次のエラーが発生します。
スレッド「メイン」の例外 java.lang.SecurityException: マニフェストのメイン属性の署名ファイル ダイジェストが無効です
説明を探して 1 時間以上グーグル検索しましたが、ほとんど価値がありませんでした。誰かがこのエラーを以前に見たことがあり、助けを提供できる場合は、私は義務付けられます.
を使用してシェーディングされたuber-jarを作成しようとしたときにこのエラーが発生した場合maven-shade-pluginの解決策は、次の行をプラグイン構成に追加して、マニフェスト シグネチャ ファイルを除外することです。
<configuration>
<filters>
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
<!-- Additional configuration. -->
</configuration>
gradle を使用していて、ファット jar を作成して使用しようとしている場合は、次の構文が役立つ場合があります。
jar {
doFirst {
from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
}
exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA'
}
次のコマンドを使用してください
zip -d yourjar.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'
依存関係の一部は、署名済みの jar ファイルである可能性があります。それらをすべて 1 つの大きな jar ファイルに結合すると、対応する署名ファイルがまだ存在し、「結合された大きな」jar ファイルと一致しなくなるため、ランタイムは、jar ファイルが改ざんされたと考えて停止します (これは...話す）。
ant を使用していると仮定すると、jarfile の依存関係から署名ファイルを削除することで問題を解決できます。残念ながら、これを ant でワンステップで行うことはできません。
ただし、次を使用して、各jarfile依存関係に具体的に名前を付けることなく、2つのステップでAntでこれを機能させることができました。
<target name="jar" depends="compile" description="Create one big jarfile.">
<jar jarfile="${output.dir}/deps.jar">
<zipgroupfileset dir="jars">
<include name="**/*.jar" />
</zipgroupfileset>
</jar>
<sleep seconds="1" />
<jar jarfile="${output.dir}/myjar.jar" basedir="${classes.dir}">
<zipfileset src="${output.dir}/deps.jar" excludes="META-INF/*.SF" />
<manifest>
<attribute name="Main-Class" value="com.mycompany.MyMain" />
</manifest>
</jar>
</target>
sleep 要素は、将来の変更日を持つファイルに関するエラーを防ぐことになっています。
リンクされたスレッドで見つけた他のバリエーションは、私にとってはうまくいきませんでした。
ここにリストされている解決策は、ポインターを提供する場合があります。
結論：
公式の jar をそのままにして、アプリケーションの jar ファイルのマニフェスト ファイルに依存関係として追加するのがおそらく最善です。
IntelliJ IDEA 14.01 を使用しているときにこの問題が発生しました。
次の方法で修正できました。
[ファイル] -> [プロジェクト構造] -> [新規追加 (アーティファクト)] -> [jar] -> [モジュールから jar を作成] ウィンドウの依存関係を持つモジュールから:
あなたのメインクラスを選択してください
ライブラリからの JAR ファイル 出力ディレクトリへのコピーを選択し、マニフェスト経由でリンクします
セキュリティはすでに難しいトピックですが、最も一般的な解決策がセキュリティ署名を削除することであることに失望しています。JCE はこれらの署名を必要とします。Maven shade は署名を META-INF に入れる BouncyCastle jar ファイルを展開しますが、BouncyCastle 署名は新しい uber-jar (BC jar のみ) に対して有効ではなく、それがこのスレッドで無効な署名エラーの原因です.
はい、@ruhsuzbaykus が提案するように署名を除外または削除すると、元のエラーは解消されますが、新しい不可解なエラーが発生する可能性もあります。
java.security.NoSuchAlgorithmException: PBEWithSHA256And256BitAES-CBC-BC SecretKeyFactory not available
次のように、アルゴリズムを見つける場所を明示的に指定します。
SecretKeyFactory.getInstance("PBEWithSHA256And256BitAES-CBC-BC","BC");
私は別のエラーを得ることができました：
java.security.NoSuchProviderException: JCE cannot authenticate the provider BC
この同じスレッドの他の場所の提案に従って暗号化署名を削除したため、JCE はプロバイダーを認証できません。
私が見つけた解決策は、jar-in-jar アプローチを使用して BouncyCastle 署名を単一の実行可能 jarに保存する実行可能パッカープラグインでした。
これを行う別の方法 (正しい方法?) は、Maven Jar signerを使用することです。これにより、セキュリティ エラーが発生することなく Maven シェードを使用し続けることができます。ただし、コード署名証明書が必要です (Oracle は「Java コード署名証明書」を検索することをお勧めします)。POM 構成は次のようになります。
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<filters>
<filter>
<artifact>org.bouncycastle:*</artifact>
<excludes>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>your.class.here</mainClass>
</transformer>
</transformers>
<shadedArtifactAttached>true</shadedArtifactAttached>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jarsigner-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>sign</id>
<goals>
<goal>sign</goal>
</goals>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<keystore>/path/to/myKeystore</keystore>
<alias>myfirstkey</alias>
<storepass>111111</storepass>
<keypass>111111</keypass>
</configuration>
</plugin>
いいえ、JCE に自己署名証明書を認識させる方法はありません。そのため、BouncyCastle 証明書を保持する必要がある場合は、jar-in-jar プラグインを使用するか、JCE 証明書を取得する必要があります。
antを使用してjarファイルを作成すると仮定すると、META-INFディレクトリを省略するようにantに指示することができます。これは私のアリターゲットの簡略版です：
<jar destfile="app.jar" basedir="${classes.dir}">
<zipfileset excludes="META-INF/**/*" src="${lib.dir}/bcprov-jdk16-145.jar"></zipfileset>
<manifest>
<attribute name="Main-Class" value="app.Main"/>
</manifest>
</jar>
最近、自分のプロジェクトで IntelliJ を使い始めました。しかし、私の同僚の何人かは、同じプロジェクトで Eclipse をまだ使用しています。今日、IntelliJ によって作成された jar ファイルを実行した後、まったく同じエラーが発生しました。ここでのすべてのソリューションはほぼ同じことを話していますが、どれも簡単に機能しませんでした（おそらくANTを使用していないため、Mavenビルドで他のエラーが発生し、http://cwiki.apache.org/を参照しました） confluence/display/MAVEN/MojoExecutionException、また、署名済みの jar が何であるかを自分で把握できませんでした!)
最後に、これは私を助けました
zip -d demoSampler.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*SF'
私のjarファイルから何が削除されたと思いますか?!
deleting: META-INF/ECLIPSE_.SF
deleting: META-INF/ECLIPSE_.RSA
この問題は、いくつかの eclipse 関連ファイルに関連していたようです。
新しい jar 内のフォルダー META-INF を古い jar (新しいライブラリーを追加する前) と比較します。新しいファイルが存在する可能性があります。はいの場合は、それらを削除できます。それは役立つはずです。よろしく、999ミハル
エラー: JNI エラーが発生しました。インストールを確認し、再試行してください スレッド "main" で例外が発生しました java.lang.SecurityException: sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java: 314) で sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:268) で java.util.jar.JarVerifier.processEntry(JarVerifier.java:316) で java.util.jar.JarVerifier.update(JarVerifier.java) で:228) java.util.jar.JarFile.initializeVerifier(JarFile.java:383) で java.util.jar.JarFile.getInputStream(JarFile.java:450) で sun.misc.URLClassPath$JarLoader$2.getInputStream(URLClassPath) で.java:977)、sun.misc.Resource.cachedInputStream(Resource.java:77)、sun.misc.Resource.getByteBuffer(Resource.java:160) java.net.URLClassLoader.defineClass(URLClassLoader.java:454) で java.net.URLClassLoader.access$100(URLClassLoader.java:73) で java.net.URLClassLoader$1.run(URLClassLoader.java:368) でjava.net.URLClassLoader$1.run(URLClassLoader.java:362) で java.security.AccessController.doPrivileged(Native Method) で java.net.URLClassLoader.findClass(URLClassLoader.java:361) で java.lang.ClassLoader.loadClass (ClassLoader.java:424) で sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) で java.lang.ClassLoader.loadClass(ClassLoader.java:357) で sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.ジャワ:495)run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) ) java.lang.ClassLoader.loadClass(ClassLoader.java:424) で sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) で java.lang.ClassLoader.loadClass(ClassLoader.java:357) で.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) ) java.lang.ClassLoader.loadClass(ClassLoader.java:424) で sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) で java.lang.ClassLoader.loadClass(ClassLoader.java:357) で.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)331) java.lang.ClassLoader.loadClass(ClassLoader.java:357) で sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495) で331) java.lang.ClassLoader.loadClass(ClassLoader.java:357) で sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495) で
私を助けたもの (IntelliJ IDEA 2016.3): ファイル -> プロジェクト構造 -> アーティファクト -> JAR を追加 -> メイン クラスを選択 -> 「出力ディレクトリにコピーし、マニフェスト経由でリンク」を選択 -> OK -> 適用 -> ビルド - > アーティファクトの構築... -> 構築
同様の問題がありました。その理由は、Windows ボックスのデフォルト JRE とは異なる JRE を使用して JDK を使用してコンパイルしていたためです。
正しい java.exe を使用すると、問題が解決しました。