我使用以下命令运行SignTool:signtool sign/f keyfile.pfx/p mypassword pathToMsiFile.msi,我收到以下错误:

SignTool错误:发生了意外的内部错误.错误信息:"错误:Store :: ImportCertObject()失败." (-2146893792/0x80090020)

它一直工作到一天前,我不知道可能会有什么变化......

任何想法都会很棒,谢谢!

我设法修复它.显然用户已损坏.

在使用Microsoft的这个KB修复用户之后,一切都变得正确了.

我正在尝试解决WiX RemotePayload哈希问题,但我不确定该CertificatePublicKey属性是如何找到的.

例如,从WiX 3.6源代码中获取.NET 4.0软件包定义:

  <Fragment>
    <util:RegistrySearchRef Id="NETFRAMEWORK40"/>

    <WixVariable Id="WixMbaPrereqPackageId" Value="NetFx40Redist" />
    <WixVariable Id="WixMbaPrereqLicenseUrl" Value="$(var.NetFx40EulaLink)" />

    <PackageGroup Id="NetFx40Redist">
      <ExePackage
          InstallCommand="/q /norestart /ChainingPackage &quot;[WixBundleName]&quot;"
          RepairCommand="/q /norestart /repair /ChainingPackage &quot;[WixBundleName]&quot;"
          UninstallCommand="/uninstall /q /norestart /ChainingPackage &quot;[WixBundleName]&quot;"
          PerMachine="yes"
          DetectCondition="NETFRAMEWORK40"
          Id="NetFx40Redist"
          Vital="yes"
          Permanent="yes"
          Protocol="netfx4"
          DownloadUrl="$(var.NetFx40RedistLink)"
          Compressed="no"
          Name="redist\dotNetFx40_Full_x86_x64.exe">
        <RemotePayload
            Size="50449456"
            Version="4.0.30319.1"
            ProductName="Microsoft .NET Framework 4"
            Description="Microsoft .NET Framework 4 Setup"
            CertificatePublicKey="672605E36DD71EC6B8325B91C5FE6971390CB6B6"
            CertificateThumbprint="9617094A1CFB59AE7C1F7DFDB6739E4E7C40508F"
            Hash="58DA3D74DB353AAD03588CBB5CEA8234166D8B99"/>
      </ExePackage>
    </PackageGroup>
  </Fragment>

来自wix36-sources\src\ext\NetFxExtension\wixlib\NetFx4.wxs

我能找到的SHA1 Hash与fciv -sha1 dotNetFx40_Full_x86_x64.exe...

58da3d74db353aad03588cbb5cea8234166d8b99 dotnetfx40_full_x86_x64.exe

我可以CertificateThumbprint通过文件的属性对话框轻松找到匹配,或者使用signtool它来显示以下输出

C:\redist>signtool verify …

我们最近尝试对.NET二进制文件进行数字签名。我们有一个Windows服务，通常会在10秒内启动。但是，当我们开始对其进行数字签名后，时间增加到20-30秒左右。

谷歌搜索导致我这样：http : //support.microsoft.com/kb/936707，它基本上说我必须将generatePublisherEvidence设置为false。

但是在MSDN上对generatePublisherEvidence的描述指出了这样的事实，即它不适用于.NET 4。我再次检查了我的二进制文件是否针对.NET 4。

有人可以向我解释这种行为吗？

有没有人知道如何在不使用应用程序配置文件的情况下禁用.NET可执行文件中的authenticode签名验证(以避免启动缓慢)？换句话说,这样做:

<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
</configuration>

没有app.config.可能吗？

我正在为我的开源项目获得代码签名证书.我有几个问题:

1. 作为开发开源项目的未注册公司,有没有办法通过验证过程？
2. 如果我以个人名义注册代码签名证书,是否涉及任何风险(例如,被盗身份和跟踪)？

直接在构建服务器上安装Authenticode代码签名证书以创建生产签名构建是否可以接受？我正在网上寻找一些建议或支持这种做法是合法的资源,前提是您已采取适当的步骤来保护构建服务器以及构建和部署构建的过程.

关于代码签名实践,我可以找到的所有"最佳实践"指南在建议的流程方面都是最重要的.对于签署单个程序集的简单操作,Microsoft的参考文档有多达6个服务器. http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc

一些背景:

我的公司为其员工和直接客户创建简单的富客户端业务应用程序.我们不创建商业软件.我的构建服务器使用我公司严格的安全策略和程序进行物理安全和网络安全保护.只有组织中非常具体的人才能够在我的环境中开始构建.

我们当前的流程要求我通过大量的手动流程将构建/部署流程分解为多个阶段.我们使用物理设备存储Authenticode证书,要求用户输入的PIN才能访问.我们必须将需要代码签名的程序集/清单洗牌到指定的代码签名PC,这些PC也必须是物理安全的.

对我而言,传递物理令牌/设备并保留所有这些手动步骤的安全性较低.没有任何东西可以阻止物理访问令牌/设备的人签署任何他们想要的东西.至少,通过自动化,记录的,受控制的构建服务器环境,您可以知道签名的内容以及由谁签名.

因此，我正在使用Windows SDK 8.1中的signtool对二进制文件进行签名：

"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe" sign /a /i Symantec /ac C:\utils\MSCV-VSClass3.cer /ph /t "http://timestamp.verisign.com/scripts/timstamp.dll" "foo.exe"
Done Adding Additional Store
Successfully signed: foo.exe
"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe" sign /a /i Symantec /ac C:\utils\MSCV-VSClass3.cer /ph /fd sha256 /tr "http://timestamp.geotrust.com/tsa" /td sha256 /as "foo.exe"
Done Adding Additional Store
Successfully signed: foo.exe

当我在文件属性中查看它时，可以看到正确的结果。

但是，当我使用它时verify，signtool我会根据传递的参数获得：

"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe" verify /all "foo.exe"
File: foo.exe
Index  Algorithm  Timestamp
========================================
SignTool Error: A certificate chain processed, but terminated in a root …

通过Visual Studio的项目"签名"设置页面签署ClickOnce部署时,我指定了SHA2(SHA256)EV Authenticode证书并发布.

发布并尝试运行引导程序(setup.exe)后,我在ClickOnce对话框中显示"未知发布者".

有问题的EV证书是有效的,并且在带有SafeNet客户端工具的eToken硬件令牌上运行,以与令牌进行通信.使用signtool签署常规PE文件(exe和dll)始终生成完全有效的程序集,并且发布者是已知的.这只是ClickOnce部署的一个问题.此外,ClickOnce部署的各个文件看起来完全有效,因为文件属性对话框的数字签名选项卡已正确列出为引导程序(setup.exe)和后缀为".deploy"的程序集文件.

此外,".application"和".manifest"文件被适当地改变(可能通过Visual Studio的mage)以包含<publisherIdentity>元素以及正确的算法集.

签名机正在运行Win10,我尝试了我能想象到的每一种排列:

• 有没有时间戳
• 有和没有强名称签名
• 有无在线发布
• 有无https在线发布
• 通过发布页面添加和不添加特定的"更新位置"
• 在发布页面中通过描述设置和不使用"发布者名称"
• 随着Manifest选项的每个组合:
  • 排除部署提供程序URL
  • 阻止通过URL激活应用程序
  • 将应用程序清单用于信任信息
• 各种版本的Windows上的多台机器
• 通过mage和signtool进行手动清单签名和程序集签名(是的mageui)
• 确保证书提供程序未撤消证书

似乎有其他人经历过这种情况.

我当前正在使用 WinVerifyTrust api 检查 Windows 安装程序文件 (.msi) 的数字签名在 C# 中是否有效。我还在验证签名中的指纹是否来自已知列表。

我需要对 C# 中的 Mac OSX 文件 (.dmg)（在 Windows 上）执行相同的操作。有什么办法可以做到这一点吗？

在 Windows 上，有 Authenticode 来签署 .NET Core / .NET 5 程序集（请注意，我指的不是强名称签名，这是不同的）。这可以防止篡改并保证真实性。

我是 Linux 上的 .NET Core 新手。Linux 上 .NET Core 的 Authenticode 签名相当于什么？由于 Authenticode 签名是 Windows SDK（而不是 .NET Core）的一部分，因此它在 Linux 上不可用。理想情况下，有一些广泛使用的约定。

在 SO 和网上广泛查看，但未能找到任何有用或明确的内容。任何指导将不胜感激。