Multiple components of a DN are not reported to the environment

[tlhackque]

Consider this cert:

openssl x509 -in john.cer -noout -subject
subject= /C=US/ST=State/L=City/O=Minicorp/OU=Department/OU=Group/CN=John Smith/emailAddress=john@…

Note that this cert's Subject has two OU components (this is quite common in large deployments). In the environment variables, only one shows up as:

X509_0_OU=Group A (The last OU seen in DN order)

Both should be made available in the DN order. E.g.

X509_0_OU=Department
X509_0_OU.1=Group A

Note that pretty much any RDN component can have multiple values, and the order is significant. This applies both to issuers and to subjects.

[Gert Döring]

I'm not a crypto expert, so I'm handing this to Syzzer to comment.

What I can say is that we're very likely not going to change this in the 2.3.x series - this looks like a large change, and 2.3.x really should only get bug fixes and long-term compatibility stuff.

[tlhackque]

This is a major omission - but should not be a major change. Although the tradition is that the first OU has no suffix and the second+ get numbered, there's no reason why a compatible approach can't be taken, e.g. e.g. for the example define environment variables:

X509_0_OU.1=Department
X509_0_OU.2=Group A

# For legacy scripts that depend on the last of a series to be in the un-numbered variable:
X509_0_OU=Group A

This will work with any current script that depends on the misbehavior.

I would argue (strongly) that not reporting all the components of a DN (That's 'distinguished name' in X509 jargon) is a bug.

Doing the right thing by adding variable for all the components is definitely in the interest of long-term compatibility.

That said, which release gets an edit is always an interesting discussion. It should be made based on a common understanding of the facts.

[Steffan Karger]

This indeed sounds like a bug / shortcoming to me. I think the second proposed approach makes the most sense, because backward compatibility is considered important for OpenVPN.

Patches are welcome here or on the openvpn-devel mailinglist. Otherwise this will have to wait until I get to it myself.

[Gert Döring]

related to #81?

[Steffan Karger]

In the past 1,5 year nobody else got to it, but finally I got to it myself. A patch to add this has been committed to the master branch:
​https://github.com/OpenVPN/openvpn/commit/13b585e8

This means the functionality will be available in OpenVPN 2.4. Alternatively, you could compile and run a server using the git-master code.