InstallShield セットアップに署名するための証明書があります。今年証明書を更新したところ、中間証明書「thawte code signing ca - g2」に依存するようになりました。
多くのお客様がこの中間ルート証明書をインストールしていないのではないかと心配しています (実際、私たち自身のビルド サーバーには中間ルート証明書がインストールされていなかったため、証明書の更新後にビルドが失敗し始めました)。
その中間証明書を配布するためのベスト プラクティスは何ですか? より一般的な「thawte コード署名 CA」に依存するように認証パスを変更する方法はありますか?
助けていただければ幸いです。
ありがとう、サンジェイ
私はついに問題を理解しました。エクスポートするときに pfx ファイルに証明書のルートを含めるオプションがあることがわかりました。以下は、thawte から取得した証明書をインストールした Windows マシンで実行した内容です。1. [スタート] -> [ファイル名を指定して実行] -> certmgr.msc から証明書ストアを開きます。 2. 証明書をエクスポートします。3. 秘密鍵も含めるように選択してください。4. 次に、ルート証明書を含めるオプションが表示されます。これはデフォルトではオフになっています。チェックしてください。
Micrsoft には、信頼できるルート プログラムがあり、現在、次のメンバーが含まれています。
Windows ルート証明書プログラム - メンバー リスト (すべての CA)
一般に配布されるアプリケーションの場合、ベスト プラクティスは、これらのルートのいずれかによってバックアップされたコード署名証明書を取得することです。内部エンタープライズ アプリケーション (IT、DoD ectera) の場合、証明書のルートを配布する代わりに手段があれば、他のアプリケーションを使用できます。InstallShield は現在、これを直接行うことはできませんが、CAPI / CAPICOM / .NET X509 クラスを呼び出すカスタム アクションを使用することは可能です。
ところで、証明書の詳細を見るときは、最初のエントリまで調べて、ルートが誰であるかを確認してください。たとえば、私の証明書には COMODO Code Signing 2 と書かれていますが、その上には USERTrust と書かれています。USERTrust 証明書を表示すると、「UTN-UserFirst-Object」と表示されます。その名前は、上記のリンク先の Microsoft Web ページで見つかります。