InstallShieldセットアップに署名するための証明書があります。今年私たちの証明書を更新したとき、中間証明書 "thawte code signing ca - g2"に依存します。InstallShieldセットアップに署名し、中間証明書を含めるベストプラクティス
多くのお客様には、この中間ルート証明書がインストールされていない可能性があります（実際には独自のビルドサーバーには証明書がないためビルドに失敗しました）パブリッシャー "エラーです。
中間証明書を配布するベストプラクティスは何ですか？より一般的な "thawteコード署名CA"に依存するように、証明書パスを変更する方法はありますか？
私は非常に助けていただければ幸いです。
おかげで、 サンジェイ
Micrsoft電流は、以下のmemebers含まれている信頼されたルートプログラムがあります。一般の人に配布するアプリケーションのために
Windows Root Certificate Program - Members List (All CAs)
は、ベストプラクティスは、コードを取得することですがこれらのルートの1つによってバックアップされた署名証明書。社内のエンタープライズアプリケーション（IT、DoD ectera）では、証明書のルートを配布する代わりに、他の方法を使用することができます。 InstallShieldではこれを直接行うことはできませんが、CAPI/CAPICOM/.NET X509クラスを呼び出すカスタムアクションを使用することは可能です。
ところで、証明書の詳細を見ると、ルートが誰であるかを知るための最初のエントリまですべて見ることができます。たとえば、私の証明書はCOMODOコード署名2と言っていますが、それより上にはUSERTrustがあります。 USERTrustの証明書を見ると、「UTN-UserFirst-Object」と表示されます。その名前は、上記のリンク先のMicrosoft Webページにあります。
私はついにこの問題を理解しました。 pfxファイルをエクスポートするときに証明書ルートを含めるオプションがあります。以下は、私がthawteから得た証明書をインストールした私のWindowsマシンで私が続いたことです。 1.スタート→実行→certmgr.msc から証明書ストアを開きます。2.証明書をエクスポートします。 3.秘密鍵も含めて選択するようにしてください。 4.ルート証明書を含めるオプションが表示されます。これはデフォルトではチェックされていません。それを確認してください。
詳細な説明はありがとうございます。だから、私はそのリンクを見て、 "thawteコード署名ca - G2"はそこに記載されていない見つける。ユーザーがこの証明書をインストールしておらず、彼がsetup.exeのプロパティを調べようとすると、「署名の証明書を検証できません」と表示されます。 したがって、カスタムアクションで証明書をインストールするようにコーディングを行っても、この特定の問題は修正されません。 私は、上記のリンクに記載されている証明書のいずれかによってバックアップされた証明書を取得することしかできないと思いますか？ –
あなたは、介入なしに可能な限り多くのマシンで動作するようにしたい場合は、はい。私が使用しているプロバイダに関連する情報のためのGoogleの安いコード署名。 –