小编Daa*_*ape的帖子

初始问题

我们制造运行网络服务器的设备，用户可以通过直接浏览设备的 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/ ), Service Workers ( https://www.digicert.com/dc/blog/https-only-features-in-browsers/ ), ...列表保留每天都在成长。

我都赞成拥有安全系统，但我认为存在一个主要问题。HTTPS (TLS) 设置证书的方式仅在域名与证书中的域名匹配并且证书颁发机构被客户端浏览器接受时才被标记为有效，即所谓的信任链。这在使用固定主机名的网络上非常有效。

然而，当用户不使用互联网而是使用他们的本地网络时，主机名是事先不知道的。有时用户可以使用本地 DNS、mDNS，但情况并非总是如此。很多时候用户只使用内部 IPv4 地址。这是问题开始的地方，因为使用我们制造的设备有两种选择：

1. 用户不使用 HTTPS（我们不强制执行，请继续阅读以了解原因）。目前的主要浏览器不会给出明确的警告，而是将页面标记为浅灰色的“不安全”。大多数用户甚至没有注意到它并且非常高兴。
2. 用户在同一设备上使用 HTTPS。尽管这使得连接更加安全，但浏览器现在明确告诉他们要极其谨慎地使用该设备，并且连接可能被黑客入侵，私人数据可能会被盗。该站点现在以红色标记为“不安全”，用户必须按 2 或 3 个按钮以允许证书例外。

选项 2 是我们不强制设备通过 HTTPS 访问的原因，因为它只是向许多用户发出警报并淹没客户服务。五年前，这并不是真正的问题，因为没有 HTTPS 一切都可以完成。随着越来越多的 API 现在只能在“安全上下文”中工作，这对我们来说真的是一个问题。

因此，我认为设计一个完全在内部网络中使用 HTTPS 而不使用主机名系统的系统的需求变得非常大。我可以想象私有 IPv4 范围可以从警告或更聪明的东西中排除。这让我想到我的问题，您是否面临同样的问题，如何解决？

更新 1

正如第一条评论中所指出的，现在提出的解决方案是使用通配符证书并为公共域上的设备配置 DNS 条目。然而，这存在客户端仍然需要活动互联网连接的问题。在此类设置中，情况当然并非总是如此。

更新 2

我还发现了这篇关于 Let's encrypt 的文章，它在没有给出解决方案的情况下讨论了同一主题：https : //letsencrypt.org/docs/certificates-for-localhost/

更新三：假设的解决思路

阅读以下答案和评论后，我正在考虑针对该问题的可能的安全解决方案。下面的设置（如果允许的话）是否安全？

1. 从具有名称约束的受信任根 CA 请求中间 CA 证书，该证书仅允许创建多个中间 CA，这些中间 CA 只能为单个固定主机名“*.mydevice.local”或类似内容创建证书，并允许所有私有 IPv4 地址在 SAN 中使用。 …