在专用网络上启用 HTTPS

Question 1

如果您的内部域名与外部域名匹配（例如sales.corp.example.com），您仍然可以从大多数公共 CA 获得证书，因为它们将接受所有权，example.com假设所有者[email protected]//[email protected]任何人乐意批准您的证书请求。该网站本身不需要通过互联网访问。还有其他提供商实施 Let's Encrypt 的 ACME 协议，因此如果您不能遵守他们的要求，您仍然可以使用其他提供商的相同协议。

如果您的内部域名没有任何部分是可以公开解析的（例如，您使用了类似的假 TLD sales.corp.example.local），那么您唯一的选择就是使用内部 CA。

如果您想使用内部 CA 来签署证书，则需要将该 CA 安装为所有设备上的受信任提供商。如果您想“正确”地执行此操作，则设置起来相当麻烦（通常，您有一个离线的根 CA，它会签署一个实际上签署您证书的下属 CA）。您需要制定流程来在根证书到期时轮换它们，并制定分发它们的方法（如果您完全集成在没有 Linux 设备的 Windows 域中，这实际上并不难）。

以前，可以去 CA 要求他们为内部域颁发证书，并经过漫长而昂贵的验证程序，但是 2012 年 7 月 1 日引入的新程序禁止任何 CA 从 2015 年起颁发任何包含内部通用名称的证书，并在 2016 年之前撤销现有证书。所以，除非你有时光机，否则这不会发生。

作为旁白：

客户安装软件即可使用

这几乎不可能发生。多年来，我安装了很多企业软件，TLS 配置总是需要手动完成。有很多原因导致您无法假设可以自动配置证书：

客户可能无法从主机访问互联网，因此您无法联系外部机构
客户可能拥有非常有限的已批准 CA 列表，并且您必须拥有由他们颁发的证书
客户可能需要审核针对内部主机名颁发的所有证书

事实上，如果您的设备在我的网络上，并且开箱即用，并且带有自动配置的、有效的、受信任的 SSL 证书，我会非常怀疑。有很多设备允许您一键配置 Let's Encrypt，但这绝不是默认设置。它始终是可选的。

Answer

如果您的内部域名与外部域名匹配（例如sales.corp.example.com），您仍然可以从大多数公共 CA 获得证书，因为它们将接受所有权，example.com假设所有者[email protected]//[email protected]任何人乐意批准您的证书请求。该网站本身不需要通过互联网访问。还有其他提供商实施 Let's Encrypt 的 ACME 协议，因此如果您不能遵守他们的要求，您仍然可以使用其他提供商的相同协议。

如果您的内部域名没有任何部分是可以公开解析的（例如，您使用了类似的假 TLD sales.corp.example.local），那么您唯一的选择就是使用内部 CA。

如果您想使用内部 CA 来签署证书，则需要将该 CA 安装为所有设备上的受信任提供商。如果您想“正确”地执行此操作，则设置起来相当麻烦（通常，您有一个离线的根 CA，它会签署一个实际上签署您证书的下属 CA）。您需要制定流程来在根证书到期时轮换它们，并制定分发它们的方法（如果您完全集成在没有 Linux 设备的 Windows 域中，这实际上并不难）。

以前，可以去 CA 要求他们为内部域颁发证书，并经过漫长而昂贵的验证程序，但是 2012 年 7 月 1 日引入的新程序禁止任何 CA 从 2015 年起颁发任何包含内部通用名称的证书，并在 2016 年之前撤销现有证书。所以，除非你有时光机，否则这不会发生。

作为旁白：

客户安装软件即可使用

这几乎不可能发生。多年来，我安装了很多企业软件，TLS 配置总是需要手动完成。有很多原因导致您无法假设可以自动配置证书：

客户可能无法从主机访问互联网，因此您无法联系外部机构
客户可能拥有非常有限的已批准 CA 列表，并且您必须拥有由他们颁发的证书
客户可能需要审核针对内部主机名颁发的所有证书

事实上，如果您的设备在我的网络上，并且开箱即用，并且带有自动配置的、有效的、受信任的 SSL 证书，我会非常怀疑。有很多设备允许您一键配置 Let's Encrypt，但这绝不是默认设置。它始终是可选的。

Question 2

无需手动操作。客户安装软件即可使用。

如果您不控制最终用户设备，则无需采取额外步骤，这意味着您必须使用其根证书存储（操作系统或浏览器）中已有的 CA。客户的内部 PKI 可以签署您的证书，但前提是他们有一个证书，并且它不适用于非托管设备。这就剩下一个众所周知的“公共”CA。

该网站可能是仅供内部使用的网站。（https://letsencrypt.org/ 无法到达。）

所有权挑战不必来自获得证书的主机。您提到了 Let's Encrypt，他们的 DNS 挑战可以从任何 Internet 可见的 DNS 进行。包括通配符，因此您可以发出*.present.example.com。

Answer

无需手动操作。客户安装软件即可使用。

如果您不控制最终用户设备，则无需采取额外步骤，这意味着您必须使用其根证书存储（操作系统或浏览器）中已有的 CA。客户的内部 PKI 可以签署您的证书，但前提是他们有一个证书，并且它不适用于非托管设备。这就剩下一个众所周知的“公共”CA。

该网站可能是仅供内部使用的网站。（https://letsencrypt.org/ 无法到达。）

所有权挑战不必来自获得证书的主机。您提到了 Let's Encrypt，他们的 DNS 挑战可以从任何 Internet 可见的 DNS 进行。包括通配符，因此您可以发出*.present.example.com。

Question 3

在我的公司，我们有多个仅供内部网使用的网站。由于最近/当前的浏览器策略更改，我们已为它们设置了 HTTPS/TLS 支持。

由于这些网站仅供内部使用，我们决定使用 Microsoft Active Directory 证书颁发机构 (MS AD CA) 服务设置内部证书颁发机构。此外，我们还为网站使用 [公司名称].local URL。

使用 AD CA 服务，我们创建了一个 RootCA 证书，该证书通过域控制器分发给所有与域连接的系统。然后，使用 AD CA 服务，我们能够为各种内部网站和具有 Web 界面的设备颁发证书。

然后，我们使用 Active Directory DNS 服务设置 [公司名称].本地域，以将正确的 IP 地址分配给正确的 URL。因为内部 AD DNS 是我们网络的主要 DNS。

这种方法给我们带来的唯一问题是 Firefox 浏览器不使用 Windows 证书存储，需要手动导入创建的 RootCA 证书。根据我有限的研究，似乎确实可以将 RootCA 证书自动导入 Firefox 证书存储，但由于 Firefox 用户数量有限，我们决定采用手动方法。此外，如果我没记错的话，Firefox 开发团队正在等待功能请求单，以启用对 Windows 证书存储的访问。

对于我们的情况来说，这似乎是最可靠的解决方案，您的情况可能会有所不同:)

对于任何面向外部的网站，我们都使用来自信誉良好来源的证书。

Answer