Subject line varies depending on order of fields.

[Gisleburt]

I asked a question on StackOverflow recently but this may be an actual bug so I thought I'd report it here too.

When creating a CSR, the subject line seems to vary depending on the order of parameters:

For example:

$ 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

Which doesn't look right anyway. I don't know if emailAddress is a valid field name, however it is requested when entering the field using the subject prompt in LibreSSL 2.2.7 on OSX, installed via brew, and that will give you the same output.

Further, if you move emailAddress to the beginning of the subject, it then becomes comma seperated:

$ 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"

Subject: emailAddress=me@my.domain, C=UK, L=London, O=Org, OU=Unit, CN=my.domain

Not sure how important it is, so long as the subject line doesn't change, the signature will be valid.

[kinichiro]

I tried to see this issue.
At first, I generated private key and CSR by these commands.

$ openssl genpkey -algorithm RSA -out my.key
$ 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"

I checked subject of generated CSR by this commad,
and I confirmed emailAddress was merged into CN value.

$ openssl req -in my.csr -text -noout
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=UK, L=London, O=Org, OU=Unit, CN=my.domain/emailAddress=me@my.domain
...

I also tried to parse CSR by perspective of ASN1 by this command,
and I found emailAddress was successfully separated from CN.

$ openssl asn1parse -in my.csr -inform PEM -dump
    0:d=0  hl=4 l= 689 cons: SEQUENCE
    4:d=1  hl=4 l= 409 cons: SEQUENCE
    8:d=2  hl=2 l=   1 prim: INTEGER           :00
   11:d=2  hl=2 l= 108 cons: SEQUENCE
   13:d=3  hl=2 l=  11 cons: SET
   15:d=4  hl=2 l=   9 cons: SEQUENCE
   17:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   22:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :UK
   26:d=3  hl=2 l=  15 cons: SET
   28:d=4  hl=2 l=  13 cons: SEQUENCE
   30:d=5  hl=2 l=   3 prim: OBJECT            :localityName
   35:d=5  hl=2 l=   6 prim: UTF8STRING        :London
   43:d=3  hl=2 l=  12 cons: SET
   45:d=4  hl=2 l=  10 cons: SEQUENCE
   47:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   52:d=5  hl=2 l=   3 prim: UTF8STRING        :Org
   57:d=3  hl=2 l=  13 cons: SET
   59:d=4  hl=2 l=  11 cons: SEQUENCE
   61:d=5  hl=2 l=   3 prim: OBJECT            :organizationalUnitName
   66:d=5  hl=2 l=   4 prim: UTF8STRING        :Unit
   72:d=3  hl=2 l=  18 cons: SET
   74:d=4  hl=2 l=  16 cons: SEQUENCE
   76:d=5  hl=2 l=   3 prim: OBJECT            :commonName
   81:d=5  hl=2 l=   9 prim: UTF8STRING        :my.domain
   92:d=3  hl=2 l=  27 cons: SET
   94:d=4  hl=2 l=  25 cons: SEQUENCE
   96:d=5  hl=2 l=   9 prim: OBJECT            :emailAddress
  107:d=5  hl=2 l=  12 prim: IA5STRING         :me@my.domain
  121:d=2  hl=4 l= 290 cons: SEQUENCE
  125:d=3  hl=2 l=  13 cons: SEQUENCE
  127:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
  138:d=4  hl=2 l=   0 prim: NULL
  140:d=3  hl=4 l= 271 prim: BIT STRING
...

I could not get an answer yet, though, this issue might just a subject display probrem.

[kinichiro]

X509_NAME_print() in crypto/asn1/t_x509.c appears to cause this issue.
It can handle upper cased 1 byte or 2bytes subject string only.
And man page says

The functions X509_NAME_oneline() and X509_NAME_print() are legacy
functions which produce a non-standard output form.  They don't handle
multi-character fields and have various quirks and inconsistencies.
Their use is strongly discouraged in new applications.

[kinichiro]

@Gisleburt Can you close this issue ?