我正在使用 X.509 客户端证书通过相互 TLS 验证一组 Windows 客户端。哪些客户端属于这组客户端应该以某种方式在 AD 中进行管理，例如通过组成员身份或父 OU。
注意：该问题适用于计算机证书，而不适用于用户证书。即任何用户在从此类计算机启动 HTTPS 请求时都应该能够使用此证书。（这是对任何用户登录方法的补充，它不属于 mTLS 身份验证方案的一部分。）
服务器应该能够分辨出进行身份验证的客户端计算机是此集合的成员。服务器是基于 Linux 的容器，而不是 AD/域的一部分，因此我们拥有的只是 X.509 证书中的信息。
Windows 证书模板是否提供了任何方法来将此类声明作为 X.509 证书的一部分传达？似乎我可以限制可以获得此类证书的计算机集，但我找不到一种方法来标记这些证书以便服务器可以识别它们。
- X.509 证书不包含管理模板名称或 ID，因此我无法设置服务器来检查它。
- 配置主题的灵活性似乎有限，特别是没有方法将任何 AD 信息映射到主题字段。这将是理想的 - 我是否遗漏了什么？
- 我正在考虑为这些模板使用特定的中间 CA，但对于如此基本的要求来说这似乎太复杂了。
也许 X.509 证书还有另一个方面可以通过模板进行设置？或者我可以使用与组/OU 不同的声明吗？
答案1
答案是否定的。组成员身份是动态属性，而不是静态属性，也不是证书持有者身份的一部分。因此，您不能将组成员身份包含在证书中，因为此信息不属于身份。并且每次更改组成员身份时，您都必须重新颁发证书。证书的有效期相当长。这是一个非常有缺陷的解决方案。
即任何用户从此类计算机启动 HTTPS 请求时都应该能够使用此证书
这仅在从在本地系统或网络服务帐户下运行的应用程序发送 TLS 请求时才有效。如果您想使用此类证书，您必须通过源代码明确配置 TLS 客户端以使用非默认客户端证书。
服务器是基于 Linux 的容器，不属于 AD/域的一部分
有趣的是，基于 Linux 的服务器应该如何验证实际的组成员身份？
双向 TLS 中的客户端证书是身份验证方法。证书中的字段映射到必须连接到的帐户信息服务器。
由于您的 Linux 服务器不属于任何 AD，因此它们无法将客户端证书绑定到 AD 用户帐户并验证组成员身份。服务器甚至无法判断此类组是否真的存在。Linux 服务器必须有一个单独的身份数据库，并且 Linux 服务器必须以某种方式将客户端证书绑定到该单独身份数据库中的身份。并且只有此单独身份数据库中可用的信息才可用于客户端授权。
这意味着您的要求：
应在 AD 中管理计算机的组成员身份。
和
服务器是基于 Linux 的容器，不属于 AD/域的一部分
是相互排斥的，不能一起使用。要么让 Linux 服务器具备 AD 感知能力，要么在证书中包含 Linux 服务器可用的身份信息。我强烈避免在证书中包含组成员身份。组成员身份应该用在短期令牌中，而不是长期证书中。