Closed Bug 200630 Opened 19 years ago Closed 8 years ago

PSM only imports binary DER CRLs, not base-64 encoded (PEM)

Categories

(Core Graveyard :: Security: UI, defect)

1.0 Branch
x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: miguel.soares, Unassigned)

References

()

Details

(Whiteboard: [kerh-coz])

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
Assignee: mstoltz → ssaux
Status: UNCONFIRMED → NEW
Component: Security: CAPS → Client Library
Ever confirmed: true
Product: Browser → PSM
QA Contact: carosendahl → bmartin
Version: Trunk → unspecified
Version: unspecified → 2.4
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.
Summary: Error importing a CRL version v2 → PSM only imports binary DER CRLs, not base-64 encoded (PEM)
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
Product: PSM → Core
*** Bug 302297 has been marked as a duplicate of this bug. ***
Whiteboard: [kerh-coz]
QA Contact: bmartin → ui
Version: psm2.4 → 1.0 Branch
The CRL Manager / Revocation Lists feature was removed.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.