Click Once signing manifests with custom certificate

[Former Member]

Hi!

I am publishing a ClickOnce application with a custom certificate which was provided by my company specifically for this application. This application has Crystal Reports as a prerequisite (amongst other things).

This custom certificate only has the "Code Signing" Intented Purpose, which would not be a problem (Click Once certificate is there to sign code after all) if I did not run into a specific issue when trying to install the whole Click Once deploy (prerequisites are deployed along with the ClickOnce application as can be chosen in Visual Studio) on a freshly installed Windows 7 Ultimate virtual machine. The ClickOnce error log shows this:

Copying from '

tinf-w7-10ClickToMRWPublicación2.5.2.10.OldPRECrystalReports 12.3CRRuntime_12_3_mlb.msi' to 'C:Usersctm-3AppDataLocalTempVSD3208.tmpCrystalReports 12.3CRRuntime_12_3_mlb.msi'

Verifying file integrity of C:Usersctm-3AppDataLocalTempVSD3208.tmpCrystalReports 12.3CRRuntime_12_3_mlb.msi

WinVerifyTrust returned -2146762487

File not trusted

Error: Setup has detected that the publisher of file 'C:Usersctm-3AppDataLocalTempVSD3208.tmpCrystalReports 12.3CRRuntime_12_3_mlb.msi' cannot be verified.

Now I did some searching about this issue, and came up with the general idea that this is due to the conjonction of several factors:

1. the use of a 64 bit OS: the exact same setup on Windows XP 32 works. It seems somehow 64 bit Windows is less permissive with executable signatures.

2. the use for ClickOnce deployment of a certificate limited to the Code Signing Intended Purpose: if I use a certificate generated by Visual Studio (those ones have all purposes activated by default), it works. And if I limit this newly created certificate to Code Signing, I have the same problem than with the certificate my company provided.

3. a signing problem with the Crystal Reports redistributable: if I exclude this prerequisite from my ClickOnce project, the deploy installs fine (including other prerequisites). Then if I install the CRRuntime_12_3_mlb.msi separately, the application works.

I want to make clear here that at no point did I modify the Crystal Reports msi file. It seems that somehow, prerequisite files are validated by ClickOnce with the certificate used to sign ClickOnce manifests OR the certificate used to sign the prerequisite file itself. When both fail, the prerequisite will not install.

Other things that I checked:

- my custom certificate is date-valid (until 2013).

- all machine validated the certification path of the custom certificate I use: the root certificate of my company belong to both virtual and dev machines's CA certificate repository.

- I checked this with several versions of .net 3.5-dependent Crystal Reports runtimes. That is the CR2008SP3 FP3.3 ClickOnce zip file, the CR2008SP3 FP3.3 Redist used with Bootstrapper Manifest generator, the Crystal Report Basic for Visual Studio 2008 Redist...

It seems that somehow the certificating path of the Crystal Report files do not validate on a standard 64 bit Windows installation. I checked the certificates and they look like this:

Signer information:

Issued to: Business Objects America

Issued by: Thawte Code Signing SA

Valid from 22/01/2009 to 23/01/2011

Countersignature:

Issued to: VeriSign Time Stamping Services Signer - G2

Issued from: Verisign Time Stamping Services CA

Valid from 16/06/2007 to 15/06/2012

Could it be that somehow one of these two certificates causes my problem?

[former_member183750 · Accepted solution]

The certificate for the SP3 click-once MSI expired Jan22... and I know this is going to be an issue since it is not easy to get new keys through SAP (don't ask...).

Now, the MSI will install directly if downloaded and clicked on, so I wonder if its possible to remove the u201CPublicKeyu201D attribute from the <PackageFileu2026./> tag in product.xml so it doesnu2019t verify. Iu2019ve never tried it. Can you give it a test as a possible workaround?

- Ludek

[Former Member]

My first guess is yes - that the certificate Issued to: Business Objects America - is the one causing the problem.

Another note;

Regarding BO XI 3.1 .. ServicePack2 and SP3 also have this expire dates; Valid from 22/01/2009 to 23/01/2011

This causes the users to have to "trust the publisher..." or you might try to add the site to "trusted sites" in IE and see if this solves your problem ?

All in all.. I'm guessing SAP has to create a new certificate.