I'm writing a simple script to generate CSRs for our staff without them having to worry about all the fiddly bits openssl requires and I've noticed an issue with the emailAddress part of the subject.
When filling in the options given by the CLI, my subject is roughly:
Subject: C=UK, L=London, O=Org, OU=Unit, CN=my.domain/emailAddress=me@my.domain
If I use the -subj option on the command line and keep the parameters the same order, the result is the same:
$ openssl req -new -key my.key -out my.csr \
-subj="/C=UK/L=London/O=Org/OU=Unit/CN=my.domain/emailAddress=me@my.domain"
gives
Subject: C=UK, L=London, O=Org, OU=Unit, CN=my.domain/emailAddress=me@my.domain
But, if I put emailAddress at the front
$ openssl req -new -key my.key -out my.csr \
-subj="/emailAddress=me@my.domain/C=UK/L=London/O=Org/OU=Unit/CN=my.domain"
I get
Subject: emailAddress=me@my.domain, C=UK, L=London, O=Org, OU=Unit, CN=my.domain
What I'd like to understand is:
my.domain/emailAddress=me@my.domain a valid CommonName?emailAddress a valid subject name?The certs are for client authentication, and from a security point of view I think this doesn't matter but I am curious.
(RFC5280 is either lacking this information or I don't understand it... probably the later)
What is CommonName specifically for?
RFC5280, sec. 4.1.2.4 refers to X.520 (..."Standard sets of attributes have been defined in the X.500 series of specifications [X.520]"). ITU-T recommendation on X.520 (see the linked PDF, section 6.2.2) gives some general talk on what CommonName is. A one-sentence quote might be:
...it is a (possibly ambiguous) name by which the object is commonly known in some limited scope (such as an organization) and conforms to the naming conventions of the country or culture with which it is associated.
Is my.domain/emailAddress=me@my.domain a valid CommonName?
CommonName may contain arbitrary string, so this would have been a valid CN. But your CSR does not have it. Both of your CSRs have, in fact, CN=my.domain. OpenSSL just shows the emailAddress subject field via slash, which is admittedly confusing! (OpenSSL FAQ calls this "the old behavior"; I do not know why such behavior was present in "the old".) OpenSSL req has option -nameopt (documented in man x509), e.g. openssl req [...] -nameopt RFC2253 will show you the subject without such confusion.
Is emailAddress a valid subject name?
Did you intend to ask "Is emailAddress a valid part of a representation of a subject name"?
Subject name, according to RFC5280 4.1.2.6, "...MUST contain an X.500 distinguished name". In turn, distinguished name, according to RFC1779, is a list of key-value pairs, and anything with an OID can be the key. Instead of the numerical OID, a "keyword" may be used; RFC1779 friendly states that "A register of valid keywords is maintained by the IANA." Well, emailAddress has OID 1.2.840.113549.1.9.1, so it should count as "valid". It is specifically mentioned in RFC2985. (And of course OpenSSL recognizes it; it is listed in objects.h header.)
(RFC5280 is either lacking this information or I don't understand it... probably the later)
To me it looks like the former!
Now, one thing from your question remains a question to me: what is different in two CSRs you demonstrated, which makes openssl req show them in two different ways.