使用 X.509 证书对标识进行身份验证

  • 项目

IoT 中心使用 X.509 证书对设备进行身份验证。 使用 X.509 身份验证可以在建立传输层安全性 (TLS) 标准连接的过程中，对物理层上的 IoT 设备进行身份验证。

X.509 CA 证书是可为其他证书签名的一种数字证书。 如果数字证书符合 IETF RFC 5280 标准规定的证书格式标准，则它被视为 X.509 证书。 证书颁发机构 (CA) 意味着其持有者可为其他证书签名。

本文介绍如何使用 X.509 证书颁发机构 (CA) 证书对连接到 IoT 中心的设备进行身份验证，其中包括以下步骤：

  • 如何获取 X.509 CA 证书
  • 如何将 X.509 CA 证书注册到 IoT 中心
  • 如何使用 X.509 CA 证书为设备签名
  • 如何对使用 X.509 CA 签名的设备进行身份验证

重要

使用 X.509 证书颁发机构 (CA) 身份验证的设备的以下功能尚未正式发布，必须启用预览模式：

  • HTTPS、基于 WebSocket 的 MQTT 和基于 WebSocket 的 AMQP 协议。
  • 文件上传（所有协议）。

这些功能在使用 X.509 指纹身份验证的设备上已正式发布。 若要了解有关使用 IoT 中心进行 x.509 身份验证的详细信息，请参阅支持的 x.509 证书。

借助 X.509 CA 功能，可以使用证书颁发机构 (CA) 在 IoT 中心进行设备身份验证。 它极大地简化了初始设备登记过程，以及设备制造期间的供应链后勤。

身份验证和授权

身份验证是证明你自己的身份的过程。 身份验证向 IoT 中心验证用户身份或设备标识。 它有时缩写为 AuthN。 授权是确认 IoT 中心上经过身份验证的用户或设备的权限的过程。 它指定允许访问的资源和命令，以及可使用这些资源和命令执行的操作。 授权有时缩写为 AuthZ。

本文介绍如何使用 X.509 证书进行身份验证。 可以通过将证书指纹或证书颁发机构 (CA) 上传到 Azure IoT 中心，从而借助 IoT 中心使用任何 X.509 证书对设备进行身份验证。

X.509 证书用于 IoT 中心中的身份验证，而不是授权。 与 Microsoft Entra ID 和共享访问签名不同，无法使用 X.509 证书自定义权限。

强制执行 X.509 身份验证

为了进一步提高安全性，可以将 IoT 中心配置为不允许对设备和模块进行 SAS 身份验证，而将 x.509 保留为唯一接受的身份验证选项。 目前，此功能在 Azure 门户中不可用。 若要进行配置，请将 IoT 中心资源属性上的 disableDeviceSAS 和 disableModuleSAS 设置为 true：

az resource update -n <iothubName> -g <resourceGroupName> --resource-type Microsoft.Devices/IotHubs --set properties.disableDeviceSAS=true properties.disableModuleSAS=true

X.509 CA 证书身份验证的优势

X.509 证书颁发机构 (CA) 身份验证可用于向 IoT 中心进行设备身份验证，所用方法极大地简化了设备标识创建和供应链中的生命周期管理。

X.509 CA 身份验证的一个特有属性是，CA 证书与其下游设备具有一对多关系。 借助这种关系，只需注册 X.509 CA 证书一次，就能将任意数量的设备注册到 IoT 中心。 否则，必须先为每台设备预先注册唯一的证书，然后设备才能进行连接。 这种一对多关系还可简化设备证书生命周期管理操作。

X.509 CA 身份验证的另一重要属性是简化了供应链逻辑。 设备的安全身份验证要求每台设备拥有唯一机密（如密钥），以作为信任基础。 在基于证书的身份验证中，此机密即为私钥。 典型的设备制造流程需要多个步骤及多个保管人。 跨多个保管人安全管理设备私钥并维持信任十分困难且成本高昂。 使用证书颁发机构即可解决此问题，因其将每个保管人签名到加密信任链，而不是将设备私钥委托给他们。 每个保管人在各自的制造流步骤中对设备进行签名。 整体结果是通过使用加密信任链、借助内置职责优化了供应链。

在设备保护其唯一私钥时，此过程可实现最大安全性。 为此，我们建议使用能够内在生成私钥的硬件安全模块 (HSM)。

使用 Azure IoT 中心设备预配服务 (DPS) 可以轻松将设备组预配到中心。

获取 X.509 CA 证书

X.509 CA 证书位于每个设备的证书链的顶层。 可以根据目标用途购买或创建该证书。

对于生产环境，我们建议从专业的证书服务提供商处购买 X.509 CA 证书。 购买 CA 证书的好处是可让根 CA 充当受信任的第三方，确保设备的合法性。 如果设备是在其中与第三方产品或服务进行交互的开放 IoT 网络的一部分，请考虑此选项。

此外，还可以创建自签名的 X.509 CA 证书进行测试。 有关创建用于测试的证书的详细信息，请参阅创建和上传用于测试的证书。

注意

不建议在生产环境中使用自签名证书。

不管 X.509 CA 证书是如何获取的，都请确保保持其相应私钥的机密性，并始终对此私钥进行保护。 此预防措施是确保能够在 X.509 CA 身份验证中建立信任的必要措施。

在证书信任链中为设备签名

X.509 CA 证书的所有者能以加密方式为某个中间 CA 签名，而该 CA 又能为另一个中间 CA 签名，依此类推，直到最后一个中间 CA 通过为设备证书签名来终止此过程。 结果是一个称为证书信任链的级联证书链。 这种信任委派十分重要，因为它能够建立一种加密的可变监护链，并避免共享签名密钥。

Diagram that shows the certificates in a chain of trust.

设备证书（也称分支证书）必须将公用名称 (CN) 设置为在 Azure IoT 中心注册 IoT 设备时使用的设备 ID (CN=deviceId)。 身份验证需要此设置。

对于使用 X.509 身份验证的模块，模块的证书公用名称 (CN) 格式必须如 CN=deviceId/moduleId 所示。

了解如何像为设备签名时一样创建证书链。

将 X.509 CA 证书注册到 IoT 中心

将 X.509 CA 证书注册到 IoT 中心，在注册和连接期间，IoT 中心将使用此证书对设备进行身份验证。 注册 X.509 CA 证书是一个两步过程，包括上传证书文件，然后建立所有权证明。

上传过程需要上传包含证书的文件。 此文件不得包含任何私钥。

所有权证明步骤涉及到在你与 IoT 中心之间执行加密质询和响应过程。 鉴于数字证书内容是公开的，因而容易遭到窃听，IoT 中心必须验证 CA 证书真正由你拥有。 可以选择自动或手动验证所有权。 对于手动验证，Azure IoT 中心会生成使用 CA 证书的相应私钥签名的随机质询。 如果按照建议保持私钥的机密性并对其进行保护，则只有你才能拥有所需的信息来完成此步骤。 私钥的机密性是此方法的信任源。 为质询签名后，可以完成此操作并通过上传包含结果的文件来手动验证证书。

了解如何注册 CA 证书

对使用 X.509 CA 证书签名的设备进行身份验证

每个 IoT 中心都有一个标识注册表，存储允许连接到 IoT 中心的设备和模块的相关信息。 IoT 中心的标识注册表中必须先有设备或模块的条目，然后该设备或模块才能连接到 IoT 中心。 设备或模块基于标识注册表中存储的凭据向 IoT 中心进行身份验证。

注册 X.509 CA 证书并在证书信任链中为设备签名后，最后一步就是在设备连接时进行设备身份验证。 当 X.509 CA 签名的设备建立连接时，会上传其证书链用于验证。 该链包含所有中间 CA 和设备证书。 使用此信息，IoT 中心可通过一个两步过程对设备进行身份验证。 IoT 中心以加密方式验证证书链的内部一致性，然后向设备发出所有权证明质询。 如果设备返回了所有权证明成功响应，则 IoT 中心会声明该设备可信。 此声明假设设备的私钥受到保护，并且只有该设备才能成功响应此质询。 我们建议使用设备中的安全芯片（例如硬件安全模块 (HSM)）来保护私钥。

设备成功连接到 IoT 中心后，身份验证过程即告完成，这也表明设置正确。 每次设备进行连接时，IoT 中心都会重新协商 TLS 会话并验证设备的 X.509 证书。

吊销设备证书

在使用基于证书的身份验证对设备进行身份验证时，IoT 中心不会从证书颁发机构检查证书吊销列表。 如果由于证书可能泄露，而需要阻止设备连接到 IoT 中心，则应在标识注册表中禁用该设备。 有关详细信息，请参阅禁用或删除 IoT 中心中的设备。

示例方案

X 公司生产 Smart-X-Widget 并提供专业安装服务。 X 公司将制造和安装外包。 Y 工厂负责生产 Smart-X-Widget，技术人员 Z 负责安装。 X 公司希望将 Smart-X-Widget 直接从工厂 Y 运送到技术人员 Z 进行安装，然后将该设备直接连接到 X 公司的 IoT 中心实例。 为实现这一目的，X 公司需完成几个一次性安装操作，对智能 X 小组件进行优化以实现自动连接。 此端到端方案包括以下步骤：

  1. 获取 X.509 CA 证书

  2. 将 X.509 CA 证书注册到 IoT 中心

  3. 将设备签名到证书信任链

  4. 连接设备

教程：创建和上传用于测试的证书中演示了这些步骤。

获取证书

X 公司可以从公共根证书颁发机构购买 X.509 CA 证书，或者通过自签名过程创建一个证书。 上述任一选项都需要完成两个基本步骤：生成公钥/私钥对，并在证书中为公钥签名。

不同服务提供商完成这些步骤的方式详情有所不同。

Diagram showing the flow for generating an X.509 CA certificate.

购买证书

购买 CA 证书的好处是可让知名根 CA 充当可信第三方，确保设备连接时 IoT 设备的合法性。 如果设备将与第三方产品或服务交互，请选择此选项。

若要购买 X.509 CA 证书，请选择一家根证书服务提供商。 根 CA 提供商将指导你创建公钥/私钥对以及为其服务生成证书签名请求 (CSR)。 CSR 是从证书颁发机构申请证书的正式过程。 此次购买的证书可用作证书颁发机构证书。 由于 X.509 证书普遍存在，所以该证书格式可能已按照 IETF RFC 5280 标准正确设置。

创建自签名证书

除了需要根证书颁发机构之类的第三方签名人之外，创建自签名 X.509 CA 证书的过程与购买过程相同。 在本例中，X 公司要对其授权证书进行签名，而不是向根证书颁发机构购买。

在准备好购买证书颁发机构证书之前，可以选择此选项进行测试。 如果你的设备不连接到 IoT 中心外的任何第三方服务，你也可以在生产中使用自签名 X.509 CA 证书。

将证书注册到 IoT 中心

Company-X 需要将 X.509 CA 注册到 IoT 中心，以便在 Smart-X-Widget 连接时对它们进行身份验证。 此过程是一次性的，完成后即可对任何数量的 Smart-X-Widget 设备进行身份验证和管理。 CA 证书和设备证书之间的一对多关系是使用 X.509 CA 身份验证方法的主要优点之一。 另一种方法是为每个 Smart-X-Widget 设备上传单个证书指纹，但这会增加运营成本。

注册 X.509 CA 证书的过程包括两个步骤：上传证书，然后提供证书所有权证明。

Diagram showing the process flow for registering an X.509 CA certificate.

上传证书

X.509 CA 证书上传过程仅包括将 CA 证书上传到 IoT 中心。 IoT 中心希望证书包含在文件内。

在任何情况下，证书文件都不能包含任何私钥。 公钥基础结构 (PKI) 标准的最佳做法规定，X 公司的私钥只能驻留在 X 公司内部。

证明所有权

与所有数字证书相同，X.509 CA 证书也是易遭窃听的公共信息。 因此，窃听者可能会拦截证书并尝试将其作为自己的证书进行上传。 在本示例中，IoT 中心必须确保 X 公司上传的 CA 证书确实属于 X 公司。 实现这一目的的方法是：要求 X 公司通过所有权证明 (PoP) 流程证明他们拥有该证书。

对于所有权证明流程，IoT 中心将生成随机数字，X 公司将使用其私钥对该数字进行签名。 如果 X 公司遵循了 PKI 最佳做法并保护了私钥，那么只有他们才能够正确响应所有权证明质询。 成功响应所有权证明质疑后，IoT 中心会继续注册 X.509 CA 证书。

成功响应 IoT 中心的所有权证明质疑后，即可完成 X.509 CA 注册。

将设备签名到证书信任链

IoT 要求连接的每个设备都有一个唯一的标识。 对于基于证书的身份验证，这些标识采用证书形式。 在本示例中，基于证书的身份验证意味着每个 Smart-X-Widget 必须拥有唯一设备证书。

在每个设备上提供唯一证书的一种有效但效率低下的方法是为智能 X 小组件预生成证书，并信任具有相应私钥的供应链合作伙伴。 对于 X 公司，这意味着委托 Y 工厂和 Z 技术人员。 这种方法必须同时解决一些问题才可确保信任度，如下所示：

  • 除了忽略 PKI 最佳做法（绝不共享私钥）外，还必须与供应链合作伙伴共享设备私钥，这使得供应链中的信任构建成本高昂。 这需要安装系统（例如安全室）来存放设备私钥和建立定期安全审核等流程。 这两者均会增加供应链成本。

  • 从设备唯一证书（和私钥）生成到设备停用，对每个密钥-设备对而言，在供应链中安全照管设备以及之后在部署中管理它们都是一项一对一任务。 这妨碍设备的组管理，除非以某种方式将组的概念明确嵌入该过程。 因此，安全照管设备和设备生命周期管理成为沉重的运营负担。

X.509 CA 证书身份验证使用证书链来为这些挑战提供完美的解决方案。 证书链如此生成：一个 CA 对一个中间 CA 进行签名，这个中间 CA 转而对另一个中间 CA 进行签名，依此类推，直到最后一个中间 CA 对设备进行签名。 在本例中，X 公司对 Y 工厂进行签名，Y 工厂转而对 Z 技术人员进行签名，而 Z 技术人员最后要对智能 X 小组件进行签名。

Diagram showing an example of a certificate chain hierarchy.

链中的这种证书级联体现了授权的逻辑转移。 许多供应链都遵循这种逻辑转移，每个中间 CA 在接收所有上游 CA 证书时被签名到链中，最后一个中间 CA 最后对每台设备进行签名并将链中的授权构证书引入设备。 这种移交常见于具有工厂层次结构的合同制造公司委托特定工厂进行生产的情况。 层次结构可能是多级深度（例如，地理/产品类型/生产线），只有最后的工厂才会与设备进行交互，但供应链是从层次结构顶部进行维护的。

备用链中可能会有其他中间 CA 与设备进行交互，在这种情况下，与设备进行交互的 CA 此时会插入证书链内容。 如果只有某些 CA 与设备进行物理交互，也可使用混合模型。

下图显示了信任证书链如何在 Smart-X-Widget 示例中组合到一起。

Diagram showing the certificate chain of trust from the certificates of one company to the certificates of another company.

  1. X 公司永远不会与任何 Smart-X-Widget 进行物理交互。 它通过为 Y 工厂的中间 CA 证书签名来启动信任证书链。
  2. Y 工厂现在拥有自己的中间 CA 证书和来自 X 公司的签名。 它将这些项的副本传递给设备。 它还使用其中间 CA 证书来为技术人员 Z 的中间 CA 证书和 Smart-X-Widget 设备证书签名。
  3. 技术人员 Z 现在拥有自己的中间 CA 证书和来自 Y 工厂的签名。 它将这些项的副本传递给设备。 它还使用其中间 CA 证书来为 Smart-X-Widget 设备证书签名。
  4. 现在，每个 Smart-X-Widget 设备都有自己唯一的、用于在整个供应链中交互的设备证书以及来自每个中间 CA 证书的公钥和签名副本。 这些证书和签名可以追溯到原始的 X 公司根。

CA 身份验证方法将安全责任引入了设备制造供应链。 由于证书链过程，链中每位成员的操作均已加密记录且可验证。

此过程依赖于这种假设：唯一的设备公钥/私钥对是单独创建的，并且私钥始终在设备中受到保护。 幸运的是，硬件安全模块 (HSM) 形式的安全硅芯片能够在内部生成密钥并保护私钥。 X 公司只需将此类安全芯片之一添加到 Smart-X-Widget 的组件材料清单即可。

对设备进行身份验证

将顶级 CA 证书注册到 IoT 中心并且设备拥有其唯一证书后，它们如何连接？ 通过向 IoT 中心注册一次 X.509 CA 证书，数百万台设备在首次连接时即可通过身份验证，这怎么可能？ 通过之前注册 X.509 CA 证书所用的相同证书上传和所有权证明流程即可实现。

针对 X.509 CA 身份验证所制造的设备配有唯一设备证书和其各自制造供应链的证书链。 即使是首次连接，也只需 2 步即可实现设备连接：证书链上传、所有权证明。

在证书链上传期间，设备将其唯一证书及其证书链上传到 IoT 中心。 使用预注册的 X.509 CA 证书，IoT 中心验证上传的证书链是否内部一致，以及该链是否来自有效的 X.509 CA 证书所有者。 与 X.509 CA 注册过程一样，IoT 中心使用一个所有权证明质询-响应过程来确定链和设备证书是否属于上传该链的设备。 成功响应将促使 IoT 中心认为设备可信并允许其进行连接。

在本示例中，每个智能 X 小组件都会将其设备唯一证书与 Y 工厂和 Z 技术人员的 X.509 CA 证书一并上传，然后响应 IoT 中心发出的所有权证明质疑。

Diagram showing the flow for validating a device certificate.

信任的基础在于保护私钥（包括设备私钥）。 因此，我们一再强调使用硬件安全模块 (HSM) 形式的安全硅芯片保护设备私钥的重要性，也一再强调绝不共享任何私钥（如某工厂将其私钥委托给另一工厂）这一整体最佳做法。

后续步骤

若要详细了解构成 X.509 证书的字段，请参阅 X.509 证书。

如果你有根 CA 证书或从属 CA 证书，并想要将其上传到 IoT 中心，则必须验证自己对该证书的所有权。 有关详细信息，请参阅教程：创建和上传用于测试的证书。