Petar Popara wrote:
What date are you verifying your certificate against ?
Current date and time. CERT_VerifyCertificateNow() (should) use current date
and time and that is what I need.
This is my code sample:
SECStatus s = CERT_VerifyCertificateNow(
CERT_GetDefaultCertDB(),
pCertContext,
PR_TRUE,
certificateUsageAnyCA,
NULL,
&out);
if (s == SECFailure) {
//an error occured
}
Actually, that's the wong test.
You should test for
if (s != SECSuccess)
The reason is because some APIs , including CERT_VerifyCertificate, may
return SECWouldBlock .
If that's not it, then you will need to step through the code in the CRL
cache. Assuming you are using NSS 3.10 (NSS_3_10_RTM) I suggest you start
with DPCache_FetchFromTokens and find out if the CRL is found during the
verification.
I haven't compiled NSS by myself. I'm using Windows precompiled binaries. :(
Doing that would help. Before that, you could list the content of your
database with crlutil -d <dir> -n <YourCA> -L
And also the details of your end-entity and CA certs with
certutil -d <dir> -n <YourCA> -L
certutil -d <dir> -n <YourEE> -L
The primary check involved is that the subject of the CRL should match
the subject of the CA and the issuer field of the EE .
If not, then NSS cannot correlate the certs and the CRL . That would
indicate an invalid CRL most probably.
If you are using your own CA, you might want to try with real public
certs and CRL to convince yourself that it works, ie. Thawte or Verisign
certs .
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
