Signing ClickOnce Manifests Using Certificate Chains and Thawte

Question

I have a problem that is proving a bit tricky to sort out, can anyone help ?

 

I have a Thawte code signing certificate, and I am trying to use it to sign a .Net project for ClickOnce deployment - actually to sign the ClickOnce Manifest using the 'Signing' options in Visual Studio (VS 2005 vn 8.0.50727.762).

 

For code signing Thawte use an intermediate level cert - my certificate is chained to a Thawte root certificate via the 'Thawte Code Signing CA' certificate.

 

Unfortunately (for whatever reason) the intermediate certificate is not included in the set installed automatically by Windows / Windows Update.

 

The full certificate chain is available on the machine that I am using to build and sign the project - so the signing process is successful - also, if you run ClickOnce installation on that same machine everything work - the first installation dialog says all is ok - and you can check the publisher's cert details - everything is valid.

 

However, if I try to install the application on a fresh machine there is a problem - this machine does not have the Thawte intermediate certificate installed by default.

 

The normal way of dealing with this type of problem is to make sure that the Certificate used to sign the code includes the full certificate chain - which then provides the 'missing link' to the root. The certificate I am using does include this chain - I can verify this by exporting it and importing it elsewhere. I can also use other signing utilities successfully.

 

However, as far as I can tell - although I am not sure - there is a strange twist when signing ClickOnce manifests in Visual Studio. It looks to me as if there may be two types of 'code signing' going on, one a 'normal' authenticode type signing and another xml signature of the manifest, that are working inconsistently.

 

If I configure Visual Studio project to 'Sign the ClickOnce manifests', and then move the installation files to another machine - and then (right) click on the 'setup.exe' file icon, and look at 'digital signatures' - then the signature seen here is valid - and I can see a complete certificate chain.

 

However, if I now double click on 'setup.exe' to install the application, and then check the signature from the next dialog - here the signature is not valid and the certificate chain is broken.

 

One strange possibility is that the manifest xml signature is not including the intermediate cert information, but a-n-other signature on the setup file is including it. Otherwise I find this very hard to explain.

 

I would not expect clients to have to manually install the missing intermediate certificate, and it is not included in Windows Update, which leaves me struggling to see a solution.

 

I know that I am including the full cert chain when I sign the application, but for whatever reason the intermediate cert is being 'seen' from within the setup file's properties dialog, but not when it then comes to run the application installation and validate the publisher.

 

Has anyone any informed suggestions ?

 

Thanks,

 

Andrew.

 

 

 

Answer 1

I have the exact same problem with Thawte, and from what I see on the web this is a general problem with intermediate certificates and visual studio.
I'm using Visual Studio 2008 SP1 and this is still happening. Is there anything I can do appart from making all my clients install the intermediate code signing certificate??

Thanks

Answer 2

I've posted an answer to this in the following thread. I thought when I got the info from the dev at Microsoft, I responded to this thread, but I must not have. Sorry about that. (Too much work, too little time.)

http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/13876bb8-7dbb-4df1-93f8-70ff467ffd4b

RobinDotNet

---

Click here to visit my ClickOnce blog!

Answer 3

We have a Windows Forms application which we are attempting to deploy and sign in VS 2012 with a authenticode code signing cert from Thawte and we see exactly the same problem as stated by the poster. We're hoping to have better luck with a cert from Verisign. 

Answer 4

If it makes you feel any better, we use Verisign, and don't have the intermediate-certificate problem.

RobinDotNet

---

Click here to visit my ClickOnce blog!
Microsoft MVP, Client App Dev