For the past 22 months, we’ve been publishing using ClickOnce to the same path, using the same certificate, with no problems. This week, problems found us:
C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets (3652,9): error MSB3482: An error occurred while signing: Failed to sign
. SignTool Error: The signer’s certificate is not valid for signing. SignTool Error: An error occurred while attempting to sign:
The usual problem here is an expired certificate, but the certificate we’re using was created in December 2010 and expired in year 2039, so we knew expiration wasn’t a problem. The certificate file itself was also known to be valid; it was stored in our Subversion repository and hadn’t changed since the day it was created.
We called Microsoft (free support using our MSDN subscription). We spent about four hours working with them, creating test certificates, creating new certificates, trying to publish, with mixed and inconsistent results. We were told to use a new certificate because our current certificate was deemed corrupt. (When I asked what corrupt means, I was told it means the certificate file is bad. When I said that the MD5 hash of the certificate file was identical to the MD5 hash of the file created nearly two years ago and that it was stored in source control, I was told it was “bad” not corrupt. Semantics. Whatever.)
I seem to have fixed the problem this morning. It wasn’t the certificate. It wasn’t the path. Frankly, I don’t know what it is. I only know what steps I took before the point in which everything started publishing normally, as it had for the past 22 months.
Here’s what I did: I verified that every project in the solution has the same target platform (x86), .Net Framework version (3.5), and correct assembly information (some had default copyright information, some had autogenerated version numbers where we expected 220.127.116.11). After doing that and rebuilding, the ClickOnce publish worked as it did before, with the same old certificate, and clients behaved as expected (upgrading according to ClickOnce settings).
It makes no sense, because none of those settings were changed from our last good ClickOnce publish. Either way, it fixed the problem. Hopefully, it’ll help fix yours, if and when this annoying problem comes up.
0 thoughts on “Solved: ClickOnce publish failing with a valid certificate”
DJ Bodnar says:
This is a very timely article.
Yesterday I attempted publishing an application I have been publishing for 5 years and ran into the same error, with my certificate also expiring in 2039.
Unfortunately, your fix did not work for me.
I was trying to avoid creating a new certificate for 2 reasons.
1. my certificate is not expired; therefore, not the cause of this problem.
2. Every time I have had to change my publish location, certificates have seemed to cause me problems.
Interesting. We had the same problem and found it was related to a MS patch (KB2661254) which prevents certificates with keys < 1024 bits. Our certificate is 1024 bits but it still complained and broke the build. I don't suppose your fix might have been related to that?
First off, I’ve had some exposure to SSL, digital certificates, CA, and so on, but not a lot.
We’re experiencing the same thing it seems. I’ve followed the instructions here: http://blogs.msdn.com/b/rextang/archive/2009/01/27/9377001.aspx and ended with a self-signing CA, server certificate and exported PFX. I connect that with our VS2012 AddIn for ClickOnce signing and encountered this error:
An error occurred while signing: Failed to sign bin\Release\app.publish\\setup.exe. SignTool Error: The signer’s certificate is not valid for signing. SignTool Error: An error occurred while attempting to sign: bin\Release\app.publish\\setup.exe
I’ve checked what I believe are the usual suspects: I’ve imported the certificates into my trusted certificates through FireFox. Verified through Internet Explorer. Still same results.
I can choose the EXPORTED.PFX file and it shows the correct details.
I am fairly certain I’ve used the openssl to create a 4096-bit certificate? Following the instructions I was unable to output the SNK public key, which may be an issue later on (“just in case”).
Anyone with a solution to this problem?
One observation, as far as I know, our key is 4096-bits, like the KB2661254 issues says. Not < 1024 anyway. Should we remove that patch, however?
My gut feeling on this is that ClickOnce publishing is great when it works. But you can probably roll the same in your own app: have a “bootstrap” program run that checks the version; if it is old, update the “main” application before running it. If it is up to date, just run the main application.
For every solution, there is an equal and just as irksome alternate solution. 🙂
Not sure if its of any help to anyone but i just had this problem crop up first thing in the morning. Turns out visual studio had changed the build platform to ‘mixed platforms’ Changing it back to ‘Any CPU’ and rebuilding solved it 🙂
I have been removing the KB2661254 update whenever it crept back in in order to get around this. It started again yesterday but the KB2661254 update was not there.
I sorted the updates by date and started removing them from the Microsoft Windows area on the Installed Updates page.
I believe the new culprit to be KB2808679.
Now I understand my confusion – it is both of them.
KB2808679 and KB2813430
Now it is KB2862966!