了解 Azure IoT Edge 使用证书的方式

项目
08/12/2024

适用于： IoT Edge 1.5 IoT Edge 1.4

重要

IoT Edge 1.5 LTS 和 IoT Edge 1.4 LTS 是受支持的版本。 IoT Edge 1.4 LTS 的生命周期结束日期为 2024 年 11 月 12 日。如果你使用的是较低的版本，请参阅更新 IoT Edge。

IoT Edge 将不同类型的证书用于不同的目的。本文将引导你了解 IoT Edge 在 Azure IoT 中心和 IoT Edge 网关方案中使用证书的不同方式。

重要

为简洁起见，本文适用于 IoT Edge 版本 1.2 或更高版本。 1.1 版的证书概念类似，但有一些区别：

版本 1.1 中的“设备 CA 证书”已重命名为“Edge CA 证书”。
版本 1.1 中的“工作负载 CA 证书”已停用。在 1.2 或更高版本中，IoT Edge 模块运行时直接从 Edge CA 证书生成所有服务器证书，证书链中的它们之间没有中间工作负载 CA 证书。

总结

这些核心方案是 IoT Edge 使用证书的地方。使用以下链接详细了解每个方案。

Actor	目的	证书
IoT Edge	确保它与合适的 IoT 中心通信	IoT 中心服务器证书
IoT 中心	确保请求来自合法的 IoT Edge 设备	IoT Edge 标识证书
下游 IoT 设备	确保它与合适的 IoT Edge 网关通信	IoT Edge中心 edgeHub 模块服务器证书，由 Edge CA 颁发
IoT Edge	对新模块服务器证书进行签名。例如，“edgeHub”	Edge CA 证书
IoT Edge	确保请求来自合法的下游设备	IoT 设备标识证书

先决条件

你应该对公钥加密、密钥对以及公钥和私钥如何加密或解密数据有基本的了解。有关 IoT Edge 如何使用公钥加密的详细信息，请参阅了解公钥加密和 X.509 公钥基础结构。
你应该对 IoT Edge 与 IoT 中心的关系有基本的了解。有关详细信息，请参阅了解 Azure IoT Edge 运行时及其体系结构。

单设备方案

为了帮助了解 IoT Edge 证书概念，假设有一个方案，其中名为“EdgeGateway”的 IoT Edge 设备连接到名为“ContosoIotHub”的 Azure IoT 中心。在此示例中，所有身份验证都是使用 X.509 证书身份验证而不是对称密钥完成的。若要在此方案中建立信任，我们需要保证 IoT 中心和 IoT Edge 设备是可信的：“此设备是否是真正且有效的？”和“IoT 中心标识是否正确？”。下图可以说明该方案：

我们将解释每个问题的答案，然后在本文后面的部分中扩展示例。

设备验证 IoT 中心标识

EdgeGateway 如何验证它是否在与真正的 ContosoIotHub 通信？当 EdgeGateway 想要与云通信时，它会连接到终结点 ContosoIoTHub.Azure-devices.NET。为了确保该终结点是可信的，IoT Edge 需要 ContosoIoTHub 显示标识 (ID)。该 ID 必须由 EdgeGateway 信任的颁发机构颁发。为了验证 IoT 中心标识，IoT Edge 和 IoT 中心使用“TLS 握手”协议来验证 IoT 中心的服务器标识。下图演示了“TLS 握手”。为了保持示例简洁，此处省略了一些详细信息。若要详细了解 TLS 握手协议，请参阅维基百科上的“TLS 握手”。

注意

在此示例中，ContosoIoTHub 表示 IoT 中心主机名 ContosoIotHub.Azure-devices.NET。

显示从 IoT 中心到 IoT Edge 设备的证书交换的序列图，其中包含使用 IoT Edge 设备上受信任的根存储进行的证书验证。

在此上下文中，你无需知道加密算法的确切详细信息。重要的是了解该算法可确保服务器拥有与其公钥配对的私钥。它验证证书的提供者是否未复制或窃取它。如果我们使用照片 ID 作为示例，则你的人脸与 ID 上的照片匹配。如果别人偷了你的 ID，那么他们无法将其用于识别，因为你的脸是独一无二的，很难重现。对于加密密钥，密钥对是相关且唯一的。加密算法使用密钥对来验证标识，而不是将人脸与照片 ID 进行匹配。

在我们的方案中，ContosoIotHub 显示以下证书链：

显示 IoT 中心的中间证书和根证书颁发机构链的流程图。

根证书颁发机构 (CA) 是 Baltimore CyberTrust 根证书。此根证书由 DigiCert 签名，受到广泛信任，并且存储在许多操作系统中。例如，Ubuntu 和 Windows 都将其包含在默认证书存储中。

Windows 证书存储：

Ubuntu 证书存储：

当设备检查“Baltimore CyberTrust 根”证书时，它已预装在 OS 中。从 EdgeGateway 的角度来看，由于 ContosoIotHub 提供的证书链由 OS 信任的根 CA 签名，因此该证书被视为可信证书。该证书称为 IoT 中心服务器证书。

概括而言，EdgeGateway 可以验证并信任 ContosoIotHub 的标识，因为：

ContosoIotHub 提供其 IoT 中心服务器证书
该服务器证书在 OS 证书存储中受信任
使用 ContosoIotHub 的公钥加密的数据可由 ContosoIotHub 解密，证明其拥有私钥

IoT 中心验证 IoT Edge 设备标识

ContosoIotHub 如何验证它是否在与 EdgeGateway 通信？由于 IoT 中心支持相互 TLS (mTLS)，它会在执行客户端已验证的 TLS 握手期间检查 EdgeGateway 的证书。为简单起见，我们将跳过下图中的一些步骤。

显示从 IoT Edge 设备到 IoT 中心的证书交换的序列图，其中包含 IoT 中心上的证书指纹检查验证。

在这种情况下，EdgeGateway 会提供其 IoT Edge 设备标识证书。从 ContosoIotHub 的角度来看，它会检查提供的证书的指纹是否与其记录匹配，以及 EdgeGateway 是否具有与其出示的证书配对的私钥。在 IoT 中心内预配 IoT Edge 设备时，需要提供指纹。该指纹是 IoT 中心用于验证证书的指纹。

提示

IoT 中心在注册 IoT Edge 设备时需要两个指纹。最佳做法是准备两个不同的设备标识证书，它们的过期日期不同。这样，如果一个证书过期，另一个证书仍然有效，让你有时间轮换过期的证书。但是，也可以仅使用一个证书进行注册。通过在注册设备时为主要和次要指纹设置相同的证书指纹来使用单个证书。

例如，可以使用以下命令获取 EdgeGateway 上的标识证书指纹：

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

该命令输出证书 SHA256 指纹：

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

如果查看在 IoT 中心注册的 EdgeGateway 设备的 SHA256 指纹值，可以看到它与 EdgeGateway 上的指纹匹配：

ContosoIotHub 中 EdgeGateway 设备指纹的 Azure 门户屏幕截图。

总之，ContosoIotHub 可以信任 EdgeGateway，因为 EdgeGateway 提供有效的 IoT Edge 设备标识证书，该证书的指纹与在 IoT 中心中注册的指纹匹配。

有关证书生成过程的详细信息，请参阅使用 X.509 证书在 Linux 上创建和预配 IoT Edge 设备。

注意

此示例未处理 Azure IoT 中心设备预配服务 (DPS)，该服务支持使用 IoT Edge 进行 X.509 CA 身份验证（如果已预配有注册组）。使用 DPS 时，你需上传 CA 证书或中间证书，证书链将被验证，然后设备会被预配。若要了解详细信息，请参阅 DPS X.509 证书证明。

在 Azure 门户中，DPS 显示证书的 SHA1 指纹，而不是 SHA256 指纹。

DPS 将 SHA256 指纹注册或更新到 IoT 中心。可以使用 openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256 命令验证指纹。注册后，IoT Edge 会将指纹身份验证与 IoT 中心配合使用。如果重新预配了设备并颁发了新证书，DPS 会使用新的指纹更新 IoT 中心。

IoT 中心目前不支持直接使用 IoT Edge 进行 X.509 CA 身份验证。

适用于模块标识操作的证书用途

在证书验证示意图中，它可能会显示 IoT Edge 仅将证书用来与 IoT 中心通信。 IoT Edge 由多个模块组成。因此，IoT Edge 会使用证书来管理发送消息的模块的模块标识。模块不会使用证书向 IoT 中心进行身份验证，而是使用从 IoT Edge 模块运行时生成的私钥派生的 SAS 密钥。即使设备标识证书过期，这些 SAS 密钥也不会更改。例如，如果证书过期，edgeHub 将继续运行，只有模块标识操作会失败。

模块与 IoT 中心之间的交互是安全的，因为 SAS 密钥派生自机密并且 IoT Edge 会管理密钥，没有人为干预的风险。

将 IoT Edge 作为网关的嵌套设备层次结构方案

现在，你对 IoT Edge 与 IoT 中心之间的简单交互有了很好的了解。但是，IoT Edge 也可以充当下游设备或其他 IoT Edge 设备的网关。这些信道也必须经过加密且受信任。由于增加了复杂性，我们必须扩展示例方案以包含下游设备。

我们添加名为“TempSensor”的常规 IoT 设备，该设备连接到其父 IoT Edge 设备“EdgeGateway”，后者连接到 IoT 中心“ContosoIotHub”。与之前类似，所有身份验证都是通过 X.509 证书身份验证完成的。我们的新方案提出了两个新问题：“TempSensor 设备是否合法？”和“EdgeGateway 的标识是否正确？”。下图可以说明该方案：

提示

TempSensor 是该方案中的 IoT 设备。如果 TempSensor 是父 EdgeGateway 的下游 IoT Edge 设备，则证书概念是相同的。

设备验证网关标识

TempSensor 如何验证它是否在与真正的 EdgeGateway 通信？当 TempSensor 想要与 EdgeGateway 通信时，TempSensor 需要 EdgeGateway 来显示 ID。该 ID 必须由 TempSensor 信任的颁发机构颁发。

显示从网关设备到 IoT Edge 设备的证书交换的序列图，其中包含使用专用根证书颁发机构的证书验证。

该流程与 EdgeGateway 和 ContosoIotHub 通信时相同。 TempSensor 和 EdgeGateway 使用 TLS 握手协议来验证 EdgeGateway 的标识。有两个重要细节：

主机名特异性：EdgeGateway 提供的证书必须颁发给 TempSensor 用于连接到 EdgeGateway 的同一主机名（域或 IP 地址）。
自签名根 CA 特异性：EdgeGateway 提供的证书链可能不在 OS 默认信任的根存储中。

为了了解详细信息，让我们先检查 EdgeGateway 提供的证书链。

显示 IoT Edge 网关的证书颁发机构链的流程图。

主机名特异性

证书公用名 CN = edgegateway.local 在链的顶部列出。 edgegateway.local 是 edgeHub 的服务器证书公用名称。 edgegateway.local 也是 TempSensor 和 EdgeGateway 连接到的本地网络（LAN 或 VNet）上 EdgeGateway 的主机名。它可以是专用 IP 地址（例如 192.168.1.23），也可以是下图所示的完全限定的域名 (FQDN)。 edgeHub 服务器证书是使用 IoT Edge config.toml 文件中定义的 hostname 参数生成的。不要将 edgeHub 服务器证书与 Edge CA 证书混淆。有关管理 Edge CA 证书的详细信息，请参阅管理 IoT Edge 证书。

当 TempSensor 连接到 EdgeGateway 时，TempSensor 使用主机名 edgegateway.local 连接到 EdgeGateway。 TempSensor 检查 EdgeGateway 提供的证书，并验证证书公用名称是否为 edgegateway.local。如果证书公用名称不同，TempSensor 将拒绝连接。

注意

为简单起见，该示例将使用者证书公用名 (CN) 显示为经过验证的属性。在实践中，如果证书具有使用者别名 (SAN)，则会验证 SAN 而不是 CN。通常，由于 SAN 可以包含多个值，因此它同时具有证书持有者的主域/主机名以及任何备用域。

为什么需要告知 EdgeGateway 其自己的主机名？

EdgeGateway 没有可靠的方法来知道网络上的其他客户端如何连接到它。例如，在专用网络上，可能会有 DHCP 服务器或 mDNS 服务将 EdgeGateway 作为 10.0.0.2 或 example-mdns-hostname.local 列出。但是，某些网络可能具有将 edgegateway.local 映射到 EdgeGateway IP 地址 10.0.0.2 的 DNS 服务器。

为解决此问题，IoT Edge 使用 config.toml 中配置的主机名值并为其创建服务器证书。当请求到达 edgeHub 模块时，它会提供具有正确证书公用名 (CN) 的证书。

为什么 IoT Edge 会创建证书？

在本示例中，请注意证书链中有一个“iotedged workload ca edgegateway”。它是存在于 IoT Edge 设备上的证书颁发机构 (CA)，称为“Edge CA”（以前在 1.1 版中称为“设备 CA”）。与前面示例中的 Baltimore CyberTrust 根 CA 一样，Edge CA 可以颁发其他证书。最重要的是，也是在此示例中，它向 edgeHub 模块颁发服务器证书。但是，它还可以向 IoT Edge 设备上运行的其他模块颁发证书。

重要

默认情况下，无需配置，Edge CA 由 IoT Edge 模块运行时在首次启动时自动生成（称为“快速启动 Edge CA”），然后它将证书颁发给 edgeHub 模块。此过程允许 edgeHub 提供已签名的有效证书，从而加快下游设备连接的速度。如果没有此功能，则必须让 CA 为 edgeHub 模块颁发证书。不支持在生产环境中使用自动生成的“快速启动 Edge CA”。有关快速启动 Edge CA 的详细信息，请参阅快速启动 Edge CA。

在设备上拥有颁发者证书不危险吗？

Edge CA 旨在支持连接受限、不可靠、昂贵或缺失但同时对证书续订有严格规定或策略的解决方案。如果没有 Edge CA，IoT Edge（尤其是 edgeHub）将无法正常工作。

若要在生产环境中保护 Edge CA，请执行以下操作：

将 EdgeCA 私钥放在受信任的平台模块 (TPM) 中，最好采用临时生成私钥且私钥永不离开 TPM 的方式。
使用 Edge CA 汇总到的公钥基础结构 (PKI)。这样，就能够禁用或拒绝续订已泄露的证书。 PKI 可以在客户 IT 具有相应技能的情况下由他们管理（成本较低），也可以通过商业 PKI 提供商管理。

自签名根 CA 特异性

edgeHub 模块是构成 IoT Edge 的重要组件，因为它处理所有传入流量。在此示例中，它使用由 Edge CA 颁发的证书，而该证书又由自签名根 CA 颁发。由于根 CA 不受 OS 信任，因此可让 TempSensor 信任它的唯一方法就是将 CA 证书安装到设备上。这也称为“信任捆绑”方案，其中需要将根证书分发给需要信任该链的客户端。信任捆绑方案可能很麻烦，因为你需要访问设备并安装证书。安装证书需要规划。它可以通过脚本完成、在制造过程中添加，或预安装在 OS 映像中。

注意

某些客户端和 SDK 不使用 OS 信任的根存储，并且你需要直接传递根 CA 文件。

应用所有这些概念，TempSensor 可以验证它是否在与真正的 EdgeGateway 通信，因为它提供了与地址匹配的证书，并且该证书是由受信任的根签名的。

若要验证证书链，可以在 TempSensor 设备上使用 openssl。在此示例中，请注意，连接的主机名与“depth 0”证书的 CN 匹配，并且根 CA 匹配。

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

若要详细了解 openssl 命令，请参阅 OpenSSL 文档。

还可以检查默认情况下存储在 /var/lib/aziot/certd/certs 中的证书。可以在该目录中找到 Edge CA 证书、设备标识证书和模块证书。可以使用 openssl x509 命令检查证书。例如：

sudo ls -l /var/lib/aziot/certd/certs

total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

总之，TempSensor 可以信任 EdgeGateway，因为：

edgeHub 模块显示了 edgegateway.local 的有效 IoT Edge 模块服务器证书
该证书由 my_private_root_CA 颁发的 Edge CA 颁发
此专用根 CA 之前也作为受信任的根 CA 存储在 TempSensor 中
加密算法验证所有权和颁发链是否可受信任

其他模块的证书

其他模块可以获取由 Edge CA 颁发的服务器证书。例如，具有 Web 界面的 Grafana 模块。它还可以从 Edge CA 获取证书。模块被视为容器中托管的下游设备。但是，能够从 IoT Edge 模块运行时获取证书是一种特殊特权。模块调用工作负载 API 以接收链接到已配置的 Edge CA 的服务器证书。

网关验证设备标识

EdgeGateway 如何验证它是否在与 TempSensor 通信？ EdgeGateway 使用“TLS 客户端身份验证”对 TempSensor 进行身份验证。

显示从 IoT Edge 设备到网关的证书交换的序列图，其中包含根据 IoT 中心证书进行的证书检查验证。

该序列类似于用于验证设备的 ContosoIotHub。但是，在网关方案中，EdgeGateway 依赖于 ContosoIotHub 作为证书记录的真实来源。 EdgeGateway 还会保留脱机副本或缓存，以防无法连接到云。

提示

与 IoT Edge 设备不同，下游 IoT 设备不仅限于指纹 X.509 身份验证。 X.509 CA 身份验证也是一个选项。 EdgeGateway 还可以检查 TempSensor 的证书的根证书是否在已上传到 ContosoIotHub 的 CA 中，而不仅仅是在指纹上查找匹配项。

总之，EdgeGateway 可以信任 TempSensor，因为：

TempSensor 为其名称提供了有效的 IoT 设备标识证书
该标识证书的指纹与上传到 ContosoIotHub 的指纹匹配
加密算法验证所有权和颁发链是否可受信任

在何处获取证书并进行管理

在大多数情况下，可以提供你自己的证书或自动生成的证书。例如，Edge CA 和 edgeHub 证书是自动生成的。

但是，最佳做法是将设备配置为使用“通过安全传输的注册 (EST)”服务器来管理 x509 证书。使用 EST 服务器，你便无需手动处理证书并将它们安装到设备上。有关使用 EST 服务器的详细信息，请参阅为 Azure IoT Edge 配置“通过安全传输的注册”服务器。

也可以使用证书向 EST 服务器进行身份验证。这些证书用于通过 EST 服务器进行身份验证以颁发其他证书。证书服务使用一个启动证书通过 EST 服务器进行身份验证。该启动证书是长期存在的。在初始身份验证时，证书服务向 EST 服务器发出请求以颁发标识证书。此标识证书用于将来对同一服务器的 EST 请求。

如果无法使用 EST 服务器，则应从 PKI 提供商请求证书。可以在 IoT 中心和 IoT Edge 设备中手动管理证书文件。有关详细信息，请参阅管理 IoT Edge 设备上的证书。

对于概念证明开发，可以创建测试证书。有关详细信息，请参阅创建演示证书以测试 IoT Edge 设备功能。

IoT 中的证书

证书颁发机构

证书颁发机构 (CA) 是颁发数字证书的实体。证书颁发机构充当所有者和证书接收者之间的可信第三方。数字证书可认证证书接收者对公钥的所有权。使用证书信任链的方式是先颁发根证书，这是信任机构颁发的所有证书的基础。根证书所有者可以颁发其他中间证书（下游设备证书）。

根 CA 证书

根 CA 证书是整个过程的信任根。在生产方案中，此 CA 证书是从受信任的商业证书颁发机构（如 Baltimore、Verisign 或 DigiCert）购买的。如果可完全控制连接到 IoT Edge 设备的设备，即可使用公司级证书颁发机构。无论它是从上述哪一颁发机构购买的，从 IoT Edge 到 IoT 中心的整个证书链都会使用它。下游 IoT 设备必须信任该根证书。可将根 CA 证书存储在受信任的根证书颁发机构存储中，也可以在应用程序代码中提供证书详细信息。

中间证书

在创建安全设备的典型制造过程中，很少直接使用根 CA 证书，这主要是因为存在泄漏或暴露的风险。根 CA 证书创建并对一个或多个中间 CA 证书进行数字签名。可能只有一个中间证书，也可能存在中间证书链。需要中间证书链的情景包括：

制造商各部门的层次结构
多家公司有序参与设备生产
客户购买根 CA 并派生签名证书，以便制造商代表该客户对制造的设备签名

在任何情况下，制造商都使用此链末尾的中间 CA 证书对终端设备上的 Edge CA 证书进行签名。这些中间证书在制造厂受到严密保护。这些证书的使用需要遵循严格的物理和电子流程。

后续步骤

若要详细了解如何在 IoT Edge 设备上安装证书并从配置文件引用这些证书，请参阅在 IoT Edge 设备上管理证书。
了解 Azure IoT Edge 模块
配置 IoT Edge 设备以充当透明网关
本文讨论了用于保护 IoT Edge 设备上不同组件之间的连接或 IoT Edge 设备与任何下游设备之间的连接的证书。还可以使用一些证书向 IoT 中心验证 IoT Edge 设备。这些身份验证证书是不同的，本文不对其进行讨论。有关使用证书对设备进行身份验证的详细信息，请参阅使用 X.509 证书创建和预配 IoT Edge 设备。

通过