私の会社はGoDaddyからドライバー署名証明書を購入しました。これを使用して、Microsoftのusbser.sysを使用する一部のUSBデバイスのドライバーである単純なINFファイルに署名しました。署名したWindows764ビットコンピューターではすべてが機能しているようです。INFファイルを右クリックして[インストール]を選択すると、2番目に表示される警告は、正しい発行元名を示すこの適切な警告です。

ただし、別のコンピューター（Windows Vista 64ビット）に移動し、INFファイルを右クリックして[インストール]を選択すると、代わりに次のエラーメッセージが表示されます。

これにより、ドライバーが適切に署名されていないと思います。コンピューターで見栄えがする唯一の理由は、GoDaddyのインストールプロセス中にインストールしたルート/中間/クロス証明書が原因です。コンピューターに証明書を手動でインストールしなくても、ユーザーが私たちが確認済みの発行元であることを確認できるようにしたいと思います。

同じディレクトリにあるINFファイルと.catファイル。

なぜこれが起こっているのか、どうすれば修正できるのか誰かが知っていますか？

主な問題は、実行時にこのエラーが発生することであると思われますsigntool verify /v pololu.cat（詳細は以下を参照）。理由はわかりません。

SignToolエラー：証明書チェーンは処理されましたが、信頼プロバイダーによって信頼されていないルート証明書で終了しました。

私の手順の詳細

Driver Signing Certificateは、数週間前に発売されたGoDaddyの新製品です。コード署名証明書との違いはよくわかりませんが、同じ価格です。Go DaddyのWebサイトの指示に従って証明書をダウンロードしてインストールしましたが、指示は実際には完全には一致していません。手順1でMicrosoftCrossCertificateをインストールした後、次のような赤い警告メッセージが表示されました。

証明書をインストールする前に、Windows Updateを使用してルート証明書を更新するか、リポジトリからルート証明書を手動でダウンロードしてインストールする必要があります。

どうしたらいいのかわからない。リポジトリからいくつかのGoDaddyルート証明書をインストールしましたが、目立った違いはありませんでした。

最新バージョン（8.0）のWindows Driver Kit（WDK）をインストールしてから、最新バージョン（8.0）のWindows Software Development Kit（SDK）forWindows8をインストールしました。これにより、inf2catおよびsigntoolユーティリティにアクセスできます。どちらのキットも先月リリースされたので、私たちが踏み込んでいるいくつかの新しいバグがある可能性があります。

新しいディレクトリに、次の3つのファイルを配置します。

1. pololu_usb_to_serial.inf、署名したいINFファイル。長いですがシンプルです。ここで読むことができます。このINFファイルはスタンドアロンドライバーです。ドライバパッケージに他のファイルは必要ありません。このファイルは、基本的に当社が何年にもわたって正常に配布（署名なし）したバージョンと同じですが、Inf2Catがそれを受け入れるためにいくつかの変更を加える必要がありました。
2. mscvr-cross-gdroot-g2.crt、GoDaddy証明書リポジトリからダウンロードしました。これは、「Go Daddyルート認証局-G2」がMicrosoftによって信頼されていることを証明する相互証明書だと思いますが、これが使用するのに適切な証明書であるかどうかは完全にはわかりません。
3. sign_it.bat、署名を行うために実行するバッチファイル。

バッチファイルには次のものが含まれています。

最初のコマンドは、WindowsDriverKitから呼び出しますinf2cat。/vオプションはそれを冗長にします。この/driver:%~dp0オプションは、バッチファイルを含むディレクトリを指します。a.は何らかの理由で機能せず、これはフルパスをハードコーディングするよりも優れています。この/osオプションは、このドライバーパッケージでサポートしたいすべてのオペレーティングシステムを指定します。このコマンドはを作成しますpololu.cat。

signtool2番目のコマンドは、Windows Software Development Kitから呼び出して、カタログファイルに署名します。/vオプションはそれを冗長にします。この/acオプションは、どの相互証明書を使用するかを指定します（上記の＃2を参照）。この/nオプションは、使用する証明書の名前を指定します（その証明書は、に従ってコンピューターにインストールされますcertmgr.msc）。この/tオプションは、GoDaddyのタイムスタンプサーバーのURLを指定します。

バッチファイルを実行したときのコマンドプロンプトの出力は次のとおりです。

私が言ったように、私は.catファイルと.infファイルを同じディレクトリに一緒に保持していますが、それらに署名した場合、それらはコンピュータ上でのみ正しく機能します。

Signtoolによる検証

Microsoftのsigntoolユーティリティには、署名が正しいかどうかを確認できる「確認」機能もあります。検証時に使用できる3つの異なるポリシーがあり、それぞれが異なる結果をもたらします。

• Windowsドライバー検証ポリシーでは、署名チェーンはMicrosoftにさかのぼることはなく、ルートが信頼されていないことに関するエラーメッセージが出力されます。それは私には問題のようです。
• デフォルトの認証コード検証ポリシー（/pa）には、署名チェーンはMicrosoftにさかのぼらないと書かれていますが、エラーは発生しません。
• カーネルモードドライバー署名ポリシー（カーネルモードドライバーに署名し/kpていないため、おそらく適用されません）は、署名チェーンがMicrosoftにトレースバックし、エラーが発生しないことを示しています。

WindowsがINFファイルに使用するポリシーを知っている人はいますか？それは少なくとも私が問題を絞り込むのに役立ちます。

これは、以下からの完全で詳細な出力ですsigntool verify。

ドライバーに署名したコンピューター（動作している場所）と他のコンピューター（動作していない場所）で実行した場合、出力は同じように見えました。

StackOverflowに関する同様の質問

64ビットWindows用のThawteドライバー署名-この男の問題の解決策は、CatalogFileディレクティブをINFファイルに追加することでしたが、私はすでにそれを持っています。（CatalogFile=pololu.cat）。

編集＃1：実行可能ファイルへの署名は機能します

実行可能ファイル（NSISインストーラー）に署名するために同じオプションでsigntoolを使用しましたが、両方のコンピューターで最初の試行で正しく機能しました。ですから、INFドライバファイルの署名ポリシーには何か違いがあると思います。それが私を困惑させているのです。

編集＃2：GoDaddyの証明書に関する警告

をダブルクリックするmscvr-cross-gdroot-g2.crtと、[全般]タブに「Windowsにはこの証明書を確認するための十分な情報がありません」と表示されます。[証明書のパス]タブの[証明書のステータス：]に、「この証明書の発行者が見つかりませんでした」と表示されます。gd_ms_drv_sign_bundle.p7b（GoDaddyの証明書バンドル）をダブルクリックして最初の証明書を開くと、同じ警告が表示されます。

これらの証明書の両方の発行者は、Microsoftコード検証ルートであると想定されています。その警告メッセージについて心配する必要がありますか？

編集＃3：GoDaddyの証明書の削除

GoDaddyの高度なサポートチームのLindsayが私に戻ってきました。彼女はglobalsignからこのページにリンクし、ドライバーに署名するコンピューター上のCAからルート証明書と中間証明書をアンインストールする方法を説明しています。Lindsayによると、この手順を実行しない場合、署名ツールはそれらの証明書が他のコンピューターに存在すると想定するため、署名に含まれません。

どの証明書が署名に「インポート」されているかを確認する方法を知っている人はいますか？LindsayとGlobalSignが正しいかどうかを確認するためにどのツールを使用できますか？

ちなみに、Windows XPコンピュータはありますが、MicrosoftはまもなくそのOSのサポートを停止します。GlobalSignが言っていることにもかかわらず、これをWindows7で機能させる方法が必要です。

Lindsayのアドバイスに基づいて、Microsoftの指示に従って、自動ルート認証局の更新をオフにし、のUIを使用して、certmgr.msc「信頼されたルート証明機関」と「中間証明機関」からすべてのGoDaddy証明書を削除しました。次に、infファイルに再署名しました。

残念ながら、それはうまくいきませんでした！署名後、すべてのGoDaddy証明書がまだ削除されていることを再確認しました。

signtool verifyの出力、または検証を行うときに確認する必要のあるドライバー署名ポリシーに関する入力について、GoDaddyからフィードバックを受け取っていません。私は、彼らが検証出力を見て、私が間違っていることを教えてくれるか、正しい出力がどのようになるかを教えてくれることを望んでいました。

完全を期すために、signtool verifyこれらの証明書を削除してドライバーに再署名した後の3つの出力を次に示します。

編集＃4：DefaultInstallセクションはノーノーです

MicrosoftのDefaultInstallセクションのドキュメントで、私はこれを発見しました。

注ドライバーパッケージをデジタル署名する場合は、ドライバー パッケージのINFファイルに INFDefaultInstallセクションを含めないでください。

なぜそれが本当なのか誰かが知っていますか？説明が見つかりませんでした。

とにかく、INFファイルのDefaultInstallセクションを取り出したので、これからは、SetupCopyOemInfを呼び出す小さなDLLを実行してテストする必要があります。

まだ運がない。WindowsVistaコンピューターで未確認の発行元の警告が表示され続けます。

編集＃5：JLinkドライバーは正しく署名されています

私はC：\ Windows \ System32 \ DriverStore \ FileRepositoryをざっと見て、適切に署名されたドライバーパッケージを見つけようとしていました。私が最初に見つけた興味深いものは、JLinkCDC.cat/JLinkCDC.infです。InfファイルのバージョンはですDriverVer=01/25/2012,6.0.2600.4。Windows Vistaマシンで、（DLLを使用して）infファイルでSetupCopyOemInfを呼び出すと、発行元が誰であるか（Segger GMBHなど）を通知する適切なメッセージが表示されます。したがって、私のようなドライバーパッケージに適切に署名することは可能ですが、どういうわけかGoDaddyまたは私は何か間違ったことをしています。

JLinkCDC.infドライバーは、1つのファイルであり、usbser.sysを使用するため、私のドライバーと非常によく似ています。署名の信頼チェーンは、VeriSign Class 3 Public Primary CertificateAuthority-G5に戻ります。

基本的に、このJLinkCDCドライバーは私のものと似ており、動作するので、違いが何であるかを注意深く調べる予定です。

JLinkCDC.catのsigntoolverifyの出力は、GoDaddyではなくVerisignにトレースバックすることを除いて、私のものと非常によく似ています。

編集＃6：マイナーな変更

ドライバーをJLinkCDC.infに近づけるDriverPackageType=PlugAndPlayために、INFファイルに追加し、ファイル名を短くしました。ファイルの名前はpolser.catおよびpolser.infになりました。まだ運がない！

編集＃7：いくつかの成功！

私は次のことが真実だと思います。私が間違っている場合は私を訂正してください：

• ドライバーパッケージ（.catファイル）の場合、の正しいオプションはsigntool verifyです/pa。これはKMCS_Walkthrough.docから推測します。
• ドライバーパッケージの場合、Windowsは、信頼の鎖がcertmgr.mscの[信頼されたルート証明機関]フォルダー内の証明書に戻った場合にのみ、発行元が検証されたと見なします。
• ドライバーパッケージの場合、相互証明書を使用して署名できます（gdroot-g2.crtからMicrosoftコード検証ルートへの信頼の鎖を拡張します）が、Windowsはそれを無視しているようです。これは、Microsoftコード検証ルートが「信頼されたルート証明機関」ではないためです。
• 現在のユーザーの証明書ストアとローカルマシンの証明書があります。どちらも重要なので、MMC証明書スナップインを使用して両方を表示する必要があります。Certmgr.mscは、現在のユーザーのもののみを表示します。
• Windowsは、必要に応じて「Go Daddyルート証明機関-G2」（gdroot-g2.crt）を「信頼されたルート証明機関」フォルダーに シームレスに追加し、Windows Updateからダウンロードする必要がありますが、そうではありません。詳細はこちら。

テストマシンのWindowsイベントビューアを使用して、何が起きているかを確認しました。Windowsは「GoDaddyRootCertificate Authority-G2」を自動的にフェッチするように見えますが、望ましくない未確認の発行者警告ダイアログが表示された後でのみです。ユーザーがそのダイアログを閉じるとすぐに、証明書がWindows Updateからフェッチされるため、次回のインストールは成功するはずです。興味深いことに、スターフィールド証明書（私のタイムスタンプの信頼の鎖のルート）をタイムリーに自動的にダウンロードします。

ドライバーをインストールする前に、gdroot-g2.crtをダブルクリックしてインポートすることにより、Windows7およびWindowsVistaコンピューターで機能するように署名を取得しました。このプロセスを自動化してインストーラーに追加できるかどうかを確認します。

「VeriSignClass3Public Primary Certification Authority-G5」に根ざした、VeriSign証明書で署名された別の会社（JLinkCDC.cat）のドライバーパッケージを見つけました。その証明書は私が調べたすべてのコンピューターにあるので、Go Daddyの代わりにVeriSignを使用すれば、WindowsUpdateでこの問題を回避できると思います。

VeriSign証明書がSHA1を使用しているのに対し、GoDaddy証明書は署名アルゴリズムと署名ハッシュアルゴリズムにSHA256を使用していることに気付きました。それが重要かどうかわからない。

編集＃8：マイクロソフトに助けを求めた

MSDNフォーラムでのディスカッションと私の結論を参照してください：http ：//social.msdn.microsoft.com/Forums/en-US/wdk/thread/1fede768-7925-4f30-8eef-ce5bd08b0b60

WiX RemotePayloadハッシュを解決しようとしていますが、CertificatePublicKey属性がどのように検出されるかわかりません。

たとえば、WiX3.6ソースからの.NET4.0パッケージ定義を取り上げます。

wix36から-sources\src \ ext \ NetFxExtension \ wixlib \ NetFx4.wxs

Hash私はsha1を見つけることができますfciv -sha1 dotNetFx40_Full_x86_x64.exe...

58da3d74db353aad03588cbb5cea8234166d8b99 dotnetfx40_full_x86_x64.exe

CertificateThumbprintファイルのプロパティダイアログを使用するかsigntool、次の出力を表示するを使用して、一致するものを簡単に見つけることができます

どのツールがハッシュを提供できますCertificatePublicKeyか？

編集：熱を使わずに、ハッシュがどこから来ているのかを理解したいと思います。

編集：これがWiXソースコードでどのように行われ、実行できるかは知って
heat payload file -out file.wxsいますが、熱を使用せずに期待されるハッシュを提供できる外部ツールを探しています。これは本当に私の好奇心を満足させるためだけのものです。

Authenticode コード署名証明書をビルド サーバーに直接インストールして、実稼働署名済みビルドを作成することは許容されますか? ビルド サーバーと、ビルドを作成および展開するプロセスを保護するための適切な手順を実行した場合に、この慣行が正当であることを示唆またはサポートするネット上のリソースを探しています。

コード署名の実践に関して私が見つけることができるすべての「ベスト プラクティス」のガイダンスは、提案されたプロセスの点で非常に優れています。Microsoft のリファレンス ドキュメントには、単一のアセンブリに署名するという単純な行為のために、6 台ものサーバーが使用されています。 http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc

背景:

私の会社では、従業員と直接の顧客向けに、単純なリッチクライアント基幹業務アプリケーションを作成しています。私たちは商用ソフトウェアを作成しません。私のビルド サーバーは、会社の厳格なセキュリティ ポリシーと手順を使用して、物理的にセキュリティで保護され、ネットワークでセキュリティで保護されています。私の環境でビルドを開始することさえできるのは、組織内の非常に特定の人だけです。

現在のプロセスでは、ビルド/デプロイ プロセスを多くの段階に分割し、多くの手動プロセスを実施する必要があります。物理デバイスを使用して Authenticode 証明書を保存し、アクセスするにはユーザーが入力した PIN を必要とします。コード署名が必要なアセンブリ/マニフェストを、物理的に保護する必要がある指定されたコード署名 PC にシャッフルする必要があります。

私にとって、物理的なトークン/デバイスを渡して、これらすべての手動の​​手順をそのままにしておくのは安全ではありません. トークン/デバイスに物理的にアクセスできる人が、必要なものに署名することを妨げるものは何もありません。少なくとも、自動化され、ログに記録され、制御されたビルド サーバー環境があれば、誰が何に署名したかがわかります。

ソフトウェア アプリケーションを開発し、Verisign (現在の Symantec) から取得した Authenticode 証明書を使用してインストーラーにデジタル署名しました。Visual Studio に付属の signtool.exe ユーティリティを使用して、インストーラー (.exe) に署名しました。インストーラーを実行すると、私の目的であった「不明」ではなく、発行元として私の会社名が表示されるようになりました....成功!

次に、インストーラー ファイルを自分の Web サイトに投稿して、顧客に配布しました。このファイルは、クリックすると次のコードを実行する asp:button によって提供されます。

Web サイトからインストーラー ファイルをダウンロードして実行すると、発行元フィールドに「不明」と表示されます!!! 次に、FTPクライアントを使用してファイルをWebサーバーからコンピューターに直接コピーしましたが、ダウンロードしたファイルには署名がありました（つまり、発行者が表示されませんでした：不明）、明らかにWebサーバー上のファイルは問題ありません。デジタル署名を削除または無効にする Web サイト経由でファイルをダウンロードするプロセスに関するものに違いありません。Firefox と IE の両方を試しましたが、同じ結果が得られました。

私は何を間違っていますか？よろしくお願いいたします。

opensslをインストールしましたが、rsa_test.cは正常に動作しています。私がやりたいことは次のとおりです。

1. exe または dll デジタル証明書を開きます。拇印とPublicKeyを抽出します。公開鍵には指数も含まれています (ASN1 エンコーディングに精通している場合)。

2. これで、ファイルのSHA-1ハッシュを計算し、それを MD フィールドと比較して正しいことがわかりました。そのため、Thumbprint、PublicKey->mおよびPublicKey->eをRSA_public_decrypt関数に渡して、ファイルの復号化されたSHA-1ハッシュを計算します。

どのパディング アルゴリズムを関数に渡す必要がありますか? RSA_NO_PADDINGを渡すと、復号化されますが、まったく正しくない 128 バイトの長さのハッシュが返されます。他のすべてのパディング アルゴリズム オプションでは、パディングが見つからないというエラーが返されます。

例または例への適切なリンクを使用して、関数を通過するための正しいパラメーターを教えてください。

外部 DLL (一種のプラグイン システム) をロードするプロセスがあり、ロードされた DLL が Authenticode を使用して正しく署名されていることを確認します。WinVerifyTrustとLoadLibrary (およびその仲間)のドキュメントを熟読した後、私が重要だと思ったことの 1 つは、両方の操作がファイル パスから DLL まで機能することです。

これを悪用して、署名された DLL をプログラムに提示し、呼び出しが実行されるWinVerifyTrust()前に署名されていないコードですぐに DLL を置き換えることで、プログラムに署名されていない DLL をロードさせることは非常に実行可能であると思われます(これはLoadLibrary()ハードな競合状態ですが、たとえばネットワーク化されたファイル システムを使用している場合など、攻撃者がファイル システムをある程度制御できる場合は、より適切に制御できます)。

API forWinVerifyTrust()は、開いているファイルへのハンドルで検証プロセスを実行できることを示唆しているようです。ファイルを開くことができ、開いているファイル ハンドルを確認し、同じファイル ハンドルからライブラリをロードできれば、安全です。残念ながらLoadLibraryEx()、これを実装するための私の主な容疑者だったでしょうが、そのhFileパラメーターを「将来の使用のために予約済み」として文書化しています。

私の次の手段は、ファイルの内容をメモリにロードしてから、メモリから DLL をロードすることでした。これを行うライブラリMemoryModuleを見つけました。これらすべてを組み合わせて、開発者が DLL を安全に検証してロードできるようにする既存の実装があるかどうか疑問に思っていました。つまり、自分で記述して保守する必要はありません。

助言がありますか？

大丈夫、私は何か正しいことをしていないので、助けが必要です。何が起こっているかは次のとおりです。

1. 支払ったComodoからの「本物の」Authenticode 証明書を持っています。
2. Visual Studio 2012 および .NET 4.5 で記述された WPF アプリケーションに署名して展開しようとしています。
3. プロジェクトのプロパティで、「ClickOnce マニフェストに署名する」をチェックし、証明書を選択しました。
4. Comodo のタイムスタンプ サーバー ( http://timestamp.comodoca.com/authenticode )も使用しています。
5. [公開] タブと [前提条件] ボタンの下で、[前提条件コンポーネントをインストールするためのセットアップ プログラムを作成する] をオンにしました。

ビルドして公開すると、すべてが機能します。setup.exe は私の Comodo 証明書で署名されているので、問題ありません。また、.applicationファイルは Comodo 証明書で署名されており、私の会社名が発行元として表示されます。これも良いことです。

ここで問題が発生します。アプリケーションがクライアントにダウンロードされると、Windows 8 は信頼できないプログラム (MyProgram.exe) に関する警告をスローし、発行元は私の会社名ではありません。したがって、実際の実行可能ファイルを除いて、すべてが署名されています。

signtool.exe を使用するビルド後のスクリプトを obj\Release\MyProgram.exe に追加しようとしましたが、アプリケーションをインストールしようとすると、ハッシュ値が一致しないというマニフェスト エラーが表示されます。つまり、ビルド後のイベントの前にマニフェストが生成されます。

.exe に署名し、ClickOnce マニフェストの整合性を維持するにはどうすればよいですか? これを行う簡単な方法はありますか、それともすべてのファイルで手動で mage.exe を使用する必要がありますか?

私のコード署名証明書は3/3/12から3/3/13まで有効です（Comodo）

1. 更新すると、新しい証明書（.pfxファイル）が発行されますか？または、料金を支払った後、2013年3月3日以降に現在の証明書（.pfxファイル）を使用できますか？

2. 新しい証明書でexeとセットアップに署名しない場合、または新しい証明書を購入しない場合、既存の署名済みアプリケーションは、2013年3月3日以降のインストール/実行中に「未確認の発行元」またはその他のエラーを表示しますか？私はすべてのdll、ソフトウェアのexe、および最終セットアップexeに署名することに注意してください

3. 更新時に新しい.snkファイルを取得する必要がありますか、それとも既存の.snkファイルを使用できますか？

4. 同じ.snkファイルを使用して別のソフトウェアとそのセットアップファイルに署名できますか？と異なるexe、同じセットアップのdll？.snkファイルは1つのexeに関連付けられていますか？または、任意のexe（.NETとVB6の両方）で使用できますか？

Windows 8 Pro + Visual Studio 6 SP6 + Visual Studio 2012 Ultimate + Microsoft8SDKスタンドアロンインストールがあります

私の質問は、.NET アセンブリ間のセキュリティの強化に関するものです。そして、ここにシナリオがあります：

• Foundationアセンブリがサーバーに展開されます。
• 一連のプラグインアセンブリがアプリケーションに同梱されています。
• プラグインはFoundationの機能を使用します。
• Foundationは機密性の高い操作とデータを提供するため、プラグイン(呼び出し元アセンブリ) が本物であり、特定の発行元からのものであることを確認する必要があります。

私はセキュリティにかなり慣れていないので、厳密な名前付けとデジタル署名の基本を理解しています。したがって、上記の目標を達成するための可能な方法を完全に説明していただければ幸いです。

http://www.ksoftware.net/から証明書を購入しました。この証明書を使用して、Windows Mobile 6.5 デバイスにソフトウェアをインストールするために使用する .CAB ファイルに署名します。ただし、.CAB に署名した後でも、(CAB 経由で) デバイスにアプリケーションをインストールしようとすると、デバイスは「不明な発行元」を警告します。これらの CAB ファイルは Web サービスからダウンロードされ、wceload とそのサイレント インストール オプションを使用して自動的にインストールされるはずですが、CAB が署名されていると認識されないため失敗します (特定の CAB ファイルを手動でインストールすると、wceload は成功します)。将来的には CAB)。

最初は、Visual Studio 2008 の展開プロパティとアプリケーション署名プロパティに設定された証明書のみがありました。また、signtool.exe を使用してみました。その後、cabsigntool.exe を使用して、CAB 内の他のすべてのファイルにも署名しました。これらの方法はどれも機能しません。Windows 7 で CAB のプロパティを確認すると、ファイルにはセキュリティ証明書が添付されていますが、デバイスにインストールしようとすると、煩わしい「不明な発行元」ポップアップ ボックスが表示されます。

不足しているものはありますか？デバイスでまだ CAB ファイルが署名されていないと見なされる原因は何ですか? 署名は、プレーンなexeでも機能しないようです。

プロンプトが表示されないようにセキュリティ設定を変更できることは知っていますが、セキュリティ証明書の問題を解決したいと考えています。