最初的问题
我们制造运行网络服务器的设备，用户可以通过直接浏览设备的 IP 来控制设备的某些功能。当使用直接 WiFi 或以太网连接时，这可能是一个固定 IP，但在大多数情况下，这是设备从网络中的 DHCP 服务器收到的 IP。
越来越多的 HTTPS 需要访问浏览器的一些更高级的功能。例如，访问缓存（https://developer.mozilla.org/en-US/docs/Web/API/Cache）以允许使用网络摄像头（https://blog.mozilla.org/webrtc/camera-microphone-require-https-in-firefox-68/)、服务工作者（https://www.digicert.com/dc/blog/https-only-features-in-browsers/),......这个名单每天都在不断增加。
我非常赞成建立安全系统，但我认为有一个主要问题。HTTPS（TLS）的设置方式是，只有当域名与证书中的域名匹配并且证书颁发机构被客户端浏览器接受时，证书才会被标记为有效，这就是所谓的信任链。这在使用固定主机名的网络上非常有效。
但是，当用户不使用互联网而是使用本地网络时，主机名是无法预先知道的。有时用户可以使用本地 DNS、mDNS，但情况并非总是如此。很多时候用户只使用内部 IPv4 地址。这就是问题开始的地方，因为使用我们制造的设备有两种选择：
- 用户不使用 HTTPS（我们不强制执行，请继续阅读以了解原因）。目前主流浏览器不会给出明确警告，但会用浅灰色将页面标记为“不安全”。大多数用户甚至没有注意到这一点，并且非常高兴。
- 用户在同一设备上使用 HTTPS。尽管这使得连接更安全，但浏览器现在明确告诉他们要极其谨慎地使用该设备，并且连接可能被黑客入侵，私人数据可能被盗。该网站现在用红色标记为“不安全”，用户必须按 2 或 3 个按钮才能允许证书例外。
第二个选项是我们不强制设备通过 HTTPS 访问的原因，因为这只会让许多用户感到恐慌，并导致客户服务大量中断。五年前，这并不是什么大问题，因为所有事情都可以在没有 HTTPS 的情况下完成。随着越来越多的 API 现在仅在“安全上下文”中工作，这对我们来说确实是一个问题。
因此，我认为迫切需要设计一个系统，在内部网络中严格使用不带主机名系统的 HTTPS。我可以想象，私有 IPv4 范围可以从警告中排除，或者采取更聪明的方法。这让我想到一个问题，您是否面临同样的问题，如何解决这个问题？
更新 1
正如第一条评论所指出的，现在提出的解决方案是使用通配符证书并在公共域上为设备配置 DNS 条目。然而，这存在一个问题，即客户端仍然需要有效的互联网连接。在这种设置中，情况当然并非总是如此。
更新 2
我还发现了有关 Let's encrypt 的这篇文章，它讨论了同一主题，但没有提供解决方案：https://letsencrypt.org/docs/certificates-for-localhost/
更新 3：假设的解决方案
阅读完以下答案和评论后，我考虑了该问题可能的安全解决方案。以下设置（如果允许）是否安全？
- 从具有名称约束的受信任根 CA 请求中间 CA 证书，该名称约束仅允许它创建多个中间 CA，这些中间 CA 只能为单个固定主机名“*.mydevice.local”或类似名称创建证书，并允许在 SAN 中使用所有私有 IPv4 地址。
- 每个部署的设备在工厂都会安装一个唯一的中间 CA，该 CA 由我在步骤 1 中谈到的中间 CA 创建。这个设备上的 CA 的名称将被限制在“.mydevice.local”上。
- 每次设备更改 IP 地址（启动、DHCP 更改等）时，它都能够使用设备上的中间 CA 生成证书。
我认为这可以彻底解决问题，并且具有以下优点：
- 没有浏览器警告，因为信任链会传递回受信任的根 CA。
- 每个设备都有一个唯一的证书。
- 单个中间 CA 的泄露不是什么大问题，因为它只能用于为设备特定的固定主机名创建受信任的证书。
如果我忽略了什么，请发表评论。
更新 4：
我想感谢大家的帮助和思考。对我来说，结论是证书背后的整个想法和信任链不允许我想要的东西。这是因为 CA 根本无法确保我指向的内部 IP 地址是由我想要访问的设备唯一拥有的。内部 IP（例如 192.168.0.10）由数千台设备拥有，因此不可能授予允许浏览器不显示警告的证书。
唯一的选择是通过手动干预进行证书验证（安装设备证书、将您自己的设备的 CA 推送给用户，以及答案中提出的各种更复杂的选项）。这只是我需要忍受的事情。
尽管如此，我想我还是要向 Firefox 和 Chrome 开一张票。因为我认为对于内部 IP 地址，一个简单的灰色不安全警告（与 HTTP 一样）就足够了。只有在使用 HTTPS 时（其设计用例），才应显示红色警告。
更新 5：
我已经在 Bugzilla 提交了一个错误报告：https://bugzilla.mozilla.org/show_bug.cgi?id=1705543我发布此链接作为参考，以便任何人都可以关注该问题。
答案1
步骤 1：让设备在首次设置时或 IP 地址更改时为其 IP 地址和/或主机名生成自签名证书，除非有客户提供的证书。请勿出售带有通用证书的设备（请参阅您链接的 Let's Encrypt 文章）。
第 2 步：让您的文档描述如何识别您的特定自签名证书并在通用浏览器中接受它们。
步骤 3：让您的文档描述如何使用组织自己的证书颁发机构或公共 CA 生成的另一个证书替换自签名证书。
答案2
在我们的一个项目中，我们遇到了一个问题，即我们想从互联网提供的网页连接到本地网络上的 websocket。为了使用安全的 web 套接字连接 (wss://)，我们需要 SSL 证书，但无法为本地 IP 获取证书。最重要的是，我们无法更改客户端计算机配置（没有 /etc/hosts，无法导入自己的 CA）。
在寻找解决方案时，我们受到了服务 xip.io 的启发，并提出了一个想法，我们可以使用通配符 SSL 证书，并稍微改变xip.io 的方法就是将本地 IP（不带点）放入 URL 中 - 获取符合通配符 SSL 的子域。因此，我们启动了自定义 DNS 服务，其工作方式如下：
dig 10-0-0-1.my.local-ip.co
;; ANSWER SECTION:
10-0-0-1.my.local-ip.co. 299 IN A 10.0.0.1
并且我们在网站上免费提供域名 *.my.local-ip.co 的 SSL 证书http://本地 ip.co
唯一的缺点是您仍然需要互联网连接才能运行它，但另一方面，您不必安装或配置任何东西来运行它......
欢呼吧，Marcin
答案3
我在目前的工作中广泛处理过这个问题 - 包括高度重视离线工作问题。我提出这个问题的前提是，添加自定义根 CA 等企业元素不合适或不切实际。
首先要记住的是，如果他们在离线时没有可用的 DNS 服务器 - 未经手动修改和检查的私有 (RFC 1918) IP 地址的 TLS 将不起作用。如果这是一个无法解决的真正问题 - 文档和用户培训是您唯一真正的选择。
如果部署超出了您的物理控制范围，通配符证书将是一个可怕的提议。被黑客入侵并提取的通配符证书可能会被恶意方利用来造成大量破坏。
另请记住，更多浏览器不接受较长的证书有效期窗口（请参阅这对于最近的 Apple/iOS 版本 - 将证书有效期限制为一年多一点）
我建议投资基础设施以自动化证书部署。我们还可以控制dnsmasq设备上的小型服务器，该服务器提供所需的 DNS 和 DHCP 方面 - 再次由部署自动化控制，以确保它是最新的。如果不了解您的解决方案和销售模式，很难判断这是否适合您。即：我们的解决方案不是静态的，并且有一个小型 4G 网关 - 因此只要每隔几个月通话一次，互联网损失就没问题。
在我看来，Puppet 非常适合互联网受限的设备（与当前开发运营宠儿 Ansible 相反），因为代理方面允许设备在有机会时尝试自行部署 - 并且在 NAT 的 IPv4 网关后面运行良好。
答案4
我不确定您的环境，所以会做出一些假设，如果我错了，请纠正我。
执行此操作的标准方法是使用活动目录推出新的根证书，您可以根据需要签署任意数量的证书，包括 IP 地址，以 HTTPS IP 检查的公共示例https://1.1.1.1/
这在本地是可以实现的。
如果您正在运行此类设置，那么推动 DNS 更改（因此人们改用 app.company.com）也很容易，您的 DNS 服务器应该能够配置为响应您想要的任何查询。运行仅返回内部 DNS 而没有互联网访问的本地 DNS 服务器是您需要维护的另一部分基础设施（假设它还没有，DCHP 应该为您提供 DNS 服务器，所以请先查看它）
如果人们使用它来开发，使用https://github.com/FiloSottile/mkcert它真的很容易使用并提供受信任的证书（再次将它们插入到所有信任存储中） - 这是第一个选项的自动版本。
回答为什么排除私有 IP 的问题，私有网络上更容易重新路由流量，如果攻击者进入，他们可以通过 arp 欺骗服务器，获取所有流量，然后控制服务器的所有输入（可能包含用户登录信息），而最终用户永远不会知道。拥有有效的证书更难欺骗，虽然攻击者可以获得流量，但所有用户都会看到“这不安全”页面，因为 TLS 步骤会失败。本地网络也需要安全。