Digitally Signed .Net Service Fails

[ITI_Randy]

We have found that digitally signing a .Net service executable can sometimes cause the service to fail on a target machine following installation. We had recently started signing all objects, along with the MSI and Setup, in newer InstallShield packages, in an effort to be in compliance with new security requirements for Server 2008. We recently stopped signing the component objects in deployment packages because a few customers began reporting that services in these new packages would not start. Testing revealed that the one single factor causing the problem was digital signing.

In researching this issue, I was able to find several articles describing possible problems that can occur in signing executables used in services, a common one being validation timeouts. I also found a support letter from Microsoft advising that .Net executables not be signed in deployment packages, as there are various issues that can occur which will prevent the service from starting. They suggested signing only the MSI and the Setup, but not the objects in these deployments.

I currently have an issue open with InstallShield support to look into this further. I'm learning more about this daily and we are testing on servers where we have encountered problems. I'm wondering if there is anyone else out there who has hit issues with this, and if so, how did you handle it? Are there others who have made it a matter of policy that when distributing programs that have services, you only sign the setup and/or msi, but not the component objects?

Your feedback is much appreciated.



Still no comments? One more try...
Is there anyone else out there who has hit issues when digitally signing .Net services?

[Christoph]

Randy,

we encounter exact the same issue.
We have a .NET service that we distribute with our Installshield 2008 Basic MSI installer. We sign all the binaries(.exe and .dll) in the setup package via an official certificate file from Verisign.

The installation works flawlessly but as soon as we reboot the machine, the service failed to start. Starting the service manually works.

We already found out that only the signing could be the problem because as we copy the unsigned .NET service EXE over the signed one(after installation) and we reboot the system afterwards... no problems.

What did you do to solve this issue?
Are there any side-effects you encountered by not signing the binaries inside your installer package?

Regards

[ITI_Randy]

Hi Christoph,

After much research, we found several articles from various companies describing the same behavior we were experiencing, and with each one, people saying that the only solution that they could find was to NOT sign executables that are used for services. It appears that the issue revolves around something in some operating systems that attemp to validate services that are signed. If the machine is not connected to the internet or cannot validate the certificate locally through the network, the service will fail to start. What finally put the lid on the whole issue for us was when I found a recent article from Microsoft Tech Support telling a troubled customer that they recommended to NOT sign service executables. We have taken this approach and so far it has not raised any further issues.

See the articles below:

http://www.brianhaas.com/2007/12/21/WhenDoingTheRightThingBites.aspx

http://social.msdn.microsoft.com/Forums/en-US/clr/thread/db3a6268-3f45-4b72-87f0-f27cfab274b7/

Note particularly the response from Microsoft Tech Support in the last article:

"It is recommended to sign the installer or MSI instead of signing the service or assembly itself."

The first article is interesting because it pretty much describes the frustration that our company felt after doing what we were told was correct and then having it come back to bite us. We were told that we needed to sign all objects in the installation, including the .msi and the setup. Then after the thing came back to cause us issues, we found that Microsoft had recanted and said they recommend that we NOT sign service executables, but only the .msi and setup that install them.


Hope this is of some help,


Randy

[Cary_R]

Hi There,

Just stumbled across this thread, and recall having dealt with this in one of our products as well. There's a fairly deep dive on this issue here:

http://blogs.msdn.com/dsvc/archive/2008/06/24/troubleshooting-startup-issues-with-managed-application-having-authenticode-signature.aspx

Which also includes an app.config change that allows you to still sign the service. However, a hotfix for .Net is required if your app is running on XP/.Net 2.0. Still, a lesser evil, I would say.

Hope this helps anyone still struggling with this!

[ITI_Randy]

Cary,

Thanks for the information and the MSDN link. This article confirms what we later found in other articles as well, which typically describe the utter frustration of developers who have struggled with this and finally found out that they need to add the generatePublisherEvidence to the .exe manifest. At the current time, this is the approach that we have taken. With all service executables, we are careful to provide a manifest that contains the added section for generatePublisherEvidence:







This was a fix we desperately needed, as we have clients that are installing to machines that have no internet service for security reasons.

Thanks again for the update.