Search code examples
code-signingcode-signing-certificate

Cross signing an msi or executable. Is there any reason to do so?


https://learn.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing

As per the link above you can sign a kernel model driver with your code signing certificate, then sign it again with the cross signed cert. This is required for a kernel mode driver.

The question is, is there any reason/benefit of signing your exe/msi packages with the cross signed certificate as well?

If there isn't any benefit, why is it required for a kernel mode driver? How does it make it more secure?


Solution

  • Cross signing gives an extra level of trust, which is important for kernel mode drivers. Cross signing provides extra trust because it's very unlikely that both certificate authorities would have been compromised.

    For EXE's and MSI's it would seem that cross signing means your executable can still be trusted in the event that one of the authorities were compromised.

    EDIT:

    My personal experience related to this was with Authenticode signed assemblies and how they can be slow to load (you haven't said if your EXE is a .NET assembly). See here https://blogs.msdn.microsoft.com/shawnfa/2005/12/13/authenticode-and-assemblies/

    Assembly Load Performance

    When the CLR loads an assembly which has an Authenticode signature, it will always try to verify that signature. This is in contrast to the Windows loader, which will verify the signature of a file only in specific instances, such as when the file is an ActiveX control. This verification can be quite time intensive, since it can require hitting the network several times to download up to date certificate revocation lists, and also to ensure that there is a full chain of valid certificates on the way to a trusted root. So, when an Authenticode signature is applied to an assembly it's not unheard of to see a several second delay while that assembly is being loaded.

    Also note that the optimization applied to strongly named assemblies, where the strong name signature is not verified if the assembly is being loaded from the GAC is not applied to Authenticode signatures. Since Authenticode provides the ability to revoke a certificate, we cannot assume that because the assembly's Authenticode signature was valid when it went into the GAC it will remain valid every time we load it.

    To me that's saying that if your EXE is built by .NET (ie. it's an assembly) then probably the more CA's it's signed by, the slower it might load. If it's not .NET, or an ActiveX control (or 'some instances), then there will be no delay.