"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 from file:/FILEPATH: 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.

To solve this, we ended up using another certificate file, and it worked fine (resigned the manifest).

But we can not understand why it would work to install the application in the developers machines (even developers that were not working with the application), but it would not work for the clients' machines?

We don't have much information on how the certificates were created or the ClickOnce package, because the person that did it is gone and didn't leave documentation about it.

The certificate that was being used didn't have a password and normal users do not have administrator rights.

From Stack Overflow question Manifest XML signature is not valid, I could guess that the problem maybe was that they created the project and certificate with .NET Framework 4.5 and then when they set the application to run with .NET Framework 4.0, they didn't change the signature algorithm. But then I would asume it shouldn't work for the developers either.

Any insight you could give me would be greatly appreciated.

Answer 1

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.

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!