1

I've recently starting configuring a CA with OpenSSL. The root CA requires intermediary CA certificates to have an OU field such that the intermediate CA's DN looks like OU=group.

With that intermediate CA, I've defined the policy for CSRs it can sign as follows:

[ policy_match ] organizationUnitName=match

The CSRs I'm attempting to sign have DNs like OU=group, OU=subgroup, but the command openssl ca -in two_OUs.csr spits out the error: The organizationalUnitName field needed to be the same in the CA certificate (group) and the request (subgroup).

I've attempted to modify the policy in two ways:

[ policy_match ] organizationUnitName=match organizationUnitName=supplied

[ policy_match ] 0.organizationUnitName=match 1.organizationUnitName=supplied

The first succeeds, but does not enforce the requirement of having two OUs. The second fails, complaining of 0.organizationalUnitName:unknown object type in 'policy' configuration

Short of bypassing the ca command all together in favor of the x509 command, how can I resolve this?

Andrew George
  • 11
  • 1
  • There is no concept of multiple OU for certificates. To describe the hierarchy in a DN you can use ON (organizationName) and the level below is OU. There are no additional levels below that and you cannot just specify multiple OU to implement such thing. But you could create a single OU with the value `group - subgroup`. – Steffen Ullrich Jan 01 '19 at 08:57
  • @SteffenUllrich: says who? The access control example currently in annex N of ITU-T X.501 = ISO/IEC 9594-2 uses two levels of OU -- _under_ O, which is the standard shortname for Organization, not ON, and X.520 = 9594-6 says OU is 'understood to be part of' and 'shall be associated with' O, which I interpret as 'must be subordinate to' although it doesn't quite say so explicitly. – dave_thompson_085 Jan 01 '19 at 10:44
  • @dave_thompson_085: as always thanks for your wise input. I've only had a look at RFC 3039 section 3.1.2 (Subject) and while it does not explicitly say that each attribute can only occur once, the phrasing on multiple places suggested to me that it assumes that each of the possible attributes will occur at most once. – Steffen Ullrich Jan 01 '19 at 11:16

1 Answers1

1

You can't directly CHECK it. The openssl ca policy logic can only check one occurrence of an attribute (exactly, an AVA in an RDN) for a given OID. From my reading of the code without actually stepping through it, I think it should check the first one, whereas it appears to be the last one in value you posted; are you posting values from something that uses the LDAP convention for displaying DNs 'backwards'?

And to be clear, you are not just saying the DN contains two OU's in this order, but that it consists entirely of them, without any O (OrganizationName)? If so, that appears to violate an X.520 rule, as I noted in my comment on your Q -- although AFAICS that rule is not carried into PKIX or even LDAP, and it is certainly not enforced by OpenSSL.

If you want to enforce your rule by checking the values of both OU's, you'll need to do it outside OpenSSL, for example by displaying the request info with openssl req and checking it with another program (perhaps a text-handling program like awk or perl).

You can use openssl ca to issue a cert for a name with repeated attributes like this (also attributes outside the policy) by using -preserveDN option or preserve=y config setting. This does the same thing x509 -req -CA* does by default.

dave_thompson_085
  • 34,712
  • 6
  • 50
  • 70