https://blogs.oracle.com/java-platform-group/entry/self_signed_certificates_for_a
先頃発表した、Java 7 Update 51（2014年1月）で計画されている変更が確定し、デフォルトのセキュリティスライダーを操作するには、コードの署名とPermissionというManifest属性を必要とするようになります。
New security requirements for RIAs in 7u51 (January 2014)コード署名は、業界で推奨されている一般的な方法で、コンピュータが実行するコードが、作成者のコードと同じことを判断するのに有用です。
https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias
http://orablogs-jp.blogspot.jp/2013/11/new-security-requirements-for-rias-in.html
Securing Software Distribution with Digital Code Signing
https://casecurity.org/2013/10/16/securing-software-distribution-with-digital-code-signing/
このエントリは、パブリックな認証局の関与がない、自己署名証明書を利用する必要があるユーザーを支援するために記載しています。
The role of self-signed certificates within a known community
既知のコミュニティ内で自己署名証明書をまだ使用することができます。自己署名とCAから購入した証明書の違いは、自己署名の場合は、それが有効であることを示すために、自己署名証明書をインポートする必要があるのに対し、認証局（Certificate Authorities）は既にデフォルトで信頼されている、というところにあります。これは、私の証明書が私のものであると信頼してくれる既知のコミュニティでは有効ですが、実際に連絡できないとか、私の証明書を信頼する必要があるシステムを知ることができないところへはスケールしません。多くの異なる要件や頻繁なチェックを通っているため、パブリックな認証局は既に広く信頼されています。
CA/Browser Forumドキュメントページ例えば、大学の学生でメーリングリストやWebページで公開証明書を共有する大学生、イントラネットに発行する会社員、エンドユーザに証明書を展開するシステム管理者などを考えてみましょう。展開を自動化するので、管理されたマシンを使うと楽になりますが、これは必須ではありません。要は、単に人々があなたの証明書を信頼してインポートすることなのです。
https://www.cabforum.org/documents.html
How to distribute self-signed certificates for a known community
自己署名証明書をに配布し、ユーザーがその自己署名証明書を信頼するにはいくつか手順があります。- 署名のために公開／秘密鍵のペアを作成する
- あなたのパブリック証明書を他者のためにエクスポートする
- あなたの証明書を、あなたを信頼するマシンにインポートする
- 異なるマシンで動作することを検証する
Creating a public/private key pair for signing
公開／秘密鍵のペアを持つことで、アイテムに自分で署名し、認証局に証明書署名要求（CSR）を認証局に発行することができます。キーペアを作成するための手順に従って、あなたの公開・秘密鍵のペアを作成します。
Generate Keys (The Java Tutorial)確認した全ての認証局で類似の手順を提供していましたが、利用したコマンドを以下にまとめておきます。
http://docs.oracle.com/javase/tutorial/security/toolsign/step3.html
- キーペアを生成します。
keytool -genkeypair -alias erikcostlow -keyalg EC -keysize 571 -validity 730 -keystore javakeystore_keepsecret.jks
- このファイルに適切なパスワードを指定します。
- エイリアス "erikcostlow" は筆者の名前で、覚えやすいものです。あなたの名前として"mykey"のようなものに置き換えましょう。
- キーアルゴリズムとしてEC（楕円曲線）、キーサイズとして571を指定するとキーが強固になります。
- A (relatively easy to understand) primer on elliptic curve cryptography
http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ - Keylength - NIST Report on Cryptographic Key Length and Cryptoperiod (2012)
http://www.keylength.com/en/4/ - 全ての鍵に有効期限を設定すべきです。2年もしくは730日が適切かつ妥当な長さでしょう。ほとんどのパブリック認証局では1年から5年間としています。
- 鍵をjavakeystore_keepsecret.jksに配置しましょう。このファイルには秘密鍵が含まれており、共有してはいけません。誰か他人がこれらの秘密鍵を入手すた場合、あなたの署名になりすますことができます。自動化されたクラウドバックアップシステムと秘密鍵ストアには是非注意して下さい。
- 全ての質問に回答します。上記で指定した"-validity"の日付の間これらの回答が有効なので、正しい回答をすることが重要です。
What is your first and last name? [Unknown]: First Last What is the name of your organizational unit? [Unknown]: Line of Business What is the name of your organization? [Unknown]: MyCompany What is the name of your City or Locality? [Unknown]: City Name What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: US Is CN=First Last, OU=Line of Business, O=MyCompany, L=City, ST=CA, C=US correct? [no]: yes Enter key password for <erikcostlow> (RETURN if same as keystore password):
- 成果物を検証します。
これで新しいキーペアが出来ました。keytool -list -keystore javakeystore_keepsecret.jks
Exporting your public certificate for others
公開鍵インフラストラクチャは2個のシンプルなコンセプトに依拠しています。公開鍵は公開してもよいが、秘密鍵は秘匿しなければならない、というものです。公開証明書をエクスポートすることで、証明書をインポートしてあなたを信頼しようとする他者と共有することができます。Export the Public Key Certificate (The Java Tutorials)
http://docs.oracle.com/javase/tutorial/security/toolsign/step5.html
これを検証するために、ほとんどのOSで.cerファイルをダブルクリックして開くことができます。証明書作成時に入力した情報が表示されるはずです。keytool -exportcert -keystore javakeystore_keepsecret.jks -alias erikcostlow -file erikcostlow.cer
これは他者と共有することになるファイルです。この証明書を使ってあなたからのこの証明書で署名されたアーティファクトを証明しようとします。直接マシンを管理しないのであれば、既知のコミュニティ仲間が信頼するはずの場所、例えばイントラネットのページなどに証明書ファイルを配置すべきです。
Import the certificate onto machines that should trust you
証明書を信頼するためには、既知のネットワークに入っている人があなたの証明書をキーストアにインポートする必要があります。最初の手順は証明書が本当にあなたのものであることを検証することですが、これは任意の方法、例えばメール、電話、あるいは直接確認、などの方法で実施できます。既知のネットワークでは通常このような方法が可能です。正しいキーストアを判断するには…
Deployment Configuration File and Properties
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/properties.html
- 個々人のユーザーが別のユーザーを信頼する場合、正しいファイルはユーザーディレクトリ内にあります。
（例）USER_HOME\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs
（例）C:\Program Files\Java\jre8\lib\security\cacertsなお、cacertsのデフォルトパスワードはkeytoolのドキュメントに記載がある通り、"changeit"です。
keytool - Key and Certificate Management Tool http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.htmlMacやLinuxのファイルパスは上記リンクに含まれています。
キーストアへの証明書のインポート手順に従って下さい。
Import the Certificate as a Trusted Certificate (The Java Tutorials)
http://docs.oracle.com/javase/tutorial/security/toolsign/rstep2.html
この場合、覚えやすいので、まだエイリアスとして自分の名前を使っています。貴社の名前のエイリアスを使うこともできます。keytool -importcert -keystore THEKEYSTOREFROMABOVE -alias erikcostlow -file erikcostlow.cer
Scaling distribution of the import
多くのマシン間で証明書を適用する最も簡単な方法は、単に.certファイルやcacertsファイルをマシンに配置することです。これを実施する場合、人々は自分のマシンのこのファイルに加えた全ての変更に気を付けて下さい。- 信頼済み.certs: ユーザーディレクトリに発行する場合、ユーザーが直近で更新してから追加した鍵をあなたのファイルが上書きします。
- CACerts: ファイルの上書きよりは、インストール先のマシン各々でimportコマンドを再実行するのが一番です。アップグレードの間同じcacertsファイルを変更しないだけであれば、追加・削除される任意のCAを上書きします。再度インポートすれば変更に追随します。
Verify work on a different machine
検証とは、あなたが署名している証明書を追加した後に、署名済みのアーティファクトが適切に信頼されていることを確認するため、クライアントマシン上でチェックする方法です。多くの人はデプロイメント・ルールセットを使って始めました。Introducing Deployment Rule Setsデプロイメント・ルールセットを以下のようにして検証することができます。
https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets
- デプロイメント・ルールセットを秘密鍵を保存するコンピュータ上に作成し、署名します。
- 署名している証明書をインポートした別のマシンにデプロイメント・ルールセットをコピーします。
- Javaコントロールパネルのセキュリティ・タブでデプロイメント・ルールセットが表示されることを確認します。
個別のJARファイルや複数のJARファイルの検証
証明書チェーンをjarsignerコマンドでテストできます。出力に"jar verified"と出ない場合には、以下のコマンドを発行して理由を確認して下さい。jarsigner -verify filename.jar
“CertPath not validated”という言葉に対する出力をチェックして下さい。jarsigner -verify -verbose -certs filename.jar
Good Entry, thanks!
返信削除