User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 Mozilla can not open a version v2 CRL. On http://www.multicert.com/ca/multicert-ca-01.crl there is a PEM encoded v2 CRL. This CRL can have the following 2 lines at the beginning and end, still encoded in PEM: -----BEGIN X509 CRL----- (at the beginning) -----END X509 CRL----- (at the end) This CRL can be also encoded in DER encoded format. Mozilla always gives the same error code: "The browser cannot import the CRL. Error importing CRL to local database. Error code: ffffe009 Please ask your system administrator for response" Internet Explorer can open this CRL in any of the different formats above. Reproducible: Always Steps to Reproduce: 1. Open the CRL file on http://www.multicert.com/ca/multicert-ca-01.crl 2. 3. Actual Results: Error window: "The browser cannot import the CRL. Error importing CRL to local database. Error code: ffffe009 Please ask your system administrator for response" Expected Results: Open and install the CRL

confirmed. 2003040108, WinXP

certificate=crypto;crypto!=Security -> PSM

Julien, Wan-Teh, are we supposed to be able to import CRLs version 2?

I can reproduce the problem. If I am calculating correctly, the error code is SEC_ERROR_BAD_DER. Miguel, your CRL looks broken to me. Your data looks like >>--------[ snip ]-------------------- MIISoDCCEYgCAQEwDQYJKoZIhvcNAQEFBQAwPjELMAkGA1UEB hMCcHQxFTATBgNVBAoTDE1VTFRJQ0VSVC1DQTEYMBYGA1UEAxMPTVVMVElDRVJULUNBIDAxFw0wM zA0MDIxNTUzMzhaFw0wMzA0MDkxNjUzMzhaMIIQ4jAjAgQ7AoqlFw0wMTA2MTIxNTI1NTlaMAwwC gYDVR0VBAMKAQUwIwIEOwKKphcNMDEwNjEyMTUyNjAwWjAMMAoGA1UdFQQDCgEFMCMCBDsCiq0XD ... QhG6cg= <<-------[ snip ]-------------------- I fixed the missing start and begin lines and removed the leading spaces and produced a file that looks like this: >>-------[ snip ]-------------------- -----BEGIN X509 CRL----- MIISoDCCEYgCAQEwDQYJKoZIhvcNAQEFBQAwPjELMAkGA1UEB hMCcHQxFTATBgNVBAoTDE1VTFRJQ0VSVC1DQTEYMBYGA1UEAxMPTVVMVElDRVJULUNBIDAxFw0wM zA0MDIxNTUzMzhaFw0wMzA0MDkxNjUzMzhaMIIQ4jAjAgQ7AoqlFw0wMTA2MTIxNTI1NTlaMAwwC gYDVR0VBAMKAQUwIwIEOwKKphcNMDEwNjEyMTUyNjAwWjAMMAoGA1UdFQQDCgEFMCMCBDsCiq0XD ... QhG6cg= <<-------[ snip ]-------------------- But still, this looks invalid. Your first data line is shorter than all the other lines. I have never before seen a file encoded like this! As an additional test I gave this file to openssl. It also dislikes the CRl and complains with the following error message: unable to load CRL 3514:error:0D0A3007:asn1 encoding routines:d2i_X509_CRL:expecting an asn1 sequence:x_crl.c:229:address=135570800 offset=0 I suggest this bug is INVALID, since the CRL you have produced looks broken.

We do not support some v2 CRL extensions, but we can import v2 CRLs that don't have those extensions.

It is true that the CRL does not contain the first and the last line, but IE understands the CRL with or without them. The CRL is PEM encoded therefore, to see the contents of the CRL file using openssl, after adding the first and last line, the syntax is: openssl crl -in multicert-ca-01.crl -inform PEM -text Using this command the error SEC_ERROR_BAD_DER does not happens, and you can see clearly it's contents, hence, it is not broken, and consequentely the bug is VALID. Which v2 CRL extensions are not supported?

Kai, I was able to hand decode & install the CRL into my NSS DB. I downloaded it using "wget http://www.multicert.com/ca/multicert-ca-01.crl", then converting it using atob, and finally imported it using crutil. The CRL is valid and does not contain any critical extensions. The problem is with PSM, not NSS. I believe that the browser expects binary CRLs, not ASCII. This may be tied to the extension .crl or a MIME type. I'm not sure, as I didn't implement PSM. If you convert the CRL to binary, you will find that it imports fine in the Mozilla browser/PSM. I'm not sure if or how PSM handles base64 encoded CRLs. As far as the critical extensions does not support, they include things like delta CRL extension and issuing distribution point CRL.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 under Mac OS X 10.2.6 (6L60). CRL from apache 2.0 under linux RH 8.0. Was able to import V2 CRL from https://crl01.aset.psu.edu/pkieval-1.0.crl once I changed it from pem to der as suggested in a previous entry. Next update I forgot to convert but pem updated ok. Next update after that I got back to der but got the original ffffe009. Deleted crl from client and started over with der. All seems ok again. My impression is that once you import der to get around this bug you can go back to pem with the next update but then you have to stay with pem for future updates.

Larry, Just FYI, NSS internally only supports DER for CRLs, not PEM. It would be the responsibility of PSM to perform any required conversion. It's possible that the conversion is only happening on updates (I'm not the maintainer of PSM and there is no official one at this time).

That (#9) is consistent with my experience with one added detail. Once PSM has converted an update from pem to der you can't go back to der on a future update. Just offering a datapoint. The obvious work around is to start with der and stay that way.

Updating description.

Mass reassign ssaux bugs to nobody

*** Bug 302297 has been marked as a duplicate of this bug. ***

The CRL Manager / Revocation Lists feature was removed.