139196 - Give better error msg when importing p12 file with unknown critical extension

Status: RESOLVED WORKSFORME

(Core Graveyard :: Security: UI, enhancement, P2)

Description

[Matp75]

build id : 2002042106 
downloaded from : http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.0.0/ today
mozilla-win32-talkback.zip decompressed in a fresh directory

action : try to import certificate in PKCS #12 
these certificate were generated by entrust and then exported to PKCS #12 file
expected result : the certificate should import or an explicit error message
should be given
result : the PKCS #12 operation failed for unknown reasons.
reproduceable : always

Comment 1

[Matp75]

Attachment: PKCS #12 certificate : Password is Mozilla1

Comment 2

[Matp75]

Attachment: PKCS #12 signing only certificate . Password is Mozilla1

Comment 3

[Matp75]

Attachment: PKCS #12 decrypt only certificate : Password is Mozilla1

The three attachements are test certificates I tried to import into mozilla
please try to duplicate by importing these into mozilla

Note : this bug might be related to bug #128586 but doesn't seem to be fixed by
it as the patch in it seems to be applied to the build I'm using.

Comment 4

[Stephane Saux]

Kai
Anything special about these certs?
Do they load fine in other browsers (earlier versions of moz for example).

Comment 5

[Stephane Saux]

the certificates in the p12 files have "unknown critical certificate
extensions", This is why they do not load.  
We should say so, but otherwise failing is the right thing to do.

We fail in certdb/certdb.c:
    if (cert_HasUnknownCriticalExten (cert->extensions) == PR_TRUE) {
	PORT_SetError(SEC_ERROR_UNKNOWN_CRITICAL_EXTENSION);
	goto loser;
    }
cc relyea.

Comment 6

[Matp75]

these certificates have these critical extensions :
keyusage : value digital signature or keyencipherment
certificatepolicy : value is oid of the certificate policy
These are standardized extensions and required by our policy

Although it is a good thing to make a better error message, the real solution is
for mozilla to support these extensions.
it seems by looking at certdb.c that keyusage criticity is supported at first look
 
these certificates import fine with outlook and outlook express

Comment 7

[Robert Relyea]

Certificate policy is most likely the extension that is messing you up. NSS
currently does not handle policy. It's a feature we will probably work on in the
near future, but right now we are working toward stabilizing what we have.

On the other hand, there shouldn't be a reason, from the cert's perspective, to
make policy a critical extension. Policy is an application dependent usage,
where applications decide to run or not if a particular policy is in place. Key
usage, on the other hand, is a perfectly legitimate use of critical extensions.
We do parse and understand key usage, so if just key usage is critical and you
can't import, that would definately be a bug in NSS.

bob

Comment 8

[Matp75]

Attachment: PKCS #12 with only key usage as critical : Password is Mozilla1

this certificate doesn't have certificate policy as critic. is still doesn't
import
message is the same : the PKCS #12 operation failed for unknown reasons.

Comment 9

[Matp75]

Attachment: PKCS #12 with nothing critical : Password is Mozilla1

this certificate doesn't anything flagged as critic. is still doesn't import
message is the same : the PKCS #12 operation failed for unknown reasons.

Comment 10

[John Unruh]

Confirming.

Comment 11

[Kai Engert [:KaiE:]]

Now that bug 128586 is fixed, is this bug fixed, too? Or is that another problem?

Comment 12

[Matp75]

I think that's another problem and it is still not fixed

Comment 13

[Robert Relyea]

There were two pkcs #12 import problems:

1) with pkcs #12 from IE where NSS was decoding the key because it had extensions.
2) with pkcs #12 from other vendors because the NSS priveate key verify code was
not correctly verifying the case where prime1 < prime2.

If you built these PKCS #12 files from OpenSSL you are probably running into
problem 2, which recorded by bug 133643 (and included the patch for that issue).

bob

Comment 14

[Frederic Bezies]

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

Comment 15

[Kai Engert [:KaiE:]]

If I understand Bob correctly, issue 1 has been fixed by bug 128586, and issue 2
has been fixed by bug 133643.

Please let us know whether you can still reproduce the problem.

Comment 16

[John Unruh]

The bug is not completely fixed. The attachments (save them as *.p12 files) in 
comments 1-3 do not import. The certs in comments 8 and 9 do.

Comment 17

[Matp75]

with mozilla 1.1rc (20020818), I still can't import the first 3 certificates but
it is because certificate policy is not yet implemented in mozilla. I can
succesfully import the one from comment 8 and 9 which is cool :-)

Comment 18

[Kai Engert [:KaiE:]]

If I understand correctly, we do no longer have a bug with importing certificates.

I'm closing this as worksforme.

Comment 19

[Kai Engert [:KaiE:]]

My previous comment is wrong, I decided to morph this bug into an enhancement
request bug.

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

"operation failed for unknown reasons."   
Yet another reason to believe that bug 107491 remains unresolved.

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

A PSM bug "futured" 4 years ago, with no progress since.

It may be that the PKCS12 library is not returning sufficiencly specific
error codes, but we'll never know as long as PSM lumps so many error codes
together as "for unknown reasons".

Comment 22

[Elio Maldonado]

The imports are all working for me with nspr-4.8.8 / nss-3.12.10
I don't know what changed, could someone else try it?

Comment 23

[Dana Keeler (she/her) [:keeler]]

The presence of unknown critical extensions isn't an issue for CERT_DecodeDERCertificate any longer: https://dxr.mozilla.org/mozilla-central/rev/8c9c4e816e86f903c1d820f3f29715dc070a5a4a/security/nss/lib/certdb/certdb.c#741 (note that this merely sets a flag bug doesn't prevent the certificate from being imported). Also, I ran a quick test with attachment 80379 [details] and it seemed to import just fine.