我的公司为基于服务器的产品分发 Windows 安装程序。根据最佳实践，它使用证书进行签名。根据Microsoft 的建议，我们使用GlobalSign 代码签名证书，Microsoft 声称默认情况下所有 Windows Server 版本都可以识别该证书。
现在，这一切正常，除非服务器已配置组策略：计算机配置/管理模板/系统/互联网通信管理/互联网通信设置/关闭自动根证书更新为已启用。
我们发现我们的一位早期 beta 测试人员正在使用此配置运行，导致安装过程中出现以下错误
无法安装所需的文件，因为 cab 文件 [cab 文件的长路径] 具有无效的数字签名。这可能表明cabinet 文件已损坏。
我们把它写成了一个奇怪的东西，毕竟没有人能够解释为什么系统是这样配置的。但是，现在该软件可用于一般用途，我们的客户中似乎有两位数（百分比）配置了此设置，没有人知道为什么。许多人不愿意改变设置。
我们已经为我们的客户写了一篇知识库文章，但我们真的不希望问题发生，因为我们真正关心客户体验。
我们在调查时注意到的一些事情：
- 全新的 Windows Server 安装不会在受信任的根权限列表中显示 Globalsign 证书。
- 在 Windows Server 未连接到 Internet 的情况下，安装我们的软件可以正常工作。在安装结束时，Globalsign 证书存在（不是我们导入的）。在后台 Windows 似乎在首次使用时透明地安装它。
所以，这又是我的问题。为什么禁用根证书更新如此普遍？再次启用更新的潜在副作用是什么？我想确保我们可以为客户提供适当的指导。
在 2012 年末/2013 年初，自动根证书更新存在问题。临时修复是禁用自动更新，所以这个问题部分是历史性的。
另一个原因是受信任的根证书程序和根证书分发，（用微软的话来说）......
到目前为止，一切都很好，但后来......
发生这种情况时，可能会出现证书被自动添加到根存储。所有这一切都让一些系统管理员感到紧张，因为您无法从证书管理工具中删除“坏”CA，因为它们无法删除......
实际上，有一些方法可以让 Windows 下载完整列表，以便他们可以根据需要对其进行编辑，但通常只是阻止更新。大量系统管理员（通常）不了解加密或安全性，因此他们毫无疑问地遵循公认的智慧（正确或不正确），并且他们不喜欢对他们不完全理解的涉及安全的事情进行更改相信它是一些黑色艺术。
自动根证书更新组件旨在自动检查 Microsoft Windows Update 网站上的受信任机构列表。具体来说，有一个存储在本地计算机上的受信任的根证书颁发机构 (CA) 的列表。当应用程序收到由 CA 颁发的证书时，它将检查受信任的根 CA 列表的本地副本。如果证书不在列表中，自动根证书更新组件将联系 Microsoft Windows Update 网站以查看是否有可用更新。如果 CA 已添加到 Microsoft 受信任 CA 列表中，则其证书将自动添加到计算机上的受信任证书存储中。
简短的回答可能是关于控制。如果您想控制受信任的根 CA（而不是使用此功能并让 Microsoft 为您完成），最简单、最安全的方法是提供您想要信任的根 CA 列表，将它们分发到您的域计算机，然后锁定该列表。由于组织想要信任的根 CA 列表的更改相对较少，因此管理员希望审查和批准任何更改而不是允许自动更新是有一定意义的。
坦率地说，如果没有人知道为什么在给定环境中启用此设置，则意味着不应该设置它。
将允许域计算机检查 Microsoft Windows 更新站点上的受信任 CA 列表，并可能将新证书添加到其受信任证书存储中。
如果这对您的客户/客户来说是不可接受的，则可以通过 GPO 分发证书，并且他们需要将您的证书包含在他们当前用于受信任证书的任何分发方法中。
或者您可以随时建议暂时禁用此特定策略，以允许安装您的产品。
我禁用 certif.service 的原因如下：
我有许多没有互联网连接的系统。此外，在大多数情况下，它们缺少显示/kb/鼠标，因为它们是大型 DatastoreServer 上的虚拟机。因此，在所有需要维护/修改的情况下，我都会使用 Windows RDP 来处理它们。如果您通过 RDP 连接到计算机，Windows 首先会在线检查证书更新。如果您的服务器/客户端没有互联网，它会在继续连接之前挂起 10-20 秒。
我每天都会进行很多 RDP 连接。我节省了几个小时不盯着消息：“保护远程连接”:) +1 禁用 certif.service！
我不同意禁用此功能很常见。更好的表达方式是询问为什么有人会禁用它。对于您的问题，更好的解决方案是让安装程序检查根/中间 CA 证书，如果不存在则安装它们。
受信任的根 CA 计划是必不可少的。如果广泛关闭，大量应用程序将无法按预期工作。当然，可能有一些组织会禁用此功能，但这取决于组织，具体取决于他们的要求。这是一个有缺陷的假设，即任何需要外部依赖项（根证书）的应用程序都可以在不对其进行测试的情况下运行。禁用此功能的应用程序开发人员和组织都有责任确保存在外部依赖项（根证书）。这意味着如果组织禁用此功能，他们知道会出现此问题（或很快就会了解）。
还值得注意的是，受信任的根 CA 程序机制（动态安装根 CA 证书）的一个有用目的是安装所有甚至大部分知名/受信任的根 CA 证书是不切实际的。如果安装的证书过多，Windows 中的某些组件会损坏，因此唯一可行的做法是仅在需要时安装所需的证书。
http://blogs.technet.com/b/windowsserver/archive/2013/01/12/fix-available-for-root-certificate-update-issue-on-windows-server.aspx
“问题是这样的：用于向客户端发送可信证书的 SChannel 安全包有 16KB 的限制。因此，存储中的证书过多会阻止 TLS 服务器发送所需的证书信息；它们开始发送但必须停止发送它们达到 16KB。如果客户端没有正确的证书信息，他们将无法使用需要 TLS 进行身份验证的服务。因为 KB 931125 中可用的根证书更新包手动将大量证书添加到存储中，将其应用于服务器结果在存储中超过 16KB 限制和可能失败的 TLS 身份验证。”
我知道这是一个较旧的线程；但是，我想提交一个替代解决方案。使用您正在使用的证书颁发机构 (ROOT CA)。换句话说，将您的签名证书切换到具有更旧的、经过批准的根 CA 的证书。
DIGICert 在请求证书时提供此功能。虽然这可能不是您 DIGICert 帐户中的默认根 CA，但在向他们提交 CSR 时，它是一个可用的选项。顺便说一句，我不为 DIGICert 工作，也没有通过推荐他们获得任何收益。我只是感到这种痛苦，并且花了太多时间在便宜的证书上节省 1000 美元，而我本可以购买更昂贵的证书并花了很多钱处理支持问题的时间更少。这只是一个例子。还有其他证书提供商提供相同的东西。
警告 - 如果您在制作 CSR 时选择了正确的根 CA。