How many formats of x.509 client certificate file are there?

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 use开发者_开发百科r's firm name.

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.

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?

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.

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).

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).

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.

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.

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.

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).

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.