在 Active Directory 环境中向所有浏览器分发 SSL 证书

Question

我生成了一个自签名 SSL 证书（有效期为 5000 年）。该证书的目的是简单地加密受信任deno应用程序的 https 流量，该应用程序可被多个公司内部网站上的各种 Web 浏览器访问。

在我之前的问题的评论中，有人建议我可以使用域控制器上的组策略将我的自签名公共 SSL 密钥分发到 Active Directory 环境中的所有计算机。

我的目标是防止用户必须手动接受此自签名证书。

此应用程序的安全性不是重中之重。首要任务是自动接受自签名证书。这样即使新用户第一次使用 Chrome 或 Firefox 访问此应用程序，他们也无需手动接受证书即可查看应用程序中的页面。

如果您想知道为什么我不只是使用 http（而不是 https），那只是因为 Web 标准中的某些功能不可用，除非您的协议是 https。该通知API是一个例子。

是否存在适用于我的用例的完整教程？

我在这里右键单击：

这把我带到了组策略编辑器，我实际上成功地在这里导入了我的自签名公钥：

然而，这没有效果。例如，我登录到局域网上的几个工作站，在 Firefox 和 Chrome 中仍然提示我手动允许证书。

我在哪里可以找到有关我的确切用例和目标的详细说明。我如何才能让 Chrome 和 Firefox 自动接收我尝试分发的证书的预授权？

这是我需要在多个公司 Intranet 站点进行多次安装时完成的任务。在每个安装位置，我需要获取活动目录来分发此证书，以便每个工作站上的所有浏览器都能接受它。

Answer 1

就此编写全面的教程可能不适合问答网站，但这里有一些建议。此外，这是从管理单个客户端在其自己的 Intranet 中安装的角度来看的。对于例如 SaaS 安装，最好使用全局 FQDN 和 PKI。

作为软件供应商，您不应该：

• 实施自己的 PKI 并将其推送到您的客户端，因为它使您能够为任意名称颁发证书，为您的整个基础架构提供上帝模式。
• 对具有硬编码私钥的多个客户端使用相同的自签名证书，因为它们可以很容易地被提取出来并用于其他客户端。
• 结合这些错误，因为它会给每个客户一个上帝模式，而不是所有其他客户。

创建您自己的 PKI 而不是信任单个证书

这主要是出于安全考虑，但也更易于维护，正如您提到的在多个 Intranet 站点上有多个安装。

• 从安全角度来看，您不希望每个应用程序都能够为任意主机名签署证书。因此，单个自签名证书不应都是受信任的证书颁发机构。

• 从维护的角度来看，您不想在每次需要添加新的 Web 应用程序时更新您的策略并等待它们传播。

• 虽然更可取，但有时不可能（或不想）从外部 CA 获取证书。Intranet 站点可能没有全球有效的 FQDN，从而无法进行域验证，或者它们与 Internet 的连接受到限制，从而更难维护证书续订。

在这种情况下，推荐的替代方法是为客户端创建自己的证书颁发机构（不要将您的 PKI 作为软件供应商推送给多个客户端）并用它签署所有应用程序证书。这样，您只需要使用 GP 将单个证书添加到受信任的证书颁发机构，并且每个使用它签名的应用程序证书都将受到信任。

如果您只需要一个很小的证书颁发机构，您可以使用 OpenSSL：

1. 生成根密钥 ( rootCA.key) 和根证书 ( rootCA.crt)。

   openssl genrsa -aes256 -out rootCA.key 4096
   openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 7300 -out rootCA.crt
   

   保持密钥安全，建议脱机，并使用组策略分发证书。
   
   

2. 以密钥和证书签名请求( .csr)开头，为您的应用程序创建证书。

   openssl genrsa -out app.example.com.key 2048
   
   openssl req -new -sha256 \
       -key app.example.com.key \
       -subj "/C=US/ST=CA/O=My Application/CN=app.example.com" \
       -out app.example.com.csr
   

3. 创建一个由您的 CA 签名的应用程序证书：

   openssl x509 -req -in app.example.com.csr \
       -CA rootCA.crt -CAkey rootCA.key -CAcreateserial \
       -days 730 -sha256 \
       -out app.example.com.crt
   

4. 在您的应用程序中使用app.example.com.key和app.example.com.crt。

对于较重的解决方案，有Active Directory 证书服务 (AD CS)，但这确实需要一些规划，而且您的技能组合可能还不够。

使用 GPO 而不是编辑默认域策略

作为旁注，我不会为此编辑默认域策略，而是创建一个新的组策略对象 (GPO)。它可以更容易地限制更改的范围，例如，首先可以将它们应用于一组测试计算机。如果出现问题，它还可以更轻松地还原更改。

Firefox 有自己的证书库——可以使用来自 Windows 的证书

Mozilla 的 CA 证书计划管理网络安全服务 (NSS) 中包含的根证书，NSS是一组开源库，旨在支持启用安全的客户端和服务器应用程序的跨平台开发。NSS 根证书存储用于 Mozilla 产品，例如 Firefox 浏览器，也被其他公司用于各种产品。

这意味着默认情况下，添加到 Windows 证书存储的证书不适用于 Firefox。为了便于维护，让 Firefox 使用安装在 Windows 上的证书颁发机构可能是个好主意。使用自己的证书存储是保护使用 Firefox 的个人隐私的好主意，但不适用于 Windows AD 环境。幸运的是，有一种方法可以禁用它。

假设Firefox的安装目录为C:\Program Files\Mozilla Firefox\，则需要添加两个ANSI编码的配置文件：

1. C:\Program Files\Mozilla Firefox\defaults\pref\local-settings.js 有

   pref("general.config.obscure_value", 0); 
   pref("general.config.filename", "ownsettings.cfg");
   

   这只是指下一个文件，具有实际的配置参数。

2. C:\Program Files\Mozilla Firefox\ownsettings.cfg 有

   //
   lockPref("security.enterprise_roots.enabled", true);
   

   重要的是实际设置从第二行开始//！

这些文件可以使用以下方式分布在同一个 GPO 上：

Computer Configuration \ Preferences \ Windows Settings \ Files

Answer 2

不要将根 CA 引入其他组织

使用自签名证书并通过 Active Directory 分发它们是可能的，但相当复杂。Esa Jokinen 在他的回答中更详细地说明了这一点。

更重要的是安全隐患；根证书就像一个万能钥匙，AD中根证书签署的所有证书都将被所有公司计算机信任。如果您在应用程序中控制根证书，那么您不能只为您的app.intranet创建一个可信任的证书，您可以为任何域创建证书。也适用于bigbank.com或google.com。

从本质上讲，让某人安装您的根证书使您能够攻击他们的所有 HTTPS 连接。这意味着您需要有适当的程序来处理这些密钥、处理撤销以及处理安全漏洞。这也意味着这些公司需要非常信任你。我认为他们不应该，抱歉。

老实说，如果供应商试图将他们自己的根 CA 引入我的组织，而没有彻底了解所涉及的问题并为所有事情制定适当的计划，我会否决他们。我什至可能会否决这些计划。

根据组织的不同，他们可能已经拥有自己的内部 CA；在这种情况下，您可以向他们索取证书；这使您免于大多数这些问题，因为 CA 管理是他们的责任，而不是您责任。他们也只会为您的申请提供证书。

有替代方案吗？

考虑这种替代方法；为您的应用程序获取合适的域名，并从任何 CA 获取常规 SSL 证书。如果担心成本，有几个团体免费提供证书。我喜欢让我们加密。

对于域名，最明显的选项是company.yourapp.com和yourapp.company.com。第一个对您来说更容易管理，因为获取主机名和证书在所有部署中都是标准化的。后者要求您处理客户的 IT，但为他们提供更好的集成。

顺便说一句，这些选项都不需要您的应用程序可公开访问（尽管这当然是一个选项）。该域可以简单地指向部署应用程序的公司内部的 IP 地址；您需要使用电子邮件验证或DNS 验证来获取证书。

另一种选择是使用 split-DNS；该域指向您控制下的服务器，该服务器承载必要的 CA 验证内容，以便您可以获得证书。在您部署应用程序的公司，他们的内部 DNS 将您的域指向您的私有应用程序服务器。

回复一些评论

在我看来，安全狂热者夸大了这个话题。他们像对待网上银行一样对待每一种情况，有时开发人员想要的只是加密数据传输。

你想要的不存在。您可以设置“仅加密”，但是当您交换加密密钥时，攻击者可以简单地拦截这些密钥并替换他们自己的密钥，从而使他们能够读取您的所有加密流量。证书确保浏览器实际上是在与目标服务器而不是与攻击者交换密钥。这部分是安全加密所必需的。

最后，身份验证是获得加密通信不可或缺的一部分；它不是可选的。

事实是，自签名证书可以提供与美国银行使用的加密级别相同的加密级别（在数据传输期间）。

仅当您可以设法正确分发这些证书时。这很容易，如果这是一个需要证书只是一个本地计算机，但它做的非常不好，而且变得非常难以电脑任意数量的正确事情。

这就是我们使用证书颁发机构的原因；它们提供了一种以可扩展且合理安全的方式分发证书的方法。

在我看来，从私有 IP 地址提供的应用程序不应该遵循与国际银行相同的规则。

问题是，计算机没有常识。他们不明白访问银行网站需要良好的安全性，但是 ehhh 安全性对于访问您的应用程序来说是可以的。他们无法理解这一点。他们不应该尝试。如果您的应用开始处理病历怎么办？突然间，为您的应用接受 ehhh 安全性的“常识”是不可接受的。计算机无法识别这种区别。

如果计算机必须在您的站点上接受草率的安全性，那么它们也必须在其他站点上接受它。幸运的是，我们已经到了无法接受的地步。接受它，并自豪地为您的应用程序提供与银行相同的加密货币！

它给开发人员带来了可怕的不必要的负担

不，它没有。

是的，使用 HTTPS 保护网站会给开发人员带来一些负担，这就是生活。称它为可怕或不必要的事情是不成比例的。

老实说，只需在您的网站上使用一些 Let's Encrypt 证书即可。它为您提供了您想要的安全性（加上一点额外的），而且比抱怨所有这些更省力。与尝试成为客户的 CA 相比，这也更省力、更安全。