User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 In the page at http://onsitecrl-str.s-trust.de/DeutscherSparkassenVerlagGmbHDebitCard/LatestCRL.crl Firefox reports error code ffffe095 while trying to import a V2 indirect CRL. Reproducible: Always Steps to Reproduce: 1.User browser to open http://onsitecrl-str.s-trust.de/DeutscherSparkassenVerlagGmbHDebitCard/LatestCRL.crl 2. 3. Actual Results: Error code ffffe095. Expected Results: Import the CRL with the success message "The Certificate Revocation List (CRL) was successfully imported. CRL Issued by....

->PSM

NSS does not like the CRL.

NSS doesn't support indirect CRL yet. When the new libpkix library is completed, we will have much better RFC 3280 support.

Error code ffffe095 is actually error code -8043. http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html says that error -8043 means "Issuer's V2 Certificate Revocation List has an unknown critical extension."

This bug was originally filed against PSM, and I am giving it back to PSM, since no NSS error is indicated (NSS is working as intended, presently) The complaint in this bug is that the user got an error dialog whose only content was a HEXADECIMAL NUMBER, not a readable error string, not even a decimal number (which he could have looked up in the error number page), but a HEX number. ffffe095 This is just inexcusable. How many more years will this go on?

...and this is still happening in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0

Is it? Does it still report error ffffe095? What is the text of the error page or dialog now?

Yes, here it goes: The application cannot import the Certificate Revocation List (CRL). Error Importing CRL to local Database. Error Code:ffffe095 Please ask your system administrator for assistance.

The CRL's IDP extension is marked critical. (Doctor, it hurts when I do this!) This is an enhancement request (RFE), asking NSS to support IDP extensions. This may be a duplicate of another RFE.

This CRL is rather large. One of the reasons is that every entry includes an entry extension that includes a copy of the cert's issuer name. There are several distinct issuer names, which seem to differ only in the CN string, which appears to contain a text encoding of the year of operation of that issuer. e.g. "S-TRUST Qualified Signature CA 2007-001:PN" "S-TRUST Qualified Signature CA 2006-001:PN" "S-TRUST Qualified Signature CA 2005-001:PN"

Updating subject to match Nelson's findings

IDP extensions are always supposed to be marked critical. Note that while we are planning on adding support for CRLs with IDP in the path validation algorithm, as far as I know, currently there is no plan to add support for those CRLs to the softoken. The softoken is still limited to a single CRL. Thus, IDPs CRLs will only work in conjunction with the automatic fetch with CRL DP extension from certs, or when being fed directly to the CRL cache by the application with CERT_CacheCRL (RAM CRL case). In order to support CRLs with IDP in the database, bug 217392 needs to be fixed first - which is about softoken allowing the storage of more than one CRL per issuer.