x.509 客户端证书文件有几种格式? [英] How many formats of x.509 client certificate file are there?

问题描述

我正在处理一项任务，即在用户向服务器发送请求时获取客户端证书.我要拿到证书，从证书中获取3条信息:用户名、用户邮箱和用户公司名称.

I am working on a task which is to get the client certificate when the user sends a request to the server. I have to get the certificate and get the 3 pieces of information from the certificate: user name, user's email address and user's firm name.

起初，获取用户名的Subject CN"、电子邮件地址的Subject E"和公司名称的subject OU"似乎很简单.

At first it seems quite simple to just get the "Subject CN" for user name, "Subject E" for email address and "subject OU" for the company name.

但后来我意识到有很多不同的 CA 和工具，它们以不同的格式颁发证书.例如，某些证书在主题"字段中根本没有电子邮件地址字段，而是将其存储在 SubjectAlternativeName 扩展名中，并且用户名存储在主题 O"中，其他一些则在主题 CN"字段中包含电子邮件以及公司的网址.

But later I realise there are a lot of different CA and tools and they issue certificate in different formats. For example, some certificate does not have email address field at all in the "subject" field but stores it in the SubjectAlternativeName extension and the user name is stored in "subject O", some other have the email in the field "subject CN" and together with the url address of the company.

我想知道有没有什么办法可以确切地找出用户的姓名、公司名称和电子邮件地址?如果没有，是否有任何证书格式标准，以便将这些信息存储在多个位置，或者它们只是在证书的任何字段中创建?

I am wondering if there is any way I can definitely find out the user's name, firm name and email address? If not, if there is any standard for the certificate format so that these information are stored in several locations or are they just created in whichsoever field in the certificate?

最后一个问题是:如果一个网站支持来自所有"CA 的客户端证书，那么我们谈论的是多少个 CA?这种场景是常见的还是大部分网站只支持它选择的1-2个CA?

And the last question is: if a website support client certificate from "all" CAs, how many CAs are we talking about? Is this scenario common or most of the website just support 1-2 CAs which it chooses?

非常感谢您的回复，我脑子里的问题太多了.

Thanks a lot for any reply, I just get too many questions in my head.

推荐答案

主题专有名称 (Subject DN) 是相对专有名称 (RDN) 的有序序列，每个 RDN 是一组无序的属性值断言 (AVA)).AVA 类似于CN=yourname"或O=yourorganization"(尽管它们在证书中的存储方式并非如此).

The Subject Distinguished Name (Subject DN) is an ordered sequence of relative distinguished names (RDN), and each RDN is an unordered set of attribute value assertion (AVA). An AVA is something like "CN=yourname" or "O=yourorganization" (although they're not store like that in the certificate).

大多数情况下，每个 RDN 只有一个 AVA，因此，除非是特殊情况，否则通常可以将其称为主题 DN 的 CN RDN(或者甚至是字段"，我猜，如果您不需要太具体).将主题 DN 序列化为可读字符串有多种标准，特别是从左到右或从右到左，或 E= 与emailAddress=，或逗号或斜杠分隔符.您应该首先确保您的工具能够从它们的 OID(对象标识符)而不是字符串表示中读取它们.

Most of the time, there will only be one AVA per RDN, so, unless it's an odd case, it's often acceptable to call this the Subject DN's CN RDN for example (or even a "field" I guess, if you don't need to be too specific). There are multiple standards for serializing a Subject DN into a readable string, in particular left-to-right or right-to left, or E= v.s. emailAddress=, or coma or slash separator. You should first make sure you tool is able to read them from their OID (Object Identifier) rather than the string representation.

通常，序列将是国家、组织、组织单位、通用名称和电子邮件(尽管电子邮件地址总是有问题，因为它是那些并不总是以相同方式序列化为字符串的地址之一取决于使用的标准).

Often, the sequence will be country, organization, organizational unit, common name and perhaps e-mail (although e-mail address is always problematic since it's once of those that don't always serialize into a string in the same way depending on the standard used).

一般来说，CA 可以在主题 DN 的结构方面自由地做他们想做的事情，以及他们是否使用主题替代名称扩展.这些事情往往受每个 CA 政策(可能是很长的技术和法律文件)的监管.这个领域没有万能的.

In general, CAs are free to do what they want in terms of structure of the Subject DN, and whether or not they use the subject alternative name extensions. These things tend to be regulated by each CA policy (which can be quite long technical and legal documents). There is no one size fits all in this domain.

在接受客户证书之前，您应该确保同意他们的政策.一旦信任 CA 证书，PKI 模型就很难在此之后进行细粒度选择.

Before accepting client-certificates, you should make sure you agree with their policies. Once you trust a CA certificate, the PKI model is such that it's hard to do fine grained selection after that.

受信任的 CA 列表取决于平台和配置.默认情况下，OSX 上的 Java 在其信任库中有大约 150 个 CA 证书，我认为在其他平台上大约有 70 个.这些数字可能会有很大差异.

The list of trusted CAs depends on the platform and the configuration. By default, Java on OSX has about 150 CA certificates in its truststore, on other platforms it's about 70, I think. These numbers can vary substantially.

无论如何，如果您确实想接受客户端证书，您或多或少需要知道它们的来源，因此通常情况下，您将拥有一小部分您愿意信任的 CA.我绝对建议您在仔细手动选择(基于策略文档)后配置您愿意信任哪些 CA 进行客户端证书身份验证.

Anyway, if you do want to accept client certificates, you more or less need to know where they come from, so quite often, you will have a small subset of CAs you're willing to trust for that. I'd definitely recommend to configure which CAs you're willing to trust for client-certificate authentication after a careful manual selection (based on the policy documents).

在实践中，我不确定为什么客户端会像那样随机地将他们的证书发送到任何服务器.用于客户端证书的 PKI 往往在封闭的管理域或完善的联盟中工作得更好，在这种情况下，您和您的用户将属于这些组织，并且您将知道期望使用哪个 CA.此外，我建议限制使用客户端证书对用户进行身份验证，同时从其他地方获取更多属性，例如 LDAP 服务器.通常，客户证书将发给个人一年或更长时间，而有关个人(甚至组织单位)的信息在实践中可能会发生变化.如果您想使用 CA 或设置自己的 CA，则必须考虑所有这些.

In practice, I'm not sure why clients would send their certificate randomly to any server, just like that. PKIs for client certificates, tend to work better in a closed administrative domain, or within a well-established federation, in which case you and your users will belong to those organizations and you'll know which CA to expect. In addition, I'd suggest limiting the use of client-certificates for authenticating a user, while fetching further attributes from somewhere else, like and LDAP server. Typically, client-certificates will be emitted to an individual for a year or more, whereas the information about the individual (even organizational unit) may change in practice. All of this has to be considered if you want to use a CA or set up your own.

这篇关于x.509 客户端证书文件有几种格式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！