JARファイルにコード署名しようとしていますが、JDK 1.7u1を使用しています。 GoDaddyコード署名証明書を取得し、次の指示(アプローチ1)に従いました: http://help.godaddy.com/article/478
JARは正常に署名しますが、コマンドを実行しようとするたびに:jarsigner -verify
JDK 1.7u1を使用して署名されたJARで次の出力を取得します。
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.
また、jarsigner -verify
コマンドは、JDK 1.6u26および1.6u14で上記と同じJARを使用し、問題なく戻ってきました。 (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を適切に署名するために必要な追加の手順がありませんか?
あなたはnot何も見逃しており、間違いなくnotだけでこの問題を抱えています。ほぼ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 verified
が生成されます。
私は同じ問題を抱えていますが、それが他の人を助けることができるなら、問題はjarsignerがキーストアを見つける方法にあります。
この問題を解決するには、次を実行します。
jarsigner -verify -keystore xxxx.jks mysignedjar.jar
これは無視できる警告です。
本当に無視したくない場合は、検証時にキーストアの場所をjarsignerに伝えます。
jarsigner -verbose -verify -keystore ${KEYSTORE_PATH} ${YOUR_JAR_FILE}
これは、JDK 7の単なる新機能です。
「DigiCert SHA2 Assured ID Code Signing CA」でも同様の問題がありました。すべてのOracle JavaバージョンとOpenJDKは同じように動作しました。Digicertのサポートによりこのページにリダイレクトされましたが、ここで述べたことは検証プロセスにも役立ちませんでした。
アプレットに署名しようとしているので、ブラウザでも検証可能にする必要があるため、キーストアパスをjarsigner -verifyに提供するトリックは適用できません。
SHA1証明書に適用されるステップの同じリストは常に機能し、SHA2には機能しないため、SHA1の代わりにSHA2を使用して証明書を操作する場合、主な問題はkeytoolのバグのようです。 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には、keytool -listコマンドでリストされたときにDigiCertCA2またはルートではなく、証明書のみが含まれているように見えますが、-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を検証可能にします。
JRE 1.7.0_21を使用してJarファイルに署名し、JRE 1.7.0の下位バージョンで検証すると、「このjarには証明書チェーンが検証されていないエントリが含まれています」というメッセージも出力されることがわかりました。
結論:Java 1.6にダウングレードする必要はありません。署名と検証の両方に同じjarsignerバージョンを使用するだけです。
これは、JDK 7以降のセキュリティメカニズムです。これは、-tsaフラグで渡すことができるタイムスタンプなしでjarに署名するときに警告を出力します。 jarにタイムスタンプがない場合、有効期限を過ぎて動作を停止します。
Androidターゲットをビルドしている場合、1.7.0_51よりも新しいJDKを使用している場合、この警告は常に出力されます。Androidは、 、ビジネスプランで2046年にユーザーが同じ.apkを使用できるようにする場合を除き、この警告は100%無視できます。
この機能のチケットは次のとおりです。目的は、タイムスタンプを有効にすることです。これは効果的だと思います。 http://bugs.Java.com/view_bug.do?bug_id=8023338 。
(jarsignerによって使用される)p12に証明書を作成/エクスポートするとき、次が選択されていることを確認してください(たとえば、Internet Explorerウィザードを使用してエクスポートする場合)、エクスポートウィザードで次を選択する必要があります。
「プライベートキーをエクスポートする」「可能であれば、証明書パスにすべての証明書を含める」「.PFXまたはPKCS#12」オプションでチェックされている「すべての拡張プロパティをエクスポートする」.
最初にp12を適切に作成した場合、jarsignは特別な作業を必要としません。
証明書がEntrustからのものである場合、新しいルート証明書を使用していることを確認してください。
http://www.entrust.net/knowledge-base/technote.cfm?tn=7875
問題:
Basic Constraintsフィールドがないため、SLL証明書の検証に失敗したことを示すエラーメッセージが表示されます。
溶液:
2009年、Entrustは2048ビットのルート証明書を再リリースして、Basic Constraintsフィールド(cn = Entrust.net Certification Authority(2048)、7/24/2029まで有効)を追加しました。 Entrustは、WindowsおよびJava(バージョン1.6アップデート22以降)のルートアップデートを介して、元の2048ビットのルートをプッシュすることを停止しました。基本制約を含む更新されたルート証明書は、次の場所にあります。
https://www.entrust.net/downloads/binary/entrust_2048_ca.cer