我正在开发一款网络管理产品。我们将产品以虚拟机的形式发送给客户，客户会将虚拟机安装在其网络中的虚拟机管理程序上。这些虚拟机在客户网络中被赋予静态的私有 IP 地址。它们监控客户的设备，并运行 (Apache/Django) Web 服务器以显示网络状态。客户通过私有 IP 访问站点，我们使用 TeamViewer（在发货前安装）直接访问虚拟机，因此不涉及公共 IP 或域名。我们非常希望在我们的虚拟机上提供 SSL 证书，这样客户就不会再看到我们站点不安全的通知（当然，这样我们的网站就不会再不安全了）。最好是，客户不必为新的 CA 添加信任或在其浏览器中添加安全例外。
最有效且最具成本效益的方法是什么？我尝试过 LetsEncrypt，但它们仅支持域名证书，而不支持 IP 证书。
答案1
只需像以前一样使用自签名证书，不要尝试任何肮脏的黑客来绕过错误。为您的客户提供用自己的证书替换该证书的选项。替换证书可以由公共 CA 使用他们自己的公共（子）域名签名，也可以由本地受信任的 CA（例如使用 Active Directory 证书服务）签名。无论哪种方式，它始终与他们的基础架构和安全策略兼容。
答案2
您可以设置一个带有 DNS 服务器的域，以便为 DNS 请求返回私有 IP 地址。这就是我在这里所做的。
$ resolveip node-1.example.com
IP address of node-1.example.com is 192.168.1.71
这样你就可以使用基于名称的 tls 证书，并获取有效的 dns
答案3
问题中有一些相互矛盾的要求，我建议您使用域名而不是 IP 地址来解决。
您向浏览器已经信任的 CA 申请内部 IP 地址证书。但是，如果 CA 颁发此类证书，浏览器可能会不再信任该 CA，这违背了您选择该 CA 的初衷。
但是，您可以获得真实域名的证书，并将该名称指向内部 IP 地址。此时，需要做出几个决定。其中一个决定取决于您首先使用内部 IP 地址的原因。您使用内部 IP 地址是因为 IP 地址短缺，还是您使用内部 IP 地址作为访问控制的方法？
对于我的其余回答，我假设您将其用作访问控制方法。如果您只是因为 IP 地址短缺而这样做，还有其他可能更简单的解决方案。
为了颁发证书，LetsEncrypt 需要向域发送 HTTP 请求，因此域必须解析为 LetsEncrypt 可访问的真实 IP 地址。您将 LetsEncrypt 定向到的服务器是您生成证书的服务器，它不必与您最终使用证书的服务器相同。由于您希望使用证书对虚拟机进行严格的访问控制，因此您可能希望 LetsEncrypt 与其他服务器通信。
您永远不希望生成证书的服务器实际使用它，而是将其复制到客户站点上的 VM。
然后，您将在最终用户站点上覆盖其 DNS 配置中的该域名以指向 VM 的本地 IP。
所有这些都可以通过在每个客户站点对每个虚拟机使用相同的名称来完成。但使用相同的名称会带来安全风险，因为您的任何客户都可以访问可能用于对付其他客户的证书。相反，我建议您注册一个域名并为每个虚拟机创建一个子域（不要将这些名称放在用于其他目的的常规域名下）。如果您已经注册example.com，则可以为customername.example.com每个虚拟机使用类似的名称（或者，如果客户不希望他们的名字出现在您选择的 CA 的审计记录中，则将 customername 替换为不同的值）。
不应强迫客户使用 的子域名example.com。您可以将其作为默认设置。但您还应允许客户提供自己的域名，在这种情况下，他们还必须提供自己的证书。为此，您可以让 VM 导出可由 CA 签名的 CSR，也可以实现与 LetsEncrypt 的集成。
答案4
我们计划采用这里发布的几种不同的选择。
1) 对于拥有自己的 CA 基础设施（ADCS 或其他）的客户，我们将使用他们的一个证书。
2) 对于没有 CA 但有 DNS 的客户，我们将获得 *.productname.com 的通配符证书，并让客户 IT 在其网络中添加指向我们 VM 的 DNS 记录。据我了解，我们将能够将此通配符证书用于所有此类客户。
3) 对于没有 CA 和内部 DNS 的客户端，我们将使用自签名证书，并让客户端用户手动将其添加到浏览器中。我希望避免这种情况，但唯一的其他选择是使用通配符证书和指向其网络中私有 IP 的公共 DNS 记录。这会泄露有关我们客户网络（至少是我们服务器的 IP）和我们客户列表的信息，这对我们来说是行不通的。