Question

I’ve got a brand new code-signing certificate and have been wondering which files I should sign.

Clearly, the setup .msi package and all .exe which run elevated should be signed to avoid “unknown publisher” warnings, but should I sign other executables, e.g. .exe which don’t need elevation, .dll or .oxc?

Microsoft themselves seem to handle this inconsistently:

• In Office 2007, all executable files are asigned
• In Visual Studio 2008, all .exe and many .dll are signed, however, there are also lots of unsigned DLLs (apparently strong-named assemblies, maybe they consider strong-naming sufficient)
• In Windows (7), neither executables nor dlls are signed (not even executables that need UAC, like mmc.exe!)

Answer 1

I think you answered your own question, sign only where needed to avoid prompting.

There are only a few reasons where I would consider signing everything.

1. It might have some kind of advantage
   with Anti-Virus vendors treating
   your files as more trustworthy,
   therefore less support / install
   hassle.
2. It marks the file as more trustworthy to a general user, for example, when I clean up a virus infected system using autoruns from MS I tend to look for shoddy stuff that has no signature, it sticks out a mile.
3. You want to look more professional.

I don’t know what overhead there is in checking the signature though, so older systems may be slower. Also, if your cert is from a cheapo cert supplier then the root CA might not be included in older platforms (XP pre SP2 etc).

Oh yes, I’d only do it as part of the build as well (integrate into MSBuild or a build server) as it could get tedious.

Remember to not let anyone else get access to your key otherwise you’ll have it revoked and all of a sudden, installs might stop working. So use a self signed cert for devs and keep the real key locked down on a build server.

Bit rambling, but there is no right answer I think.