115719 - PK11_ListCerts returns empty server cert list

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Julien Pierre]

Using a debug build from 12/17/2001 of NSS 3.4 tip on Solaris, the following
piece of code (which I wrote in web server 6) can't find the certificate upon
web server startup.

CERTCertificate* SSLSocketConfiguration :: FindServerCertFromNickname(const
char* name) const
{
    CERTCertList* clist;
    clist = PK11_ListCerts(PK11CertListUser, NULL);

    CERTCertListNode *cln;

    for (cln = CERT_LIST_HEAD(clist); !CERT_LIST_END(cln,clist);
        cln = CERT_LIST_NEXT(cln))
    {
        CERTCertificate* cert = cln->cert;
        const char* nickname = (const char*) cln->appData;
        if (!nickname)
        {
            nickname = cert->nickname;
        };
        if (0==strcmp(name, nickname))
        {
            // we found our cert
            return cert;
        };
    };
    return NULL;
};

If I revert to NSS 3.3.2 binaries, everything works. The server cert is in fact
in the database. I believe that this may be a problem with the way the property
and trust bits are handled in the tip right now.

Comment 1

[Julien Pierre]

FYI this is a regression from last week. The server was able to find its
certificate and come up.

Comment 2

[Wan-Teh Chang]

Ian, could you take a look at this bug?  Thanks.

Comment 3

[Ian McGreer]

Attachment: move trust setting to correct place

Indeed, I bungled this when moving things around for the contexts.

About that code, Julien, is that really the best way to go about it?  I know
servers don't have too many certs, but they do have the builtins, right? 
That's about 75 certs that will be listed by using PK11_ListCerts.  Couldn't
you use CERT_FindUserCertByUsage or even PK11_FindCertByNickname?  Also, the
list isn't being destroyed, so all those certs are being leaked.

Comment 4

[Julien Pierre]

Ian,

There were some bugs with duplicate certs being eliminated and not found by
PK11_FindCertByNickname. See bug 74822 -
http://bugzilla.mozilla.org/show_bug.cgi?id=74822 .
This is why I have to use PK11_ListCerts .
With the call I'm making though - returning user certs (see the first argument
to PK11_ListCerts) - I should only be given a short list of server certs, not
including the builtin certs.

Comment 5

[Ian McGreer]

Unfortunately, I no longer have permission to read netscape confidential bugs,
so i don't know what that bug was about.  I was curious to see if it might be
fixed in 3.4.

You're right about the list being short, but it still means a full traversal. 
This is the kind of thing we should prevent in the brave new world of 4.0 :)

Out of curiosity, is part of the problem that the cert may be on a token?

Comment 6

[Julien Pierre]

No, the problem was that there may be an identical cert/key in several tokens.
The PK11_FindCertByNickname is only able to find one unfortunately because
duplicate certs are eliminated.

Comment 7

[Ian McGreer]

In that case, I think the other bug is one that could easily be fixed in 3.4,
using PK11_FindCertsFromNickname.  I looked at the current state of that code
and it won't do what you require (return multiple instances of the same cert,
one for each token it appears on), but it very well could.  If you think that
would be useful, create a new bug (one that I can see ;)

BTW, have you tried the patch I checked in?

Comment 8

[Julien Pierre]

Ian,

I just tried the patch you checked in. It fixes the problem and allows the
server to come up. However, there is still an issue with PK11_ListCerts. I will
open a separate bug for it.

Comment 9

[Ian McGreer]

Since this bug was fixed and another opened, closing this one.