can we check client certificate of same root ca against multiple crl servers (that each crl generated by same...
Certificates having 2 crl distribution point both signed by same root ca.
What should be crl fetch behaviour?
Crl fetched should be concated or overwritten?
can we check client certificate of same root ca against multiple crl servers (that each crl generated by same rootca )?
networking
asked Jan 18 at 7:31
user986736user986736
1
add a comment |
Certificates having 2 crl distribution point both signed by same root ca.
What should be crl fetch behaviour?
Crl fetched should be concated or overwritten?
can we check client certificate of same root ca against multiple crl servers (that each crl generated by same rootca )?
networking
asked Jan 18 at 7:31
user986736user986736
1
add a comment |
Certificates having 2 crl distribution point both signed by same root ca.
What should be crl fetch behaviour?
Crl fetched should be concated or overwritten?
can we check client certificate of same root ca against multiple crl servers (that each crl generated by same rootca )?
networking
asked Jan 18 at 7:31
user986736user986736
1
Certificates having 2 crl distribution point both signed by same root ca.
What should be crl fetch behaviour?
Crl fetched should be concated or overwritten?
can we check client certificate of same root ca against multiple crl servers (that each crl generated by same rootca )?
networking
networking
asked Jan 18 at 7:31
user986736user986736
1
asked Jan 18 at 7:31
user986736user986736
1
asked Jan 18 at 7:31
user986736user986736
1
asked Jan 18 at 7:31
user986736user986736
1
asked Jan 18 at 7:31
user986736user986736
1
1
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
It depends on whether they're separate distribution points, or whether they're just separate URLs in the same distribution point.
My interpretation of RFC 5280 section 4.2.1.13 and section 5:
A single "CRL Distribution Points" extension may have multiple DistributionPoint items pointing to different CRLs, possibly with different ReasonFlags (e.g. one CRL for superseded certificates, another CRL for compromised, even though the spec recommends against this) – therefore you need to check all DistributionPoints and concatenate the results.
But a single DistributionPoint may have multiple names (URLs) pointing to the same CRL. These act as alternatives (e.g. redundancy or multiple protocols), and you only need to check one URL for each DistributionPoint.
If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain the same CRL. For example,
the same CRL could be available for retrieval through both LDAP and
HTTP.
So for example, if you have a CRL DP extension with:
CRLDistributionPoints {
DistributionPoint {
fullName [ URI "http://foo/foo.crl", URI "ldap://foo/foo.crl" ]
},
DistributionPoint {
fullName [ URI "http://foo/bar.crl", URI "ldap://foo/bar.crl" ]
}
}
then you would need to check two CRLs total: any one "foo.crl" + any one "bar.crl".
answered Jan 18 at 7:45
grawitygrawity
237k37504558
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
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%2fsuperuser.com%2fquestions%2f1395644%2fcan-we-check-client-certificate-of-same-root-ca-against-multiple-crl-servers-th%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
It depends on whether they're separate distribution points, or whether they're just separate URLs in the same distribution point.
My interpretation of RFC 5280 section 4.2.1.13 and section 5:
A single "CRL Distribution Points" extension may have multiple DistributionPoint items pointing to different CRLs, possibly with different ReasonFlags (e.g. one CRL for superseded certificates, another CRL for compromised, even though the spec recommends against this) – therefore you need to check all DistributionPoints and concatenate the results.
But a single DistributionPoint may have multiple names (URLs) pointing to the same CRL. These act as alternatives (e.g. redundancy or multiple protocols), and you only need to check one URL for each DistributionPoint.
If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain the same CRL. For example,
the same CRL could be available for retrieval through both LDAP and
HTTP.
So for example, if you have a CRL DP extension with:
CRLDistributionPoints {
DistributionPoint {
fullName [ URI "http://foo/foo.crl", URI "ldap://foo/foo.crl" ]
},
DistributionPoint {
fullName [ URI "http://foo/bar.crl", URI "ldap://foo/bar.crl" ]
}
}
then you would need to check two CRLs total: any one "foo.crl" + any one "bar.crl".
answered Jan 18 at 7:45
grawitygrawity
237k37504558
add a comment |
It depends on whether they're separate distribution points, or whether they're just separate URLs in the same distribution point.
My interpretation of RFC 5280 section 4.2.1.13 and section 5:
A single "CRL Distribution Points" extension may have multiple DistributionPoint items pointing to different CRLs, possibly with different ReasonFlags (e.g. one CRL for superseded certificates, another CRL for compromised, even though the spec recommends against this) – therefore you need to check all DistributionPoints and concatenate the results.
But a single DistributionPoint may have multiple names (URLs) pointing to the same CRL. These act as alternatives (e.g. redundancy or multiple protocols), and you only need to check one URL for each DistributionPoint.
If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain the same CRL. For example,
the same CRL could be available for retrieval through both LDAP and
HTTP.
So for example, if you have a CRL DP extension with:
CRLDistributionPoints {
DistributionPoint {
fullName [ URI "http://foo/foo.crl", URI "ldap://foo/foo.crl" ]
},
DistributionPoint {
fullName [ URI "http://foo/bar.crl", URI "ldap://foo/bar.crl" ]
}
}
then you would need to check two CRLs total: any one "foo.crl" + any one "bar.crl".
answered Jan 18 at 7:45
grawitygrawity
237k37504558
add a comment |
It depends on whether they're separate distribution points, or whether they're just separate URLs in the same distribution point.
My interpretation of RFC 5280 section 4.2.1.13 and section 5:
A single "CRL Distribution Points" extension may have multiple DistributionPoint items pointing to different CRLs, possibly with different ReasonFlags (e.g. one CRL for superseded certificates, another CRL for compromised, even though the spec recommends against this) – therefore you need to check all DistributionPoints and concatenate the results.
But a single DistributionPoint may have multiple names (URLs) pointing to the same CRL. These act as alternatives (e.g. redundancy or multiple protocols), and you only need to check one URL for each DistributionPoint.
If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain the same CRL. For example,
the same CRL could be available for retrieval through both LDAP and
HTTP.
So for example, if you have a CRL DP extension with:
CRLDistributionPoints {
DistributionPoint {
fullName [ URI "http://foo/foo.crl", URI "ldap://foo/foo.crl" ]
},
DistributionPoint {
fullName [ URI "http://foo/bar.crl", URI "ldap://foo/bar.crl" ]
}
}
then you would need to check two CRLs total: any one "foo.crl" + any one "bar.crl".
answered Jan 18 at 7:45
grawitygrawity
237k37504558
It depends on whether they're separate distribution points, or whether they're just separate URLs in the same distribution point.
My interpretation of RFC 5280 section 4.2.1.13 and section 5:
A single "CRL Distribution Points" extension may have multiple DistributionPoint items pointing to different CRLs, possibly with different ReasonFlags (e.g. one CRL for superseded certificates, another CRL for compromised, even though the spec recommends against this) – therefore you need to check all DistributionPoints and concatenate the results.
But a single DistributionPoint may have multiple names (URLs) pointing to the same CRL. These act as alternatives (e.g. redundancy or multiple protocols), and you only need to check one URL for each DistributionPoint.
If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain the same CRL. For example,
the same CRL could be available for retrieval through both LDAP and
HTTP.
So for example, if you have a CRL DP extension with:
CRLDistributionPoints {
DistributionPoint {
fullName [ URI "http://foo/foo.crl", URI "ldap://foo/foo.crl" ]
},
DistributionPoint {
fullName [ URI "http://foo/bar.crl", URI "ldap://foo/bar.crl" ]
}
}
then you would need to check two CRLs total: any one "foo.crl" + any one "bar.crl".
answered Jan 18 at 7:45
grawitygrawity
237k37504558
edited Jan 18 at 7:51
answered Jan 18 at 7:45
grawitygrawity
237k37504558
answered Jan 18 at 7:45
grawitygrawity
237k37504558
answered Jan 18 at 7:45
grawitygrawity
237k37504558
237k37504558
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- 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%2fsuperuser.com%2fquestions%2f1395644%2fcan-we-check-client-certificate-of-same-root-ca-against-multiple-crl-servers-th%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
