通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

X.509 证书证明

  • 项目

本文概述了使用 X.509 证书证明在设备预配服务 (DPS) 中预配设备时涉及的概念。 本文涉及设备部署准备工作中提及的所有角色。

X.509 证书可以存储在硬件安全模块 HSM 中。

提示

我们强烈建议将 HSM 用于设备，以便在生产环境中的设备上安全地存储机密（例如，X.509 证书）。

了解 X.509 证书链

将 X.509 证书用作一种证明机制是扩大生产规模和简化设备设置的极佳途径。 X.509 证书通常是信任证书链中一系列证书中的一个，证书链中的每个证书均通过下一个更高级别证书的私钥进行签名，位于链顶端的证书是自签名的根证书。 此安排会建立一个委托的信任链，该信任链始于受信任证书颁发机构 (CA) 生成的根证书，期间是每个中间证书，终于设备上安装的最终证书。 有关详细信息，请参阅使用 X.509 CA 证书进行设备身份验证。

证书链通常代表与设备关联一个逻辑或物理层次结构。 例如，制造商可能会创建以下证书层次结构：

  • 自签名根 CA 证书开始证书链。
  • 根证书为每个工厂生成唯一的中间 CA 证书。
  • 每个工厂的证书为工厂中的每条生产线生成唯一的中间 CA 证书。
  • 生产线证书为在生产线上制造的每台设备生成唯一的设备（最终实体）证书。

若要了解详细信息，请参阅概念性理解 IoT 行业中的 X.509 CA 证书。

根证书

根证书是表示证书颁发机构 (CA) 的自签名 X.509 证书。 它是证书链的终点或信任定位点。 根证书可由组织自行颁发或从根证书颁发机构购买。 根证书也可以称为根 CA 证书。

中间证书

中间证书是已由根证书（或其链中具有根证书的另一个中间证书）签名的 X.509 证书，也可以为新证书签名。 链中的最后一个中间证书对叶证书进行签名。 中间证书也称为中间 CA 证书。

你可以用各种方式使用中间证书。 例如，可使用中间证书按产品线、购买设备的客户、公司部门或工厂对设备进行分组。

假设 Contoso 是一个拥有自己公钥基础结构 (PKI) 的大型公司，并使用名为 ContosoRootCert 的根证书。 Contoso 的每个子公司都有自己的中间证书，并且由 ContosoRootCert 签名。 然后，每个子公司都使用其中间证书对每个设备的叶证书进行签名。 在这种情况下，Contoso 可以使用单个 DPS 实例，其中 ContosoRootCert 是已验证的证书。 他们可以为每个子公司建立一个注册组。 这样，每个子公司都将无需担心证书验证。

最终实体“叶”证书

叶证书（最终实体证书）标识着证书持有者。 它的证书链中有根证书，且它有零个或多个中间证书。 叶证书不用于对任何其他证书进行签名。 它向预配服务唯一标识设备，有时称为“设备证书”。 在身份验证期间，设备使用与其证书关联的私钥响应来自服务的所有权证明质询。

将 X.509 证书与 DPS 配合使用

预配服务公开了两种注册类型，你可以使用它们通过 X.509 证明机制来控制设备访问：

  • 单个注册条目使用与特定设备关联的设备证书进行配置。 这些条目控制特定设备的注册。
  • 注册组条目与特定的中间或根 CA 证书关联。 这些条目控制其证书链中具有中间或根证书的所有设备的注册。

只能在 DPS 实例的一个注册条目中指定证书。

相互 TLS 支持

为 X.509 证明配置 DPS 注册时，DPS 支持相互 TLS (mTLS)。

DPS 加密算法要求

设备预配服务仅接受使用 Rivest-Shamir-Adleman (RSA) 算法或椭圆曲线加密 (ECC) 算法进行加密的 X.509 证书。 ECC 和 RSA 提供同等级别的加密强度，但 ECC 使用的密钥长度更短。

如果使用 ECC 方法生成 X.509 证书进行设备证明，建议使用以下椭圆曲线：

  • nistP256
  • nistP384
  • nistP521

DPS 证书命名要求

与个人注册条目一起使用的叶证书的使用者公用名称 (CN) 必须设置为注册 ID。 注册 ID 标识设备向 DPS 注册，并且对于设备注册的 DPS 实例（ID 范围）必须是唯一的。

对于注册组，使用者公用名称 (CN) 还会设置通过 IoT 中心注册的设备 ID。 设备 ID 将显示在注册组中经过身份验证的设备的“注册记录”中。 对于个人注册，可以在注册条目中设置设备 ID。 如果未在注册条目中设置，则使用使用者公用名称 (CN)。

有关详细信息，请参阅对使用 X.509 CA 证书签名的设备进行身份验证。

DPS 设备链要求

当设备尝试使用注册组通过 DPS 进行注册时，设备必须将证书链从叶证书发送到已验证的证书。 否则，身份验证会失败。

例如，如果只验证了根证书并将中间证书上传到注册组，则设备应显示从叶证书一直到验证根证书的证书链。 此证书链将包含中间的任何中间证书。 如果 DPS 无法遍历验证证书的证书链，则身份验证将失败。

例如，考虑一个公司对设备使用以下设备链。

显示设备证书链示例的图。

在此示例中，根证书使用 DPS 进行验证，并且 intermediate2 证书在注册组上上传。

突出显示要上传到 DPS 的根证书和中间 2 个证书的图。

如果设备在预配过程中只发送以下设备链，则身份验证将失败。 因为 DPS 不能在假设 intermediate1 证书有效的情况下尝试进行身份验证。

显示因为证书链不链接到根目录，所以证书链身份验证失败的图。

如果设备在预配过程中按如下所示发送完整的设备链，则 DPS 可以尝试对设备进行身份验证。

显示成功的设备证书链的图。

带证书的 DPS 操作顺序

当设备连接到预配服务时，该服务会从设备（叶）证书开始遍历其证书链，并查找相应的注册条目。 它使用在链中找到的第一个条目来确定是否预配设备。 也就是说，如果存在设备证书的单独注册，则预配服务会应用该条目。 如果不存在该设备的单独注册，则服务会查找与第一个中间证书相对应的注册组。 如果找到该条目，则应用该条目；否则，它会查找下一个中间证书（依此类推，沿着链向下直至根）的注册组。

服务会应用找到的第一个条目，这样：

  • 如果找到的第一个注册条目已启用，服务会对设备进行设置。
  • 如果找到的第一个注册条目为禁用状态，服务不会对设备进行预配。
  • 如果没有为设备证书链中的任何证书找到注册条目，服务不会对设备进行预配。

设备证书链中的每个证书都可以在注册条目中指定，但只能在 DPS 实例的一个条目中指定。

通过此机制和证书链的层次结构，在控制单个设备及一组设备的访问权限时可实现极大灵活性。 例如，假设有五台设备具有以下证书链：

  • 设备 1：根证书 -> 证书 A -> 设备 1 证书
  • 设备 2：根证书 -> 证书 A -> 设备 2 证书
  • 设备 3：根证书 -> 证书 A -> 设备 3 证书
  • 设备 4：根证书 -> 证书 A -> 设备 4 证书
  • 设备 5：根证书 -> 证书 A -> 设备 5 证书

最开始，可为根证书创建单个启用的组注册条目，让五台设备均获得访问权限。 如果之后证书 B 出现安全风险，可以为证书 B 创建一个禁用的注册组条目，以防止设备 4 和设备 5 进行注册。 如果之后设备 3 出现安全风险，可为其证书创建一个禁用的单个注册条目。 这会撤消设备 3 的访问权限，但仍允许设备 1 和设备 2 进行注册。