为什么许多管理员使用“关闭自动根证书更新”策略？

我公司为基于服务器的产品分发Windows Installer。根据最佳实践，它使用证书进行签名。根据Microsoft的建议，我们使用GlobalSign代码签名证书，Microsoft声称默认情况下所有Windows Server版本都可以识别该证书。

现在，除非已使用组策略配置服务器，否则所有方法都将正常工作：计算机配置/管理模板/系统/ Internet通信管理/ Internet通信设置/将自动根证书更新关闭为启用。

我们发现我们的早期Beta测试人员之一正在使用此配置运行，导致在安装过程中出现以下错误

机柜文件[cab文件的长路径]具有无效的数字签名，因此无法安装所需的文件。这可能表明橱柜文件已损坏。

毕竟没有人能够解释为什么系统是这样配置的，所以我们把这记为一个奇怪的例子。但是，既然该软件已经可以用于一般用途，则似乎两位数（百分比）的客户都使用此设置进行了配置，没有人知道原因。许多人都不愿意更改设置。

我们已经为客户写了一篇知识库文章，但是我们真的不希望这个问题发生，因为我们实际上在乎客户体验。

我们在调查时注意到了一些事情：

1. 全新的Windows Server安装未在受信任的根颁发机构列表中显示Globalsign证书。
2. 如果Windows Server未连接到Internet，则可以正常安装我们的软件。在安装结束时，会显示Globalsign证书（不是我们导入的）。Windows在后台显示首次使用时透明安装。

所以，这又是我的问题。为什么禁用根证书更新如此常见？再次启用更新的潜在副作用是什么？我想确保我们可以为客户提供适当的指导。

在2012年末/ 2013年初，自动根证书更新出现问题。临时修复是禁用自动更新，因此，部分原因是历史性的。

另一个原因是“受信任的根证书”程序和“根证书分发”，它们（用Microsoft来解释）...

根证书在Windows上自动更新。当[系统]遇到新的根证书时，Windows证书链验证软件将为根证书检查相应的Microsoft Update位置。

到目前为止，还算不错，但是……

如果找到它，则将其下载到系统中。对于用户而言，体验是无缝的。用户看不到任何安全对话框或警告。下载会在后台自动进行。

发生这种情况时，似乎会自动将证书添加到根存储中。所有这些使一些系统管理员感到紧张，因为您不能从证书管理工具中删除“不良” CA，因为它们不在那里...

实际上，有一些方法可以使Windows下载完整列表，以便他们可以根据需要进行编辑，但是通常只是阻止更新。许多系统管理员（通常）不了解加密或安全性，因此他们毫无疑问地遵循了所接受的知识（正确或其他），并且他们不喜欢对涉及安全性的事物进行更改，因为他们不完全相信安全性一些妖术。

该自动根证书更新组件被设计为自动检查在Microsoft Windows Update网站信任当局的名单。具体来说，本地计算机上存储了一个受信任的根证书颁发机构（CA）的列表。当应用程序获得由CA颁发的证书时，它将检查受信任的根CA列表的本地副本。如果证书不在列表中，则“自动根证书更新”组件将与Microsoft Windows Update网站联系，以查看是否有可用的更新。如果已将CA添加到Microsoft可信CA列表中，则其证书将自动添加到计算机上的可信证书存储中。

为什么禁用根证书更新如此常见？

简短的答案可能是关于控制的。如果您想控制受信任的根CA（而不是使用此功能并由Microsoft帮您完成），则提出您要信任的根CA列表并将其分发到域计算机是最简单，最安全的方法。 ，然后锁定该列表。由于组织希望信任的根CA列表的更改相对很少见，因此从某种意义上说，管理员希望查看并批准任何更改，而不是允许自动更新。

坦率地说，如果没人知道为什么要在给定的环境中启用此设置，则意味着不应进行设置。

再次启用更新的潜在副作用是什么？

域计算机将被允许对照Microsoft Windows Update站点上的受信任CA列表进行检查，并有可能将新证书添加到其受信任证书存储中。

如果您的客户/客户无法接受，则GPO可以分发证书，并且他们需要在当前用于受信任证书的任何分发方法中包括您的证书。

或者，您始终可以建议暂时禁用此特定策略，以允许安装产品。

我不同意禁用此功能很常见。更好的表达方式是询问为什么有人禁用它。对于您的问题，更好的解决方案是让安装程序检查根/中间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身份验证失败。”

我禁用certif.service的原因如下：

我有许多没有互联网连接的系统。同样，在大多数情况下，由于它们是大型DatastoreServer上的虚拟机，因此它们缺少显示/ kb /鼠标。因此，在所有需要维护/修改的情况下，我都使用Windows RDP进行访问。如果您通过RDP连接到计算机，则Windows首先会在线检查证书更新。如果您的服务器/客户端没有互联网，则在继续连接之前会挂起10-20秒。

我每天都会进行很多RDP连接。我节省了几个小时，不盯着消息：“安全的远程连接” ：） +1禁用certif.service！

我知道这是一个较旧的线程；但是，我想提出一个替代解决方案。请使用与您所使用的证书颁发机构不同的证书颁发机构（ROOT CA）。换句话说，将您的签名证书切换为具有较旧的，已批准的根CA的证书。

DIGICert在请求证书时提供此服务。虽然这可能不是您的DIGICert帐户中的默认根CA，但在向其提交CSR时可以使用此选项。顺便说一句，我不为DIGICert工作，也没有通过推荐他们获得任何收益。.我只是感到这种痛苦，花了太多时间为我节省了1000美元的廉价证书，当我本可以购买更昂贵的证书并花很多钱处理支持问题的时间更少。这只是一个例子。还有其他证书提供者提供相同的功能。

99％的兼容性DigiCert根证书是世界上最受信任的权威证书之一。这样，所有常见的Web浏览器，移动设备和邮件客户端都会自动识别它们。

警告-如果在进行CSR时选择了正确的根CA。