Opened 6 years ago

Closed 5 years ago

#387 closed Bug / Defect (fixed)

Multiple components of a DN are not reported to the environment

Reported by: tlhackque Owned by: Steffan Karger
Priority: major Milestone: beta 2.4
Component: Certificates Version: OpenVPN 2.3.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

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.

Change History (7)

comment:1 Changed 6 years ago by Gert Döring

Milestone: release 2.4
Owner: set to Steffan Karger
Status: newassigned

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.

comment:2 Changed 6 years ago by 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.

comment:3 Changed 6 years ago by 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.

comment:4 Changed 5 years ago by Steffan Karger

Milestone: release 2.4beta 2.4

comment:5 Changed 5 years ago by Gert Döring

related to #81?

comment:6 Changed 5 years ago by Steffan Karger

Status: assignedaccepted

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.

comment:7 Changed 5 years ago by Steffan Karger

Component: Generic / unclassifiedCertificates
Resolution: fixed
Status: acceptedclosed
Note: See TracTickets for help on using tickets.