clickonce - valido - “La firma XML de manifiesto no es válida” en la máquina cliente pero funciona bien en la computadora del desarrollador

xades epes php

Question

En el trabajo teníamos una aplicación ClickOnce que, cuando el cliente intentaba instalar, lanzaba la excepción:

• Excepción de lectura del manifiesto del archivo: / FILEPATH: es posible que el manifiesto no sea válido o que el archivo no pueda abrirse.

  La firma XML del manifiesto no es válida.

  SignatureDescription no se pudo crear para el algoritmo de firma proporcionado.

Para resolver esto, terminamos usando otro archivo de certificado, y funcionó bien (renunció al manifiesto).

¿Pero no podemos entender por qué funcionaría instalar la aplicación en las máquinas de los desarrolladores (incluso los desarrolladores que no estaban trabajando con la aplicación), pero no funcionaría para las máquinas de los clientes?

No tenemos mucha información sobre cómo se crearon los certificados ni sobre el paquete ClickOnce, porque la persona que lo hizo desapareció y no dejó documentación al respecto.

El certificado que se estaba utilizando no tenía una contraseña y los usuarios normales no tienen derechos de administrador.

De la pregunta sobre el desbordamiento de la pila La firma XML del manifiesto no es válida , puedo suponer que el problema tal vez fue que crearon el proyecto y el certificado con .NET Framework 4.5 y luego, cuando configuraron la aplicación para que se ejecute con .NET Framework 4.0, no lo hicieron. cambiar el algoritmo de firma. Pero entonces supongo que tampoco debería funcionar para los desarrolladores.

Cualquier idea que me puedas dar sería muy apreciada.

Answer 1

También nos enfrentamos a un problema similar en el siguiente escenario.

Simplemente migramos de vs2008 a vs2013-actualización 5.

Nuestra aplicación Clickonce está en .net 3.5.

Después de esto, nuestra compilación de aplicaciones Clickonce utilizando el script nant en el símbolo del sistema emitía el mismo error "La firma XML de manifiesto no es válida" en una máquina que tiene una versión de .net framework anterior a 4.5.

Como estábamos usando vs2013-update 5, obviamente no estaba relacionado con la corrección realizada en vs2013-update 3.

Después de realizar una prueba y error en una aplicación de muestra, ordenamos ese mage.exe que estamos usando para renunciar al manifiesto después de actualizar el manifiesto. Cuando creamos la configuración utilizando el indicador de comando del desarrollador VS2013, usa mage.exe que se instala con VS2013 y no tiene la misma solución que se realiza en la actualización 3 de VS2013. Usando el antiguo mage.exe, instalado con vs2008 (normalmente ubicado en " C: / Archivos de programa (x86) / Microsoft SDKs / Windows / v7.0A / Bin ") resolvió nuestro problema.

Answer 2

Tuvimos un problema similar: tenemos una aplicación .NET 4.0, destinada a trabajar en máquinas con .NET 4.0 o superior. Cuando nuestro certificado de firma de código expiró, compramos uno nuevo y, como Sha1 va a ser menospreciado, recibimos uno Sha256. Debo decir que nuestra máquina de compilación tiene .NET 4.5 instalado, por lo que los ensamblajes de la estructura se actualizan en esa máquina.

Notamos que el siguiente error comenzó a aparecer solo en las máquinas .NET 4.0 una vez que migramos al nuevo certificado:

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

Después de una pequeña investigación, descubrí este hilo y algunos otros, lo que sugiere una actualización a .NET 4.5, pero esta no es una solución que funcione, no queremos obligar a nuestros clientes a actualizar el marco .NET (aproximadamente el 20% sigue utilizando .NET 4.0). Aquí están las soluciones que encontramos:

• Firme los manifiestos en una máquina que solo tiene .NET 4.0 instalado
• Firme con el siguiente script de PowerShell en lugar de usar 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(); } }

EDITAR: Realmente utilizo este comando -demitir para firmar los archivos de manifiesto: https://gist.github.com/nedyalkov/a563dd4fb04d21cb91dc

Espero que esta información le ahorre tiempo y esfuerzo a alguien!

Answer 3

Actualización: esto se solucionó a partir de la actualización 3 de Visual Studio 2013. Intente publicar su aplicación desde esa versión de VS o posterior.

Respuesta anterior:

Es porque su máquina de desarrollador tenía instalado .NET 4.5, mientras que las máquinas de sus clientes solo tenían instalado .NET 4.0. Las máquinas cliente .NET 4.0 no pueden leer el manifiesto, ya que esperan SHA-1, mientras que las máquinas desarrolladoras .NET 4.5 pueden.

Ver esta entrada de blog para un contexto adicional.

Este cambio se debe al hecho de que dejamos de usar certificados heredados como predeterminados (SHA-1) en NetFX4.5 para firmar el manifiesto y, en su lugar, usar una versión más nueva (SHA-256), que no es reconocida por el tiempo de ejecución de NetFx4.0. Por lo tanto, al analizar el manifiesto, 4.0 runtime se queja de un manifiesto no válido. Para los marcos heredados, cuando intentamos ejecutar una aplicación ClickOnce en un cuadro que no tiene un tiempo de ejecución específico, ClickOnce muestra un mensaje al usuario que dice "necesita el tiempo de ejecución xxxx.xx para ejecutar esta aplicación". Pero iniciando .NET 4.5, si se ejecuta una aplicación 4.5 ClickOnce en el cuadro con solo .NET 4.0 instalado, el mensaje se queja de un manifiesto no válido. Para resolver el problema, debe instalar .Net Framework 4.5 en el sistema de destino.

Intente firmar su manifiesto con un certificado SHA-1 en lugar de un certificado SHA-2.