Mixing
How do I use configure OpenSSL's policy to sign a certificate with multiple OUs?
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?
ssl openssl policy organizational-unit certificate-signing-request
asked Dec 31 '18 at 23:45
Andrew GeorgeAndrew George
61
add a comment |
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?
ssl openssl policy organizational-unit certificate-signing-request
asked Dec 31 '18 at 23:45
Andrew GeorgeAndrew George
61
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 valuegroup - subgroup.
– Steffen Ullrich
Jan 1 at 8: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 1 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 1 at 11:16
add a comment |
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?
ssl openssl policy organizational-unit certificate-signing-request
asked Dec 31 '18 at 23:45
Andrew GeorgeAndrew George
61
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?
ssl openssl policy organizational-unit certificate-signing-request
ssl openssl policy organizational-unit certificate-signing-request
asked Dec 31 '18 at 23:45
Andrew GeorgeAndrew George
61
asked Dec 31 '18 at 23:45
Andrew GeorgeAndrew George
61
asked Dec 31 '18 at 23:45
Andrew GeorgeAndrew George
61
asked Dec 31 '18 at 23:45
Andrew GeorgeAndrew George
61
asked Dec 31 '18 at 23:45
Andrew GeorgeAndrew George
61
61
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 valuegroup - subgroup.
– Steffen Ullrich
Jan 1 at 8: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 1 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 1 at 11:16
add a comment |
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 valuegroup - subgroup.
– Steffen Ullrich
Jan 1 at 8: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 1 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 1 at 11:16
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 1 at 8:57
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 1 at 8: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 1 at 10:44
@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 1 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 1 at 11:16
@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 1 at 11:16
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Jan 1 at 10:58
dave_thompson_085dave_thompson_085
13.5k11633
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53992170%2fhow-do-i-use-configure-openssls-policy-to-sign-a-certificate-with-multiple-ous%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Jan 1 at 10:58
dave_thompson_085dave_thompson_085
13.5k11633
add a comment |
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.
answered Jan 1 at 10:58
dave_thompson_085dave_thompson_085
13.5k11633
add a comment |
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.
answered Jan 1 at 10:58
dave_thompson_085dave_thompson_085
13.5k11633
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.
answered Jan 1 at 10:58
dave_thompson_085dave_thompson_085
13.5k11633
answered Jan 1 at 10:58
dave_thompson_085dave_thompson_085
13.5k11633
answered Jan 1 at 10:58
dave_thompson_085dave_thompson_085
13.5k11633
answered Jan 1 at 10:58
dave_thompson_085dave_thompson_085
13.5k11633
13.5k11633
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53992170%2fhow-do-i-use-configure-openssls-policy-to-sign-a-certificate-with-multiple-ous%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 1 at 8: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 1 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 1 at 11:16