How to avoid warning on AssemblyName.vsto when setup.exe is signed via EV certificate (SHA2)

Question

I just acquired an EV code signing certificate.

I use the certificate through the ClickOnce signing tab/page of my project properties (selected from store). I deploy the files on a remote public FTP, where customers can download the setup.exe bootstrapper. This work fine, and I get a greenlight prompt when running setup.exe, but then I get a second prompt - the Microsoft Office Customization Installer - which indicates

Publisher has been verified

but keeps showing a yellow warning shield, and the following details:

While Office customizations from the Internet can be useful, they can otentially harm your computer. If you do not trust the source, do not install this software.

How can I go green?

I did check the files from publish folder: onlysetup.exe is seen as signed by the DigiCert Certificate Utility. Other files are either not recognized as signable (AssemblyName.vsto, and FileName.dll.manifest), or are shown as not signed (FileName.dll.deploy). I guess this is because these files are signed via the Mage ClickOnce utility, which is distinct from signtool or any Authenticode signing technology?

Does it have something to do with signing, or is it by design for Office solutions that I cannot go green unless I am in the list of trusted publishers? Like this article seems to suggest.

Answer 1

The first time a VSTO (but not now a raw COM) addin is loaded, VSTO run-time checks if the addin is listed in HKCU\Software\Microsoft\VSTO\Security\Inclusion.

All parameters can be extracted from your addin's .manifest file.

You can create that key from your customer installer. I don't think you can do that from a ClickOnce installer.

Answer 2

I guess this is because these files are signed via the Mage ClickOnce utility, which is distinct from signtool or any Authenticode signing technology?

You are on the right avenue. Signing the setup.exe file is not enough. You must sign the application and deployment manifests, see How to: Sign application and deployment manifests for more information. It states the following:

If you want to publish an application by using ClickOnce deployment, the application and deployment manifests must be signed with a public/private key pair and signed using Authenticode technology. You can sign the manifests by using a certificate from the Windows certificate store or a key file. For more information about ClickOnce deployment, see ClickOnce security and deployment. Signing the ClickOnce manifests is optional for .exe-based applications.

After you make changes to deployment properties in the application manifest for Windows Forms applications, Windows Presentation Foundation applications (xbap), or Office solutions, you must re-sign both the application and deployment manifests with a certificate. This process helps ensure that tampered files are not installed on end user computers. Another scenario where you might re-sign the manifests is when your customers want to sign the application and deployment manifests with their own certificate.

Read more about that in the How to: Re-sign application and deployment manifests article.

Basically your code/solution signing custom actions may look like these:

- "signtool.exe" sign /f $(SolutionDir)certificate.pfx /p myPwd$(TargetPath)

- "mage.exe" -sign $(TargetPath).manifest -CertFile $(SolutionDir)certificate.pfx -Password myPwd

- "mage.exe" -sign $(TargetDir)$(TargetName).vsto -CertFile $(SolutionDir)certificate.pfx -Password myPwd