David,
First, welcome to working with NSS!
Your message covers a lot of subjects, and I'm not sure which one is
the central point. I'll answer some.
> I then wanted to just list out all the certs in the DB and attempted to
> get the default certdb (which I assumed is automatically set to the one
> in the config directory specified in the call to NSS_Init) like so:
>
> CERTCertDBHandle *certdb = CERT_GetDefaultCertDB();
>
> doing PR_GetError() shows no error (do PR errors apply to NSS as well as
> NSPR?) so then I try to print out the certificate DB version and the #
> of certs in it and I get 0 returned for both:
>
> printf("Certificate db version: %i\n",
> CERT_GetDBContentVersion(certdb));
> CERTCertDBHandle *certdb = CERT_GetDefaultCertDB();
> printf("Certificate db version: %i\n",
> CERT_GetDBContentVersion(certdb));
CERT_GetDBContentVersion is a deprecated function. It always returns zero.
Prior to NSS 3.4, the "cert DB" was directly acessible via NSS APIs.
Beginning in NSS 3.4, the cert DB now exists only inside of a PKCS#11
crypto module, and can only be accessed through the PKCS11 API.
Some of the old CERT_* functions that took a CERTCertDBHandle argument
were reimplemented to work by calling PKCS11 fuctions, and the value
of the CERTCertDBHandle itself was redefined to be an object that
includes information about the PKCS11 module.
The program certutil (which you've used) can enumerate the certs in a
PKCS#11 module (including PKCS#11 modules that use cert DBs).
If you want to see how to do that, I suggest you look at the source
code to certutil. There's a lot more there than you need, but I think
that when you get to the point where you can follow the certutil code
and see what it's doing and understand why, you'll be well on your way.
> This is when I stared adding the PR_GetError() calls after every NSS
> method call and I found that although rv==SECSuccess after the call to
> NSS_Init, PR_GetError() is showing the error -12285.
The NSS API is defined such that if a function return SECSuccess, then
the thread's error code (the value returned by PR_GetError) is meaningless.
In general, one should NOT attempt to interpret that error code unless
a function returns a failure indication (e.g. SECFailure, or NULL).
> Pulling the cert out and then printing the subjectName works fine, but
> the rest of the stuff with the certDB doesn't.
That's too vague to be able to help with it. What "rest of the stuff"?
If you're trying to print cert contents, I suggest you follow certutil's
example.
> I looked up error -12285 on the NSS and SSL Error page:
> http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html
It's good that you looked there, very resourceful of you.
But since this error code was found after a function returned SECSuccess,
it's not really worth persuing IMO.
> I went back and added the same line of code to print out the error after
> the initialize call in sample6 and it also spits out the same error as
> my code.
Yeah, looking at error codes after functions succeed is going to lead you
down lots of blind alleys, and be needlessly confusing.
> Any help would be appreciated. If I'm trying to enumerate the
> certificates in the DB incorrectly then I may have been sent on the wild
> goose chase for this error for nothing and it may be ignorable.
My advice, follow certutil's example.
> Another question is about the nspr log. What exactly is the highest
> level of debugging? I've seen 6 used but the page talking about nspr
> logging says just use "all:5".
Maybe Mr. NSPR can answer then when he returns from leave in a few weeks.
> Thanks,
> Dave
--
Nelson B
_______________________________________________
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
