“Manifest XML signature is not valid” on client machine but works fine on developer computer

Question

At work we had a ClickOnce application that, when the client would try to install, was throwing the exception:

• Exception reading manifest f

Answer 1

We also faced similar issue in following scenario.

We simply migrated from vs2008 to vs2013-update 5.

Our clickonce app is on .net 3.5.

After this, our clickonce app build using nant script on command prompt was giving same error "Manifest XML signature is not valid" on a machine which is having .net framework version older than 4.5.

As we were using vs2013-update 5, it was obviously not related to fix done in vs2013-update 3.

After doing trial and error on one sample app, we sorted it out that mage.exe which we are using to resign the manifest after updating manifest. When we create setup using VS2013 developer command prompt, it uses mage.exe which is installed with VS2013 and it is not having the same fix which is done in VS2013 update 3. Using old mage.exe, installed with vs2008 (normally located at "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin") solved our problem.

Answer 2

We had similar problem - we have a .NET 4.0 application, meant to work on machines with .NET 4.0 or higher. As our code signing certificate expired we purchased a new one and as Sha1 is going to be depricated, we received a Sha256 one. I should say that our build machine has .NET 4.5 installed, so the framework assemblies are all updated on that machine.

We noticed that the following error started to appear only on .NET 4.0 machines once we migrated to the new certificate:

* 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.

After a little research fe found out this thread and some other, suggesting upgrading to .NET 4.5, but this is not working solution for us - we don't want to force our clients to update .NET framework (~20% are still using .NET 4.0). Here are the solutions we came up to:

• Sign the manifests on a machine that has only .NET 4.0 installed
• Sign with the following PowerShell script instead of using mage.exe:

function SignFile($filePath, $timeStampUri, $certThumbprint)
{
    #Add-Type System.Security

    $x509Store = New-Object -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]

            # This will force using of SHA1 instead of SHA256
            $cert.SignatureAlgorithm.FriendlyName = ""

            Add-Type -AssemblyName "Microsoft.Build.Tasks.v4.0"

            [Microsoft.Build.Tasks.Deployment.ManifestUtilities.SecurityUtilities]::SignFile($cert, $timeStampUri, $filePath)
        }
    }
    finally
    {
        $x509Store.Close();
    }
}

EDIT: I actually use this command-let to sign the manifest files: https://gist.github.com/nedyalkov/a563dd4fb04d21cb91dc

Hope this information will save time and effort to somebody!

Answer 3

Update: This is fixed as of Visual Studio 2013 Update 3. Try publishing your app from that version of VS or later.

Previous answer:

It's because your developer machine had .NET 4.5 installed, while your client machines only had .NET 4.0 installed. The .NET 4.0 client machines can't read the manifest, as they expect SHA-1, while the .NET 4.5 developer machines can.

See this blog post for some additional context.

This change is due to the fact that we stopped using legacy certificates as default (SHA-1) in NetFX4.5 to sign manifest and instead, use newer version (SHA-256), which is not recognized by NetFx4.0 runtime. Therefore, while parsing the manifest, 4.0 runtime complains of an invalid manifest. For legacy frameworks, when we try to run a ClickOnce app on a box that does not have targeted runtime, ClickOnce pops up a message to user saying “you need xxxx.xx runtime to run this app”. But starting .NET 4.5, if a 4.5 ClickOnce app is run on the box with only .NET 4.0 installed, the message complains about an invalid manifest. In order to resolve the issue, you must install .Net Framework 4.5 on the target system.

Try signing your manifest with a SHA-1 certificate instead of a SHA-2 certificate.