我们正在将相同的自签名证书安装到每个开发和原型单元中。

在每个单元中安装相同的证书是处理证书时可以想象的最糟糕的安全实践。我们现在知道不要发布具有默认硬编码管理凭据的产品。我们避免使用默认凭据，因为此类凭据可以被提取一次并用于破坏所有实现它们的设备。这是一个非常相似的情况——默认证书意味着可以提取一次私钥并用于破坏依赖此证书的所有设备。

在密码学上，自签名证书和受信任的第三方证书都以相同的方式运行。每个证书都与一个密钥对相关联，该密钥对由一个秘密私钥和一个非秘密公钥组成。如果您知道私钥，那么您可以执行与公钥和证书相关的所有操作。

破坏默认证书的意义不仅仅是破坏身份验证。对于 TLS，根据使用的密码，证书最终可能被用于建立共享机密。在这种情况下，被动窃听者将能够在看到初始握手后解密 TLS 流量。

当然，有能力的管理员会通过上传他们自己的唯一证书来解决这个问题，但是有多少人会通过信任默认证书而真正停止在“让它工作”阶段？您应该做的是在初始启动或出厂重置时生成一个新的密钥对。这就是安全网络设备的运行方式。生成新证书时，您还必须确保系统中有足够的可用熵，并且最终不会生成可分解的密钥。

客户将能够提供他们自己的证书，以他们希望的任何方式（公开或私下）签名。这将为他们提供信任链，并使他们能够确定他们确实连接到该系统。

这表明A ) 典型安装将具有“真实”域名，在公共 Internet 上可见（与 Intranet 域名或私有 IP 地址相反）或B ) 典型客户将具有操作所需的技术知识他们自己的内部证书颁发机构。

如果 (A) 为真，那么您的产品可以拨出到Let's Encrypt并以这种方式获得签名证书。这要求该服务具有“真实”域名，并且对公共互联网完全可见（即它在端口 80 和/或 443 上没有防火墙）。Let's Encrypt 证书可以以完全自动化的方式获取，不需要任何手动步骤，只要您知道并控制（可以提供来自）FQDN 的网络流量。自然，您应该以合理“礼貌”的方式与服务交互，特别是考虑到它是免费的（即不要一次向它发送大量请求，实施指数重试退避等）。

如果 (B) 为真，那么您绝对应该选择您描述的选项（即让客户提供证书），因为您的客户比您更有能力解决这个问题。然而，在大多数行业中，(B) 是不正确的。然而，一个足够冒险的客户可能想要这样做的选项，所以无论如何你都应该提供它。

如果 (A) 和 (B) 都不正确，那么您应该遵循其他答案之一。在这种情况下，一个典型的客户没有能力提供一个好的证书，所以你不应该让他们负责这样做。您可能仍希望提供使用自定义证书的选项，但不应将其设为默认值。

你可以做一些事情，比如提供一个独特的证书

product-serial-number.product-name.company-name.com

并由证书路径中受信任的东西颁发。出于该目的，证书仍然不受信任，但有人可以根据盒子上的标签检查证书（并可选择将其安装到他们的证书存储中）。不幸的是，Chrome 和 Edge 不再使在 HTTPS 页面上查看证书详细信息变得容易，因此这将很困难。

我一直处于完全相同的情况，负责开发嵌入消费者设备中的 HTTPS 服务器（以及相关内容、REST API 等）。

如问题中所述，不幸的是，安装 CA（证书颁发机构）签名证书不是一种选择，因为证书必须绑定到域。

根据我的经验，您能做的最好的事情就是在每个设备中生成一个唯一的密钥对和证书。在我的设备中，这发生在固件加载到设备后的第一次启动期间以及执行出厂重置时。使用中的微控制器具有用于此目的的硬件 RNG。

当您认为攻击者可以简单地获取您的设备之一并从中提取私钥时，在所有设备上使用相同的密钥对和证书将特别危险，此时所有设备都会受到威胁。

因此，根据我的经验，您真正能做的最好的事情（因为似乎不存在理想的解决方案）是告知您的客户为什么他们必须在产品手册中确认他们的浏览器关于自签名证书的安全警告，并且在至少确保每个设备创建自己唯一的私钥和证书。