web-dev-qa-db-ja.com

クライアントマシンでは「マニフェストXML署名が無効です」が、開発者のコ​​ンピューターでは正常に機能する

職場では、クライアントがインストールしようとすると例外がスローされるClickOnceアプリケーションがありました。

  • File:/ FILEPATHからのマニフェストの読み取りの例外:マニフェストが無効であるか、ファイルを開けませんでした。

    マニフェストXML署名が無効です。

    指定された署名アルゴリズムのSignatureDescriptionを作成できませんでした。

これを解決するために、別の証明書ファイルを使用することになり、うまく機能しました(マニフェストを辞任しました)。

しかし、なぜアプリケーションを開発者のマシンにインストールするとうまくいくのか(アプリケーションを操作していない開発者でさえ)理解できませんが、クライアントのマシンではうまくいきませんか?

証明書の作成方法やClickOnceパッケージに関する情報はあまりありません。証明書を作成した人が亡くなり、それに関するドキュメントを残していないためです。

使用されていた証明書にはパスワードがなく、通常のユーザーには管理者権限がありません。

スタックオーバーフローの質問マニフェストXML署名が無効ですから、問題はおそらく彼らがプロジェクトを作成したことであり、 。NET Framework 4.5を含む証明書。その後、.NET Framework 4.0で実行するようにアプリケーションを設定しても、署名アルゴリズムは変更されませんでした。しかし、それでも私はそれが開発者にとっても機能しないはずだと思います。

あなたが私に与えることができるどんな洞察も大いに感謝されます。

24
Dzyann

更新:これはVisual Studio 2013 Update 3以降で修正されています。そのバージョン以降のVS以降からアプリを公開してみてください。

以前の答え:

これは、クライアントマシンに.NET 4.0のみがインストールされていたのに対し、開発者マシンには.NET 4.5がインストールされていたためです。 .NET 4.0クライアントマシンはSHA-1を期待しているため、マニフェストを読み取ることができません。

追加のコンテキストについては このブログ投稿 を参照してください。

この変更は、マニフェストに署名するためにNetFX4.5でレガシー証明書(SHA-1)をデフォルトとして使用するのをやめ、代わりに、NetFx4.0ランタイムで認識されない新しいバージョン(SHA-256)を使用するためです。したがって、マニフェストの解析中に、4.0ランタイムは無効なマニフェストを報告します。レガシーフレームワークの場合、ターゲットランタイムを持たないボックスでClickOnceアプリを実行しようとすると、ClickOnceは「このアプリを実行するにはxxxx.xxランタイムが必要です」というメッセージをユーザーにポップアップします。ただし、.NET 4.5以降では、.NET 4.0のみがインストールされているボックスで4.5 ClickOnceアプリを実行すると、無効なマニフェストについてメッセージが表示されます。この問題を解決するには、ターゲットシステムに.Net Framework 4.5をインストールする必要があります。

SHA-2証明書ではなくSHA-1証明書でマニフェストに署名してみてください。

26
Matthew King

同様の問題がありました。NET4.0アプリケーションがあり、.NET 4.0以降のマシンで動作するようになっています。コード署名証明書の有効期限が切れたため、新しい証明書を購入しました。Sha1が値下げされるため、Sha256証明書を受け取りました。ビルドマシンには.NET 4.5がインストールされているので、フレームワークアセンブリはすべてそのマシンで更新されます。

新しい証明書に移行した後、.NET 4.0マシンでのみ次のエラーが発生し始めたことに気付きました。

* Activation of http://localhost/publish/Test.application resulted in exception. Following failure messages were detected:
    + Exception reading manifest from http://localhost/publish/Test.application: the manifest may not be valid or the file could not be opened.
    + Manifest XML signature is not valid.
    + SignatureDescription could not be created for the signature algorithm supplied.

少し調査した後、このスレッドや他のスレッドを見つけて、.NET 4.5へのアップグレードを提案しましたが、これは私たちにとって有効な解決策ではありません-クライアントに.NETフレームワークの更新を強制したくない(〜20%はまだ.NET 4.0)。ここに私たちが思いついた解決策があります:

  • .NET 4.0のみがインストールされているマシンでマニフェストに署名する
  • Mage.exeを使用する代わりに、次のPowerShellスクリプトで署名します。
 function SignFile($ filePath、$ timeStampUri、$ certThumbprint)
 {
#Add-Type System.Security 
 
 $ x509Store = New-オブジェクト-TypeName([System.Security.Cryptography.X509Certificates.X509Store])-ArgumentList([System.Security.Cryptography.X509Certificates.StoreName] :: My)、([System.Security.Cryptography.X509Certificates.StoreLocation] :: CurrentUser )
 try 
 {
 $ x509Store.Open([System.Security.Cryptography.X509Certificates.OpenFlags] :: ReadOnly)
 $ x509Certificate2Collection = $ x509Store.Certificates .Find([System.Security.Cryptography.X509Certificates.X509FindType] :: FindByThumbprint、$ certThumbprint、$ false); 
 if($ x509Certificate2Collection.Count -eq 1)
 {
 $ cert = [System.Security.Cryptography.X509Certificates.X509Certificate2] @($ x509Certificate2Collection)[0] 
 
#これにより、SHA256の代わりにSHA1が強制的に使用されます
 $ cert .Signa tureAlgorithm.FriendlyName = "" 
 
 Add-Type -AssemblyName "Microsoft.Build.Tasks.v4.0" 
 
 [Microsoft.Build.Tasks.Deployment .ManifestUtilities.SecurityUtilities] :: SignFile($ cert、$ timeStampUri、$ filePath)
} 
} 
最後に
 {
 $ x509Store。 Close(); 
} 
} 

EDIT:実際にこのコマンドレットを使用してマニフェストに署名しますファイル:https://Gist.github.com/nedyalkov/a563dd4fb04d21cb91dc

この情報が誰かの時間と労力を節約してくれることを願っています!

13

以下のシナリオでも同様の問題に直面しました。

単にvs2008からvs2013-update 5に移行しました。

Clickonceアプリは.net 3.5にあります。

この後、コマンドプロンプトでnantスクリプトを使用してクリックオンスアプリをビルドすると、4.5より古い.netフレームワークのバージョンを使用しているマシンで同じエラー「マニフェストXML署名が無効です」が発生しました。

Vs2013-update 5を使用していたため、vs2013-update 3で行われた修正とは明らかに関係がありませんでした。

1つのサンプルアプリで試行錯誤を繰り返した後、マニフェストを更新した後、マニフェストを再署名するために使用しているmage.exeを整理しました。 VS2013開発者コマンドプロンプトを使用してセットアップを作成すると、VS2013でインストールされるmage.exeが使用され、VS2013アップデート3で行われるのと同じ修正が行われません。vs2008でインストールされる古いmage.exeを使用します(通常は「 C:\ Program Files(x86)\ Microsoft SDKs\Windows\v7.0A\Bin ")が問題を解決しました。

0
rikencpatel