Closed
Bug 58507
Opened 24 years ago
Closed 18 years ago
OCSP requires the CA to have extendedKeyUsage extensions
Categories
(NSS :: Libraries, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
3.11.6
People
(Reporter: javi, Assigned: alvolkov.bgs)
References
Details
When testing OCSP, thomask found out that NSS requires the CA to have the extendedKeyUsage bit for OCSP responder even if the signer is the issuer of the cert in question. This goes against the spec and should be fixed. Subject: Re: PSM Date: Mon, 30 Oct 2000 13:36:53 -0800 From: javi@netscape.com (Javier Delgadillo) Internal To: Thomas Kwan <thomask@netscape.com> References: 1 , 2 , 3 Invalid Signature You're right. NSS requires the CA have the extendedKeyUsage bit set even if it's the issuing cert for the cert in question. File a bug against NSS in bugzilla. Thomas Kwan wrote: Sorry, the URL for the OCSP server is http://192.18.121.247:80/ocsp Javier Delgadillo wrote: What responder am I supposed to talk to? The cert doesn't have the AIA extension. Thomas Kwan wrote: Hi Javier, Last week, Brian, you and me was looking at the OCSP problem where we forgot to put the extendedKeyUsage extension in the OCSP certificate, and PSm returned "....unknown problem". I just setup a standalone CA and its OCSP signing certificate is its Ca siging certificate. I just looked at the OCSP spec., and seems like we do not need the extendedKeyUsage extension in the CA certificate if the OCSP signing certificate is actually the CA certificate. But I am getting the same error from PSM "... unknown problem". I wonder if you can help me to try this out: My CA is in http://192.18.121.247:80, use the directory-based enrollment with "thomask", and "netscape" to get a user certificate. The OCSP server is running in http://192.18.121.247:80 thanks a lot Thomas -- Javier Delgadillo iPlanet a SUN / Netscape Alliance (408) 276-3977 http://people.netscape.com/javi
Comment 1•24 years ago
|
||
Is this easy to fix? Terry, could you take a look at this bug? Thanks.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Updated•24 years ago
|
Target Milestone: --- → 3.3
Comment 2•24 years ago
|
||
Assigned the bug to Bob for triage.
Assignee: wtc → relyea
Status: ASSIGNED → NEW
Updated•23 years ago
|
Target Milestone: 3.3 → 3.4
Comment 3•22 years ago
|
||
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Updated•22 years ago
|
Target Milestone: 3.4 → 3.5
Updated•22 years ago
|
Target Milestone: 3.6 → Future
Comment 5•21 years ago
|
||
I don't think we can turn OCSP on by default again until this is fixed.
Priority: P3 → P2
Target Milestone: Future → 3.10
Updated•21 years ago
|
Blocks: ocspdefault
Updated•19 years ago
|
QA Contact: bishakhabanerjee → jason.m.reid
Updated•19 years ago
|
Target Milestone: 3.10 → 3.12
Updated•18 years ago
|
QA Contact: jason.m.reid → libraries
Comment 6•18 years ago
|
||
Is this bug already fixed? I can see our OCSP code calls CERT_VerifyCert asking for usage certUsageStatusResponder. We require that the OCSP signing cert has KU_KEY_CERT_SIGN and its type is NS_CERT_TYPE_OBJECT_SIGNING_CA | NS_CERT_TYPE_EMAIL_CA | NS_CERT_TYPE_SSL_CA If true, it will test whether the signing cert already has a direct trust. case certUsageStatusResponder: flags = cert->trust->sslFlags; /* is the cert directly trusted or not trusted ? */ if ( ( flags & ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) == ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) { goto winner; } flags = cert->trust->emailFlags; /* is the cert directly trusted or not trusted ? */ if ( ( flags & ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) == ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) { goto winner; } flags = cert->trust->objectSigningFlags; /* is the cert directly trusted or not trusted ? */ if ( ( flags & ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) == ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) { goto winner; } I think in the mentioned scenario, that direct trust will be present?
Comment 7•18 years ago
|
||
This bug appears to be a reference to the code in ocsp_CertIsOCSPSigner() http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certhigh/ocsp.c&rev=1.29#2433 Doesn't look fixed to me. See also bug 338986 comment 3 for an issue that is related, or perhaps even the same issue described in more depth.
Comment 8•18 years ago
|
||
Kai, please see my response to your question in the preceeding comment.
Comment 9•18 years ago
|
||
I think the patch for bug 338986 fixes this problem. I'm reluctant to mark this old bug as a duplicate of a much newer one, so I'll mark the new one as blocking this old one, and assign this old bug to Alexei (who is working on bug 338986). Alexei can mark this bug resolved/fixed when bug 338986 is marked that way.
Assignee: rrelyea → alexei.volkov.bugs
Depends on: 338986
Assignee | ||
Comment 11•18 years ago
|
||
fixed as a part of the fix for bug 338986
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•