如何使用已签名的引导程序（setup.exe）诊断基于URL的安装问题？ [英] How to diagnose an URL based installation issue with a signed bootstrapper (setup.exe)?
问题描述
我们多年来一直使用相同的基于URL的安装将C＃应用程序部署到客户端计算机，通过下载已签名的引导程序启动。 我使用SHA-1证书签署的所有旧版本都继续工作。
所有尝试下载并执行新构建和签名的引导程序（安装程序）导致"Windows保护您的PC"。 如果将引导程序从可移动介质或RD连接复制到新计算机，它将启动，如所需
，请求并验证msi程序包，并执行安装。
We have been deploying C# applications to client computers for many years, using the same URL based installation, initiated by downloading a signed bootstrapper. All of my old builds, signed with a SHA-1 cert, continue to work.
All attempts to download and execute a newly built and signed bootstrapper (setup) result in "Windows protected your PC". If the bootstrapper is copied to the new computer, from removable media or over an RD connection, it starts, as
desired, requests and verifies the msi package, and executes the installation.
Sigcheck说数字签名和证书路径在引导程序中是有效的。 工作中的清单与"阻止"之间没有区别。安装文件（请参阅下面的安装清单）。
Sigcheck says that the digital signature and certificate path are valid in the bootstrapper. There is no difference between the manifests in working and "blocked" setup files (see Setup Manifest below).
所以... 它看起来像是设置文件中的另一个问题或环境/安全性变化（在Windows或IIS中）。
So... It's looking like it's either a different problem within the setup file or an environmental / security change (in Windows or IIS).
问题：
- IIS中是否有新的或现有的设置将文件指定为"安装程序"？或类似的？
- 是否有新的或现有的方法来绑定或引用带有超链接的安装程序文件？
- MSIstuff.exe是否确实存在？   ;  ） 查看安装文件会很好吗？
- 是否有其他可能的诊断工具？
Windows Installer文档带您到这里：
https://docs.microsoft.com/en-us/windows/desktop/msi/internet-download-bootstrapping
哪些引用msistuff.exe。 我无法在任何地方找到它（即使安装了几乎所有的VS 2017，安装程序包和windows sdk）。
谢谢。
Bill Clark
设置清单
<？xml version =" 1.0 "编码= QUOT; UTF-8英寸？>
$
< assembly xmlns =" urn：schemas-microsoft-com：asm.v1" manifestVersion =" 1.0">
< assemblyIdentity
version =" 1.0.0.0"
processorArchitecture =" X86"
name =" Setup"
type =" win32"
/>
< description>安装程序< / description>
< dependency>
< dependentAssembly>&
< assemblyIdentity name =" Microsoft.Windows.Common-Controls"版本= QUOT; 6.0.0.0" ProcessorArchitecture用于= QUOT; X86"公钥=" 6595b64144ccf1df"语言= QUOT * QUOT; type =" win32" />
< / dependentAssembly>
< / dependency>
< trustInfo xmlns =" urn：schemas-microsoft-com：asm.v3">
< security>
< requestedPrivileges>
< requestedExecutionLevel level =" asInvoker" uiAccess =" false" />
< / requestedPrivileges>
< / security>
< / trustInfo>
< compatibility xmlns =" urn：schemas-microsoft-com：compatibility.v1">
< application>
<！ - Windows 10 - >
< supportedOS Id =" {8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
<！ - Windows 8.1 - >
< supportedOS Id =" {1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
$
<！ - Windows 8 - >
< supportedOS Id =" {4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
$
<！ - Windows Vista - >
< supportedOS Id =" {e2011457-1546-43c5-a5fe-008deee3d3f0}" />
<！ - Windows 7 - >
< supportedOS Id =" {35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
< / application>
< / compatibility>
< / assembly>
<?xml version="1.0" encoding="utf-8" ?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="Setup"
type="win32"
/>
<description>Installer</description>
<dependency>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" type="win32"/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
<!-- Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
<!-- Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
<!--Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
</application>
</compatibility>
</assembly>
历史：
我们购买了2018年10月新的SHA-1 authenticode证书。
我们不需要在2019年2月之前推广任何新代码。
C＃项目和（设置）已使用VS 2015构建部署项目。
使用SHA-1证书对setup和msi文件进行签名。
将setup和msi文件复制到Web服务器。$
路径上的所有证书都报告为OK。
设置文件以基本链接引用：
< a href =' HTTPS：//myserver/myapps/thisapp/setup.exe'>安装< / A>或
< a href =" setup.exe">安装< / a>。$
下载并执行安装文件会导致"Windows保护您的PC"。$
我们最初怀疑是证书，所以我们申请了新的SHA-1证书，并以相同的结果重复了exorcise。
然后我们认为它可能是SHA-1的一个问题，所以我们要求一个SHA-256证书，重复驱逐，再一次，得到相同的结果。
然后我们尝试了不同的时间戳权限和signtool.exe的不同版本。
我们能够通过从外部媒体执行安装文件或通过RD将其复制到计算机来验证我们在msi上的签名是否可接受winverifytrust &NBSP;未签名的msi按预期失败（无法识别的发布者）。
然后我们转向引导程序并开始研究Windows安装程序的当前状态。
我们使用SHA重复了驱逐-256证书和VS 2017，到同一目录。
HISTORY:
We purchased a new SHA-1 authenticode cert in Oct. 2018.
We didn't need to promote any new code until Feb. 2019.
The C# projects and the (Setup) deployment projects have been built with VS 2015.
The setup and msi files are signed with a SHA-1 cert.
The setup and msi files are copied to a web server.
All certificates on the path report as OK.
The setup file is referenced with a basic link:
<a href='https://myserver/myapps/thisapp/setup.exe'>Install</a> or
<a href="setup.exe">Install</a>.
Download and execution of the setup file results in "Windows protected your PC".
We initially suspected the cert, so we requested a new SHA-1 cert and repeated the exorcise with the same result.
We then thought that it might be an issue with SHA-1, so we requested a SHA-256 cert, repeated the exorcise, and once again, had the same result.
Then we tried different timestamping authorities and different versions of signtool.exe.
We were able to verify that our signature on the msi was acceptable to winverifytrust, by executing the setup file from external media or by copying it to a computer over RD. An unsigned msi failed as expected (unrecognized publisher).
We then turned to the bootstrapper and started reseaching the current state of windows installer.
We repeated the exorcise using the SHA-256 cert and VS 2017, to the same end.
推荐答案
你好，
您可以检查是否存在禁止此操作的策略，即使使用证书也是如此。我工作的公司不接受安装，因为它有一个验证证书，因为有内部政策禁止这样做，所以你可能会检查某些东西是否有
改变了它的安装政策。
You might check if there is a policy prohibiting this action even with a certificate. The company I work for does not accept a install because it has a validate certificate as there are internal policies prohibiting this so you might check if something has changed it policies for installations.
这篇关于如何使用已签名的引导程序（setup.exe）诊断基于URL的安装问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
