To be clear, the request is to sign the standard Custom Action DLLs in the WiX Toolset, correct? We already sign the installer files distributed by WiX Toolset so that is not the issue, correct?

Yes, in details I am talking about these files:

• bin\WixBalExtension.dll
• bin\WixComPlusExtension.dll
• bin\WixDependencyExtension.dll
• bin\WixDifxAppExtension.dll
• bin\WixDirectXExtension.dll
• bin\WixFirewallExtension.dll
• bin\WixGamingExtension.dll
• bin\WixIIsExtension.dll
• bin\WixLuxExtension.dll
• bin\WixMsmqExtension.dll
• bin\WixNetFxExtension.dll
• bin\WixPSExtension.dll
• bin\WixSqlExtension.dll
• bin\WixTagExtension.dll
• bin\WixUIExtension.dll
• bin\WixUtilExtension.dll
• bin\WixVSExtension.dll

if you would sign at least these binaries (which will be added to the binaries table of a msi when adding a CA) of the wix toolset package this would be helpfull. If you would sign all binaries it would also be okay ;).
This would be the easiest way, otherwise it would be helpful to have an extension point for signing the CA dlls (which will added to the msi) before they get imported into the binary table.

Comment: The binaries listed above are only used during build, and are NOT distributed in the built MSI files. I don't know what signing those files would do. The executable binaries inside the resources of those binaries ARE potentially included in MSIs and are what would need to be signed to effectively achieve what I understand to be the request here.

this is not completely right, have you tested it?

Look here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368075(v=vs.85).aspx

When the custom action is invoked, the stream data is copied to a temporary file, which is then processed depending upon the type of custom action.

For a MSI File with a Custom Action referencing one of the default provided DLLs, the installation will fail during execution on a System with DeviceGuard enabled when only the MSI is signed. If these DLLs would be signed I could add the Signature Hash into a whitelist as for the MSI.
If I Sign the default CA Dlls manually everything works fine.

Unfortunately what I now need to do, is: Install WixToolkit and manual sign the dlls in ProgramFiles folder (and do this for all my Build Cloud machines) OR repack the wixtoolkit with signed files and install on my machine.

Therefore it would be much easier to have the files directly signed (which is a small effort before creating the WixToolkit installer), or at least an extensionpoint (which is more effort to implement) for signing the default CAs before they get embedded into msi.
For my own CustomActions all is is no problem, as I compile them, I also sign them before I create the installer.

Btw. to deliver digital signed binaries and Installer is today more common sense than an exception!

@robmen I now also read in the triage https://www.firegiant.com/blog/2016/7/5/wix-online-meeting-108-highlights/
you said:

I suggested we not sign them as it would allow a malicious actor to use, for example, WixQuietExec to call cmd.exe to launch the nuclear missiles.

I currently do not share the fear here, Just having the default custom actions signed does not mean you can install on a system with DeviceGuard enabled.
To make a complete example here, in order to let my application run on a DeviceGuard enabled windows, i added/whitelisted in advance (before enable DeviceGuard) some Sign Hashes (like my own, some from Microsoft...) to allow these signed applications to make changes to the guarded system. Now I create my application or an update for my application:
I compiled my Application binaries, Sign my binaries (incl. PS1 and Batch scripts..), compile my MSI and sign the MSI (in this example without a CA).
Now, if the MSI is signed with my key which was whitelisted above, I can install the MSI on my guarded windows and I can run my application, because my binaries are signed as well.

The Case with launching a nuclear missile, would mean that I also sign the missile (mostly a troyan or something else, because just destroying a machine brings nothing ;) ). In this case I also need to sign the script or binary with an already whitelisted Signature Key, in my example case a Microsoft one or my own one. Therefore my or the MS private key may/must have been compromised.
For sure you can run a format C or any other already signed Microsoft command, but usually you (IT Admin, Vendor of a DeviceGuarded System...) test the installation before bringing them to the DeviceGuarded Systems. Especially if you see that currently Device Guard is a Windows Enterprise Feature.
Nevertheless already today you can start the nuclear missile with an installer on every other windows system ;) So running an installation or an Application from a not trustworthy source or vendor is always a risk.

Don't get me wrong here, as I said in my first post it would be completely fine for me, to have a MsBuild Extension point to sign the default CA dlls as well with my certificate, as I already sign my compile result, MSI, Bundle... etc.
I only do not want the implementation efforts to explode here.
Just my 50 Cents here ;)

@BobSilent: Here's what I've tested: using the elements defined in the above list of DLLs in building MSI files. When I do that, none of those DLLs themselves are embedded anywhere inside of the MSI. What is embedded is the CA DLL (usually the one containing WixQuietExec) which is then copied to a temporary file and loaded to run the code contained therein. That CA DLL is embedded INSIDE of the above list of DLLs.

@robmen: I agree with BobSilent regarding the security issues raised with digitally signing the CAs that we embed in the extension DLLs. We should sign them.

Besides, if someone can load the DLL and call it passing it the parameter (an MSI handle to an active session) needed to make it function, they can call CreateProcess all by themselves with the exact same security profile. There is no added security risk added by signing the CAs, in my not-so-humble opinion.

I vote that this enhancement be done by signing the CA in the WiX official build before embedding them into the extension DLLs. Whether or not the extension DLLs themselves are also signed may still produce a performance hit when users build using them (I don't know if that bug in Windows was ever fixed or not, I didn't keep track), so I would argue (but not strenuously) against signing the extension DLLs themselves.

The plan was always to sign the CA DLLs, not the extension DLLs.

I'm all in, then :)

After investigating this a bit, this is something we'll consider for WiX v4.0.

Will signing the CA DLLs resolve this issue?

I've configured my build process to sign all binaries and override signmsi target to sign the msi. When the installer is run, some tmp files are breaching my Windows 10 Device Guard policy.

I signed all wix toolset binaries to see if it made any difference, but it didn't. The tmp files were then copied and inspected - they are wixca.dll and another of or own custom action dlls. Even after signing our own custom action dll, the problem still persists since the data is streamed to a new unsigned tmp file at install time as already pointed out.

Is there a way to configure this so that a signed version of wixca.dll and our own custom action dll is embedded in the msi and extracted as is with signature intact?

When will this be solved? This issue lurks around for quite some time. It is annoying that I cannot sign wixstdba.dll by myself because I have nowhere found sources from where WIX pulls this dll.

This is something we're looking at doing in WiX v4. It'll take a good bit of build process rework to fit in.

@robmen Can you give a rough timeline when we can expect Wix v4 to happen? Or at least a workaround until it gets out? Where is Wix pulling this wixstdba.dll out? I can sign it myself if I know where it is.

WiX v4 should come out this year.

wixstdba.dll is embedded in the WixBalExtension and included in your bundle when needed.

It won't be trivial to sign.

@robmen, We are running into the same issue with "WixCA.ibd". Can you tell us what's the current timeline for Wix v4?

Ping.

@robmen and @barnson, can you please comment on the fix for this issue?

The fix is a lot of build work. WiX v4 is under active development. If you'd like to to see it get done more quickly, you can join us or fund someone that has joined us.

@robmen, thanks for the reply.

I would like to understand the scope of work and will contribute if its feasible. thanks much!

@pinnakas, sounds great. Our developer documentation provides a great checklist for getting started.

At one point this was on the 3.11 milestone, which I know shipped. But now that Device Guard is being deployed more generally in enterprise environments, any chance of getting this fixed for 3.x (e.g. 3.11.2) still?

@robmen, Is there any workaround that we can use until Wix v4 is released? Can I use a .js or .vbscript instead of C# custom action which is trying use "WixCA.dll"?

also what's the current timeline for Wix v4?

@robmen, Ping.
Is there any workaround that we can use until Wix v4 is released? also what's the current timeline for Wix v4?

I saw that, but I thought you said you no longer have a certificate available to use that. Did I misunderstand?

No -- that's the work that's needed, to switch from cert signing to a signing service.

An end user could always build the MSI, stream out the contents of the Binary table, sign them, stream them back, sign the MSI then build the bootstrapper and sign that also.

Is this fix(wixtoolset/wix3#481) already released in a production build or do I have to use a dev build? we are currently experiencing this issue where the msi built with Wix is being blocked by Device guard and looking for a fix.

v3.11.2

Watch that you don't get hit by #6089

Looks like we still see the issue with the msi built with toolset v3.11.2.4516 . Is this verified to work with Device guard?

Here is the error i get (Note that im running in Audit mode now to still run the installer and troubleshoot further. I have tried this in non audit mode and thats where the msi was blocked and had this same error)

Code Integrity determined that a process (\Device\HarddiskVolume1\Windows\SysWOW64\msiexec.exe) attempted to load \Device\HarddiskVolume1\Windows\Installer\MSIE65D.tmp that did not meet the Enterprise signing level requirements or violated code integrity policy. However, due to code integrity auditing policy, the image was allowed to load.

Detailed:
`-

• 3076 4 4 18 118 0x8000000000000000 58068 Microsoft-Windows-CodeIntegrity/Operational DESKTOP-3Q2AS1G
• 53 \Device\HarddiskVolume1\Windows\Installer\MSIE65D.tmp 52 \Device\HarddiskVolume1\Windows\SysWOW64\msiexec.exe 2 2 0xc0e90002 20 6C65DD86130241850B2D808C24EC740A4C509D9C 32 1DE7D13645D5B6D01E81AFA0E4157C21DC6E603C914810850CE98AAD3AA3412E 20 EB4CB5FF520717038ADADCC5E1EF8F7C24B27A90 32 C8D190D5BE1EFD2D52F72A72AE9DFA3940AB3FACEB626405959349654FE18B74 299494608 1 19 DefaultWindowsAudit 6 031017 32 40B975DA6D6745FFD735C8D0D9644311B099E3458AA07823F505DA109582A13A 9 wixca.dll 5 wixca 18 WiX Custom Actions 29 Windows Installer XML Toolset 3.11.4516.0 `

Hi, Any hints on this on why we are seeing the failure?

Did you try extracting the wixca.dll from the Binary table and checking that it truly is signed? If it isn't, then take a look at the official build you have and see if it is signed there. If it is signed, then you will have to understand the Device Guard issue more.

The problem is we are not able to find the wixca.dll in the build server where we have the wix Toolkit installed. We see the name wixca.dll only in the error reported on event viewer but couldnt find it anywhere else. Are we missing something?

The wixca.dll file is embedded within a CAB found inside of an embedded resource in the WixUtilExtension.dll file.

so is that dll signed in 3.11.2.4516 ? Is it signed under Microsoft certificates or Wix? If Wix, we have to include that in our signed policy file. Also how do i see the wixca.dll to see whether its signed or not in the build machine or on the target?

All of the WiX Toolset is signed with the same certificate. So, the same certificate is on the initial install. You can use that.

Thanks, can you also let us know how to extract that wixca.dll from the WixUtilExtension.dll ? This way we can include that dll in our catalog signing as well.

Also just now checked the 3.11.2 wix toolkit binaries and see that WixUtilExtension.dll is not signed. Should i have to download a different dev build?

Barring extraordinary errors, the file isn't left laying around on the target (it's embedded inside the MSI file, accessible via the binary table. It might accidentally be left behind during the build in some randomly named subdirectory of whatever directory the toolset interpreted as it's temporary files folder. The one reliable way to get it is to extract it from the Binary table, like robmen stated already. There are several utilities that can extract from Windows Installer file formats, including one in the Windows SDK. Orca can also extract from that table, but it appears from my reading of your comments that you want to extract it with automation during your build.

It would be signed by a certificate from the .Net Foundation, as they are the current holder of the copyright assignments for the toolset in order to enforce the FOSS licensing. That's the only certificate used during official builds of the toolset.

The extension dlls are only accessed during builds. They don't form part of your final customer delivery.

The focus of this feature was to sign binaries that could end up running on a customer's box.

For support please contact the wix-users mailing list.

@BMurri Thanks for the detailed information. As i see now, only the wix toolkit installer is signed by Wix using the .Net Foundation cert you mentioned. But when we create our msi using wix and run it on the Win 10 OS that has the WDAC code signing policy enforced it fails as it says that there is wixca.dll being used(extracted from a temp file internally maybe?). So all im trying to get to is to include all the dll/exe in the catalog that we sign. As of now it says only the wixca.dll. It can also be a one time manual process i follow to extract it.

@BMurri So i get confused now. is the WixCA.dll going to be signed only in Wix 4.0 release? As I see only the Wix msi is being signed and not any of the other dlls in it.

wixca.dll is in your MSI's Binary table and we are asking you to extract it to both verify that it is signed and to provide you with the signature details to allow you to setup Device Guard.

As far as I know that dll is signed in the official build you reference.

What you continue to ask in this already closed feature are questions that should be on wix-users. Please take the discussion there, especially if you still won't extract and inspect the file from the Binary table.