我生成了一个自签名 SSL 证书（有效期为 5000 年）。该证书的目的是简单地加密受信任的 https 流量德诺可通过多个企业内部网站点上的多种 Web 浏览器访问的应用程序。
在我的评论中先前的问题，有人建议我可以使用域控制器上的组策略将我的自签名公共 SSL 密钥分发到 Active Directory 环境中的所有计算机。
我的目标是防止用户必须手动接受此自签名证书。
此应用程序的安全性并不是首要任务。首要任务是自动接受自签名证书。这样，即使新用户第一次使用 Chrome 或 Firefox 访问此应用程序，他们也不必手动接受证书即可查看应用程序内的页面。
如果你想知道为什么我不直接使用 http（而是使用 https），那只是因为 Web 标准中的某些功能只有在你的协议为 https 时才可用。通知 API就是一个例子。
是否有适合我的用例的完整教程？
我右键单击了此处：
这将我带到组策略编辑器，我实际上成功地在这里导入了我的自签名公钥：
但是，这并没有什么效果。例如，我登录了局域网上的几个工作站，Firefox 和 Chrome 仍然提示我手动允许证书。
在哪里可以找到针对我的确切用例和目标的详细说明。如何才能让 Chrome 和 Firefox 自动接收我尝试分发的证书的预授权？
这是我需要在多个公司内联网站点进行多次安装时完成的事情。在每个安装位置，我都需要获取活动目录来分发此证书，以便每个工作站上的所有浏览器都能接受它。
答案1
写一篇全面的教程可能不适合问答网站，但这里有一些建议。另外，这是从管理单个客户端的安装在他们自己的内部网内。例如对于 SaaS 安装，最好使用全局 FQDN 和 PKI。
作为软件供应商，您不应该：
- 实现自己的 PKI 并将其推广到您的客户端，因为它使您能够为任意主机名颁发证书，从而为您提供上帝模式覆盖其整个基础设施。
- 对具有硬编码私钥的多个客户端使用相同的自签名证书，因为它们很容易被提取并用于其他客户端。
- 结合这些错误，因为它会给每个客户一个上帝模式超越所有其他客户端。
创建自己的 PKI，而不是信任单个证书
这主要是出于安全考虑，但也更容易维护，正如您提到在多个内部网站点有多个安装。
从安全角度来看，您不希望每个应用程序都能够为任意主机名签署证书。因此，各个自签名证书不应全部都是受信任的证书颁发机构。
从维护角度来看，您不希望每次需要添加新的 Web 应用程序时都更新策略并等待它们传播。
虽然这是可取的做法，但有时无法（或不想）从外部 CA 获取证书。内联网站点可能没有全局有效的 FQDN，导致无法进行域验证，或者其与 Internet 的连接受到限制，导致难以维护证书续订。
在这种情况下，建议的替代方案是创建自己的证书颁发机构对于客户（作为软件供应商，不要将你的 PKI 推广到多个客户端）并使用它签署所有应用程序证书。这样，您只需使用 GP 将单个证书添加到受信任的证书颁发机构，并且使用它签署的每个应用程序证书都将受到信任。
如果您只需要一个小型证书颁发机构来实现此目的，那么您可以使用 OpenSSL：
生成根密钥（
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妥善保管密钥，建议离线使用，并使用组策略分发证书。
为您的应用程序创建一个证书，使用密钥和证书签名请求（
.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创建由您的 CA 签名的应用程序证书：
openssl x509 -req -in app.example.com.csr \ -CA rootCA.crt -CAkey rootCA.key -CAcreateserial \ -days 730 -sha256 \ -out app.example.com.crt在您的应用程序中使用
app.example.com.key和app.example.com.crt。
对于更重的解决方案，有Active Directory 证书服务 (AD CS)，但这确实需要一些规划，并且您的技能可能还不足以实现这一点。
使用 GPO，而不是编辑默认域策略
顺便说一句，我不会编辑默认域策略为此，请创建一个新的组策略对象 (GPO)。这样可以更轻松地限制更改的范围，例如，首先可以将它们应用于一组测试计算机。如果出现问题，还可以更轻松地恢复更改。
Firefox 有自己的证书存储区——可以使用来自 Windows 的证书
Mozilla 的 CA 证书计划管理根证书的纳入网络安全服务 (NSS)这是一组开源库，旨在支持跨平台开发启用安全性的客户端和服务器应用程序。 NSS 根证书存储在 Firefox 浏览器等 Mozilla 产品中使用，也被其他公司用于各种产品中。
这意味着默认情况下，添加到 Windows 证书存储区的证书不适用于 Firefox。为了便于维护，让 Firefox 使用安装在 Windows 上的证书颁发机构可能是一个好主意。使用自己的证书存储区对于保护隐私个人使用 Firefox，但不太适合 Windows AD 环境。幸运的是，有一种方法可以禁用它。
假设Firefox的安装目录为C:\Program Files\Mozilla Firefox\，则需要添加两个ANSI编码的配置文件：
C:\Program Files\Mozilla Firefox\defaults\pref\local-settings.js具有pref("general.config.obscure_value", 0); pref("general.config.filename", "ownsettings.cfg");这只是指下一个文件，具有实际的配置参数。
C:\Program Files\Mozilla Firefox\ownsettings.cfg具有// lockPref("security.enterprise_roots.enabled", true);重要的是实际设置从第二行开始
//！
可以使用以下方法在同一个 GPO 上分发这些文件：
Computer Configuration \ Preferences \ Windows Settings \ Files
答案2
不要将根 CA 引入其他组织
使用自签名证书并通过 Active Directory 分发它们是可能的，但相当复杂。Esa Jokinen 在他的回答中更详细地说明了这一点。
更重要的是安全隐患；根证书就像一把万能钥匙，所有由 AD 中的根证书签名的证书都将受到所有公司计算机的信任。如果你控制应用程序的根证书，那么你不能只为你的应用程序内部网络值得信赖，你可以做到对于任何域. 也适用于bigbank.com或google.com。
从本质上讲，让某人安装你的根证书会让你处于攻击所有 HTTPS 连接的位置。这意味着你需要有适当的程序来处理这些密钥、处理撤销以及处理安全漏洞。这也意味着这些公司需要非常信任你。但我认为他们不应该这样做，抱歉。
说实话，如果供应商试图将自己的根 CA 引入我的组织，而没有彻底了解所涉及的问题并制定适当的计划，我会否决他们。我甚至可能会否决那些有这些计划的供应商。
根据组织的不同，也许他们已经有自己的内部 CA；在这种情况下，你可以向他们申请证书；这可以免除你的大部分这些问题，因为 CA 管理是他们的责任，而不是你的责任。他们也只会为你的申请颁发证书。
还有其他选择吗？
考虑这种替代方法；为您的应用程序获取合适的域名，并从任何 CA 获取常规 SSL 证书。如果担心成本，有几方可以免费提供证书。我喜欢 Let's Encrypt。
对于域名，最明显的选项是company.yourapp.com和yourapp.company.com。前者更容易管理，因为获取主机名和证书在所有部署中都是标准化的。后者需要您处理客户的 IT 部门，但为他们提供了更好的集成。
顺便说一句，这两种方式都不需要你的应用程序公开访问（尽管这当然是一种选择）。域名可以简单地指向部署应用程序的公司内部的 IP 地址；你需要使用电子邮件验证或DNS 验证获取证书。
另一个选择是使用拆分 DNS；域名指向您控制的服务器，该服务器托管必要的 CA 验证内容，以便您可以获得证书。在部署应用程序的公司，他们的内部 DNS 将您的域名指向您的私有应用程序服务器。
回复一些评论
我认为，安全狂热分子过分夸大了这个问题。他们把每种情况都当成网上银行，而有时开发人员想要的只是加密数据传输。
你想要的并不存在。你可以设置“仅加密”，但当你交换加密密钥时，攻击者可以简单地拦截这些密钥并替换为自己的密钥，使他们能够读取您所有的加密流量。证书确保浏览器实际上是在与目标服务器交换密钥，而不是与攻击者交换密钥。这部分对于安全加密是必需的。
最后，身份验证对于获取加密通信至关重要；它不是可选的。
事实是，自签名证书可以提供与美国银行使用的相同级别的加密（在数据传输期间）。
只有当您能够设法正确分发这些证书时才可以。如果只有一台本地计算机需要证书，这很容易，但它的可扩展性非常差，并且变得非常对于任意数量的计算机来说，这都很难正确完成。
这就是我们使用证书颁发机构的原因；它们提供了一种以可扩展且合理安全的方式分发证书的方法。
在我看来，通过私有 IP 地址提供服务的应用程序不应该遵循与国际银行相同的规则。
问题是，计算机没有常识。它们不明白访问银行网站需要良好的安全性，但访问你的应用程序时，安全性是可以的。它们不能理解这一点。他们不应该尝试。如果你的应用程序开始处理医疗记录怎么办？突然间，接受应用程序安全性的“常识”变得不可接受。计算机无法知道这种区别。
如果计算机必须接受您网站上的松散安全措施，那么它们也必须接受其他网站上的松散安全措施。幸运的是，我们已经到了无法接受这种措施的地步。接受它，并自豪地为您的应用程序提供与银行相同的加密技术！
这给开发者带来了可怕的、不必要的负担
不，不是的。
是的，使用 HTTPS 保护网站会给开发人员带来一些负担，这就是生活。说它很糟糕或不必要，这太夸大其词了。
老实说，只需在您的网站上贴上一些 Let's Encrypt 证书即可。它能为您提供所需的安全性（外加一些额外的安全性），而且比抱怨所有这些要省力得多。它也比尝试成为客户的 CA 更省力、更安全。
答案3
由于安全宣讲已经结束，因此您可以继续做出明智的决定，让我对您的问题给出一个简单的答案：
- 您已经找到的方法确实有效，但仅适用于实际使用 Windows 证书存储的浏览器，例如 IE、Edge 以及 Chrome（以及其他浏览器 - 尚未找到确切列表）
- Firefox 可以遵守，但它需要添加和使用 ADMX 模板，参考。 Friefox 支持
旁注：Google 确实计划将他们自己的 CA 存储引入 Chrome（据我所知尚未达到 ETA），但表示 OS 企业根 ca 存储仍然可用，参考。Chrome Root 程序
如果您是一家为组织管理受信任 CA（包括本地安装的企业 CA）的企业，则本文档中描述的政策不适用于您的 CA。目前，企业管理员在 Chrome 中管理这些 CA 的方式尚未计划进行任何更改。设备所有者或管理员已安装到操作系统信任存储中的 CA 预计将继续像现在一样工作。