Closed
Bug 414561
Opened 18 years ago
Closed 18 years ago
Crlutil returns exit code 0 when adding wrong CRL (PKITS test 4.4.6)
Categories
(NSS :: Libraries, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
3.12
People
(Reporter: slavomir.katuscak+mozilla, Assigned: julien.pierre)
Details
PKITS test 4.4.6 (Invalid Wrong CRL) fails for NSS.
Importing wrong certificate returns exit code 0 what means success, but CRL is not imported (can't see it in crlutil -L).
| Assignee | ||
Comment 1•18 years ago
|
||
Slavo,
There isn't enough information in this bug report.
certutil does not verify certificates at the time of import. As long as the certificate is valid DER and all the command-line options are OK, the import should succeed.
Is your failure importing the CRL rather than the certificate ?
crlutil tries to verify the CRL at time of import, unless you specify the -B option to bypass the CA certificate check together with -I.
Please add more details about what specifically failred.
| Reporter | ||
Comment 2•18 years ago
|
||
I just corrected Summary field, this problem occured in crlutil, not certutil.
From logfile:
---
Test case Invalid Wrong CRL Test6
certutil -d /export/home/sven/nss/securitytip/mozilla/tests_results/security/solaris-devx.21/pkits/PKITSdb -A -t ",," -n WrongCRLCACert -i ../../../../PKITS_DATA/certs/WrongCRLCACert.crt
crlutil -d /export/home/sven/nss/securitytip/mozilla/tests_results/security/solaris-devx.21/pkits/PKITSdb -I -i ../../../../PKITS_DATA/crls/WrongCRLCACRL.crl
pkits.sh: #32: Invalid Wrong CRL Test6 (0) - FAILED
pkits.sh ERROR: Invalid Wrong CRL Test6 failed 0
---
You can find more info in PKITS tests description and data here: http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html
Summary: Certutil returns exit code 0 when adding wrong CRL (PKITS test 4.4.6) → Crlutil returns exit code 0 when adding wrong CRL (PKITS test 4.4.6)
| Assignee | ||
Comment 3•18 years ago
|
||
Slavo,
I tried running the pkits.sh script to reproduce this issue.
It appears that it reuses the same PKITSdb directory for each test. The same DB gets modified after each test. This makes it rather difficult to recreate the actual state of the DB at the beginning of test 4.4.6 . I would recommend that we start over with a fresh DB for each test.
I read the description of this test from NIST and examined the data files.
There are a couple issues in the way of NSS passing this test :
1) The files TrustAnchorRootCRL.crl and WrongCRLCACRL.crl are for the same issuer - the subject of the root CA.
This means the root CA must be installed prior to importing WrongCRLCACRL.crl , or the CRL import will fail, unless -B is specified to bypass the signature check.
Also, the softoken can only store one CRL at a time per subject. So, one CRL will override the other during the import.
2) Not only do the files TrustAnchorRootCRL.crl and WrongCRLCACRL.crl have the the same issuer - they are completely binary identical.
This means the second import of the WrongCRLCACRL will succeed, but it will be a no-op - the existing CRL will be overwritten by an identical one.
3) The test depends on the ability of vfychain to enforce the NIST CRL policy - which says that we need to have a CRL for every cert in the chain .
At this time, vfychain uses CERT_VerifyCertificate, which doesn't have the ability to enforce the NIST CRL policy.
We need vfychain to be modified to use the new CERT_VerifyPKIXCert, and configure it to enforce the NIST CRL policy, to pass this test.
I tried to pass the -p argument to vfychain to do that, but I got :
[jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 594 % ./vfychain -p -d . -u 4 /home/jp96085/nist_pkits/certs/InvalidWrongCRLTest6EE.crt /home/jp96085/nist_pkits/certs/WrongCRLCACert.crt
Chain is good!
Assertion failure: secmod_PrivateModuleCount == 0, at pk11util.c:120
Abort (core dumped)
In other words, the NIST CRL policy was not enforced, and we got a reference leak.
4) The pkits.sh script tries to delete the CRL for WrongCACRLCert . But there is no such CRL - only the CRL for the root CA. The script should be modified not to attempt to do this.
| Assignee | ||
Comment 4•18 years ago
|
||
To clarify the above comment, there is no bug in crlutil here. It is being told to import the root CA CRL a second time, and does it happily. This is why it returns 0. So, I'm marking this bug as invalid. Please use the rest of comment 3 to resolve the other issues you will face in completing the run of test 4.4.6 .
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
| Reporter | ||
Comment 5•18 years ago
|
||
In this case we have there 2 issues:
1. Bug in pkits.sh script - we expect CRL import to fail
2. Bug in pkits.sh script - we are trying to import CRL with non existing name
3. We don't use NIST CRL policy.
I think first 2 issues should be fixed within this bug (I can do this), for third there should be at least reported bug/RFE.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 6•18 years ago
|
||
Slavo, none of the 3 issues you described in comment 5 match the subject of
this bug. Bugs in pkits.sh are test bugs, not libraries bugs. This bug is
(or was) about crlutil. Please do not morph this bug to have another subject,
but instead file another bug.
If there isn't already such a bug, then a tools RFE should be filed to
enhance vfychain to optionally use the NIST CRL policy. Please check for
an existing bug before attempting to file a new one.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•