Closed Bug 324878 Opened 19 years ago Closed 18 years ago

crlutil -L outputs false CRL names

Categories

(NSS :: Tools, defect, P2)

3.11
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nelson, Assigned: alvolkov.bgs)

Details

Attachments

(1 file, 2 obsolete files)

crlutil -L -d <dir>               outputs a list of CRL names, one per CRL.
crlutil -L -d <dir> -n <nickname> outputs the pretty printed content of one CRL.

The output of the first command should include nicknames that can be used 
in the second (-n) form of the command.   
But the names output by the first command are not CRL nicknames.  That is,
those output names cannot be used as the nickname argument in the -n form
of the command shown above.  So, the output of the first command is pretty
useless.  I can get a list of CRL names, but cannot use those names to see
the CRLs themselves.  

The nickname desired by the -n form of the command is the nickname of the
cert of the CA that issued the CRL.  But there's no good way to find that
nickname from the output of the first crlutil command.  IMO, the first 
command should find and output the nickname of the CA cert, so that the 
user can get the nickname for the second form of the command directly from
the output of the first command.

Example:

+ crlutil -L -d server
CRL names                                CRL Type
CN=NSS Test CA,O=BOGUS NSS,L=Mountain View,ST=California,C=US CRL

+ certutil -L -d server
BIJOU.red.iplanet.com                                        u,u,u
TestCA                                                       CT,C,C

+ certutil -L -d server -n "CN=NSS Test CA,O=BOGUS NSS,L=Mountain View,ST=California,C=US CRL"
certutil: Could not find: CN=NSS Test CA,O=BOGUS NSS,L=Mountain View,ST=Californ
ia,C=US CRL: security library: bad database.

+ crlutil -L -d server -n TestCA
CRL Info:
    Version: 2 (0x1)
    Signature Algorithm: PKCS #1 MD5 With RSA Encryption
    Issuer: "CN=NSS Test CA,O=BOGUS NSS,L=Mountain View,ST=California,C=US"
    This Update: Thu Jan 26 15:50:31 2006
    Entry (1):
        Serial Number: 40 (0x28)
        Revocation Date: Thu Jan 26 15:50:10 2006
        Entry Extensions:
            Name: CRL reason code

    Entry (2):
        Serial Number: 42 (0x2a)
        Revocation Date: Thu Jan 26 15:50:34 2006
    CRL Extensions:
        Name: Certificate Issuer Alt Name
        RFC822 Name: "caemail@ca.com"
        DNS name: "ca.com"
        Directory Name: "CN=NSS Test CA,O=BOGUS NSS,L=Mountain View,ST=Califo
            rnia,C=US"
        URI: "http://ca.com"
        IP Address:
            87:0b:31:39:32:2e:31:36:38:2e:30:2e:31

That first command would be much more useful if it output the string "TestCA"
instead of "CN=NSS Test CA,O=BOGUS NSS,L=Mountain View,ST=California,C=US CRL"
Attached patch fix for reporter crl names (obsolete) — Splinter Review
Attachment #209901 - Flags: review?(julien.pierre.bugs)
Comment on attachment 209901 [details] [diff] [review]
fix for reporter crl names

>+	    if (cert) {
>+	        asciiname = PORT_Alloc(strlen(cert->nickname) + 1);

what if cert->nickname is NULL? (it can happen), or points to an 
empty string (first character is \0 )?

>+	        sprintf(asciiname, "%s", cert->nickname);
>+	        CERT_DestroyCertificate(cert);
>+	    } else {
>+	        name = &crlNode->crl->crl.name;
>+	        if (!name){
>+	            fprintf(stderr, "%s: fail to get the CRL issuer name (%s)\n", progName,
>+	                    SECU_Strerror(PORT_GetError()));

That fprintf is equivalent to  a call to SECU_PrintError.  
Please use SECU_PrintError instead. 

>+	            break;

This terminates the loop, meaning that any CRLs that follow this one will not
be printed.  I'm pretty sure that in this case, we want to continue the loop
with the next CRL in the list (if any).
Attachment #209901 - Flags: review-
Comment on attachment 209901 [details] [diff] [review]
fix for reporter crl names

SECU_FindCrlIssuer was written for crlgen to find a user cert to sign a CRL . In this case we are only listing and we don't need a user cert. So, you can just use CERT_FindCertByName to look up by subject.

The 3 bugs that Nelson found are all pre-existing, but since you are working on this area of the code, you should fix them.
Attachment #209901 - Flags: review?(julien.pierre.bugs) → review-
Attached patch bug fix (obsolete) — Splinter Review
Fixes problems that Nelson and Julien have found. Also has some modification to 
FindCRL function to be able to display CRLs using email address as well as AVA
Attachment #209901 - Attachment is obsolete: true
Attachment #210190 - Flags: superreview?(nelson)
Attachment #210190 - Flags: review?(julien.pierre.bugs)
Comment on attachment 210190 [details] [diff] [review]
bug fix

- In FindCrl, you can't access the CERT_NameTemplate directly when encoding. This will break the build on windows because global variables don't work in DLLs. You need to use SEC_ASN1_GET(CERT_NameTemplate) .

- The following expression is dangerous and might dereference NULL. Some more pointer checking is needed.
SECItem* subject = &crlNode->crl->crl.derName;

- nit: you can use PORT_Strdup instead of PORT_Alloc and sprintf to duplicate certName to asciiname.
Comment on attachment 210190 [details] [diff] [review]
bug fix

See previous comments.
Attachment #210190 - Flags: review?(julien.pierre.bugs) → review-
Comment on attachment 210190 [details] [diff] [review]
bug fix

I have nothing to add to Julien's review comments for this patch.
Attachment #210190 - Flags: superreview?(nelson)
Attached patch patchSplinter Review
changes according review comments
Attachment #210190 - Attachment is obsolete: true
Attachment #210400 - Flags: review?(julien.pierre.bugs)
Attachment #210400 - Flags: review?(julien.pierre.bugs) → review+
Setting target to 3.12 while we decide if we want this fix in 3.11.1
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → 3.12
Checking in crlutil.c;
/cvsroot/mozilla/security/nss/cmd/crlutil/crlutil.c,v  <--  crlutil.c
new revision: 1.27; previous revision: 1.26

QA Contact: jason.m.reid → tools
Alexei, Is this bug fixed now?
Is there anything left to be checked in?
Any part left unfixed?
Lost the track of it. It is not closed because it is not in 3.11 branch yet. Do we want it in 3.12 only? If yes, then the bug status should be set to "resolved".
Please drive this bug to completion on the 3.11 branch as well.
That means getting a second review.  
Attachment #210400 - Flags: superreview?(nelson)
Attachment #210400 - Flags: review?(neil.williams)
Comment on attachment 210400 [details] [diff] [review]
patch

the patch is integrated into the 3.11 branch.
Attachment #210400 - Flags: superreview?(nelson)
Attachment #210400 - Flags: review?(neil.williams)
3.11 branch: 
crlutil.c
new revision: 1.26.24.1
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: