我正在处理一项任务，即当用户向服务器发送请求时获取客户端证书。我必须获取证书并从证书中获取 3 条信息：用户名、用户的电子邮件地址和用户的公司名称。
起初，仅获取用户名的“主题 CN”、电子邮件地址的“主题 E”和公司名称的“主题 OU”似乎很简单。
但后来我意识到有很多不同的 CA 和工具，它们以不同的格式颁发证书。例如，一些证书在“主题”字段中根本没有电子邮件地址字段，但将其存储在 SubjectAlternativeName 扩展名中，用户名存储在“主题 O”中，另一些证书在“主题 CN”字段中具有电子邮件以及公司的url地址。
我想知道是否有任何方法可以确定用户的姓名、公司名称和电子邮件地址？如果没有，是否有证书格式的任何标准，以便这些信息存储在多个位置，或者它们只是在证书的任何字段中创建？
最后一个问题是：如果一个网站支持来自“所有”CA 的客户端证书，那么我们在谈论多少个 CA？这种情况是常见的还是大多数网站只支持它选择的 1-2 个 CA？
非常感谢您的任何回复，我脑子里有太多问题。
主题专有名称（Subject DN）是相对专有名称（RDN）的有序序列，每个RDN是一组无序的属性值断言（AVA）。AVA 类似于“CN=yourname”或“O=yourorganization”（尽管它们没有像那样存储在证书中）。
大多数时候，每个 RDN 只会有一个 AVA，因此，除非这是一个奇怪的情况，否则通常可以将其称为主题 DN 的 CN RDN（或者甚至是“字段”我猜，如果你不需要太具体）。将主题 DN 序列化为可读字符串有多种标准，特别是从左到右或从右到左，或E=vs emailAddress=，或逗号或斜杠分隔符。您应该首先确保您的工具能够从它们的 OID（对象标识符）而不是字符串表示中读取它们。
通常，序列将是国家、组织、组织单位、通用名称，也许还有电子邮件（尽管电子邮件地址总是有问题，因为它是那些并不总是以相同方式序列化为字符串的那些，具体取决于使用的标准）。
一般来说，CA 可以根据主题 DN 的结构自由地做他们想做的事，以及他们是否使用主题替代名称扩展。这些事情往往受每个 CA 政策（可能是相当长的技术和法律文件）的监管。在这个领域没有一种适合所有人的尺寸。
在接受客户证书之前，您应该确保您同意他们的政策。一旦您信任 CA 证书，PKI 模型就很难在此之后进行细粒度的选择。
受信任的 CA 列表取决于平台和配置。默认情况下，OSX 上的 Java 在其信任库中有大约 150 个 CA 证书，我认为在其他平台上大约有 70 个。这些数字可能会有很大差异。
无论如何，如果您确实想接受客户端证书，您或多或少需要知道它们来自哪里，因此通常情况下，您将拥有一小部分您愿意为此信任的 CA。我绝对建议在仔细手动选择（基于策略文档）后配置您愿意信任哪些 CA 进行客户端证书身份验证。
在实践中，我不确定为什么客户端会像这样将他们的证书随机发送到任何服务器。用于客户端证书的 PKI 往往在封闭的管理域中或在完善的联盟中工作得更好，在这种情况下，您和您的用户将属于这些组织，并且您将知道期望哪个 CA。此外，我建议限制使用客户端证书来验证用户，同时从其他地方获取更多属性，例如 LDAP 服务器。通常，客户证书将发放给个人一年或更长时间，而有关个人（甚至组织单位）的信息在实践中可能会发生变化。如果您想使用 CA 或设置自己的 CA，则必须考虑所有这些。