X.509 证书证明

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

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

提示

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

X.509 证书

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

证书链通常代表与设备关联一些逻辑或物理层次结构。 例如,制造商可以:

  • 颁发自签名根 CA 证书
  • 使用根证书为每个工厂生成唯一的中间 CA 证书
  • 使用每个工厂的证书为工厂中的每条生产线生成唯一的中间 CA 证书
  • 并最终使用生产线证书为在生产线上制造的每台设备生成唯一的设备(最终实体)证书。

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

根证书

根证书是表示证书颁发机构 (CA) 的自签名的 X.509 证书。 它是证书链的终点或信任定位点。 根证书可由组织自行颁发或从根证书颁发机构购买。 若要了解详细信息,请参阅获取 X.509 CA 证书。 根证书也可称为根 CA 证书。

中间证书

中间证书是已由根证书(或其链中具有根证书的另一个中间证书)签名的 X.509 证书。 链中的最后一个中间证书用于对分支证书进行签名。 中间证书也可称为中间 CA 证书。

为什么中间证书有用?

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

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

最终实体“叶”证书

分支证书或最终实体证书标识证书持有者。 它具有其证书链中的根证书以及零个或多个中间证书。 分支证书不用于对任何其他证书进行签名。 它向设置服务唯一标识设备,有时称为设备证书。 在身份验证期间,设备使用与此证书关联的私钥响应来自服务的所有权证明质询。

用于个人注册注册组条目的叶证书的使用者公用名称 (CN) 必须设置为注册 ID。 注册 ID 标识设备向 DPS 注册,并且对于设备注册的 DPS 实例(ID 范围)必须是唯一的。 注册 ID 是一个不区分大小写的字符串,包含字母数字字符和以下特殊字符:'-''.''_'':'。 最后一个字符必须是字母数字或短划线 ('-')。 DPS 支持最大长度为 128 个字符的注册 ID;但是,在 X.509 证书中,使用者公用名的最大长度为 64 个字符。 因此,使用 X.509 证书时,注册 ID 的长度限制为 64 个字符。

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

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

使用 X.509 证书控制设备对设置服务的访问权限

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

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

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

相互 TLS 支持

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

DPS 设备链要求

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

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

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

Example device certificate chain

在本例中,仅验证根证书,并将 intermediate2 证书上传到注册组。

Example root verified

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

Example failing certificate chain

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

Example device certificate chain

带证书的 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 进行注册