224663 - PSM in Mozilla 1.6a and trunk fails to verify personal certificate that verifies correctly in < 1.5

Status: RESOLVED INVALID

(NSS :: Libraries, defect, P2)

Description

[Philip Langdale]

I took it upon myself to poke around with S/MIME a few weeks ago. I had a
personal cert from way back (1998) that I got when verisign had an offer with
netscape to issue limited use certs for free.

S/MIME refused to list my cert and I thought it was because the cert hadn't been
issued with the right purpose flags set and thought nothing more of it. However,
I chanced to be working in windows today where I have 1.5 installed (I build
from cvs daily in linux) and noticed that S/MIME was prepared to use my cert. I
checked the cert manager and saw it listed with signing and encryption rights. I
went back to linux and there it says "cannot veryify cert for unknown reasons".
not very helpful. I then downloaded 1.5 and 1.6a and confirmed that in linux my
cert was properly verified in 1.5 and not in 1.6a. I don't know if this is a
browser issue (not using PSM correctly) or a PSM issue.

Nevertheless, this is a serious issue. An otherwise valid client cert is
rendered useless. People actually using S/MIME will find themselves unable to.

I found an unfixed bug regarding the unhelpful verification failure error
messages. heh.

Comment 1

[Philip Langdale]

Ok. I have done further poking around and can confirm that dropping libnss3.so
from mozilla 1.5 in to a 1.6a/trunk installation fixes the problem, strongly
indicating that the issue is a regression in nss. I'm attempting to transfer the bug

Comment 2

[Philip Langdale]

Accordingly transferring bug to NSS contacts.

Comment 3

[Wan-Teh Chang]

Julien, could you take a look at this?  The cvs tags for
the NSS in Mozilla 1.5 and 1.6a are MOZILLA_1_5_RELEASE
and MOZILLA_1_6a_RELEASE.  There aren't that many changes
between those two tags.

Comment 4

[Wan-Teh Chang]

Philip, could you attach your cert to this bug or email
it to us?

Comment 5

[Philip Langdale]

I am happy to do so, but I don't know how to make mozilla export the cert
without including the private key with it. I'm pretty sure, I shouldn't be
sending that! :-)

Comment 6

[Wan-Teh Chang]

Just use Mozilla 1.5 to send a signed email message to us.
The signed message will include your cert.

Comment 7

[Julien Pierre]

Philip,

I have not been able to find anything useful from the e-mail and database you
sent me. I'm not able to reproduce your problem.

Your certificate does not verify under any version of Mozilla because the issuer
certificate is unknown. In addition, your certificate's subject does not match
your e-mail address, so the certificate cannot be expected to work with S/MIME
(but you mentioned in the message that you are aware of that issue). It's
possible that Mozilla 1.6 checks the e-mail address against the cert, and
Mozilla 1.5 did not.

Also, you mention both Windows and Linux browsers, and the cert works in one but
not in the other for S/MIME signing. This could be explained by the fact that
you don't have the private key on one of your machines. I'm somewhat confused by
your bug report and we need to reduce it to the simplest case to reproduce it.

At this point, I need more information from you :

1. please try to reproduce your problem on Windows. That's what I'm using, so it
will make things easier for me to reproduce and fix. If the bug is Linux
specific, we need to know that

2. tell me the nickname of the certificate you are using for signing, in the
cert8.db you sent me

3. tell me the nickname of that certificate's issuer, in the cert8.db you sent
me. I could not find the issuer, and there is no way the certificate will verify
if the chain is incomplete.

4. explain exactly what you mean by "S/MIME does not list the certs" .

5. verify that you are using exactly the same cert8.db and key3.db on both your
Linux and Windows machines. On linux, check permissions

6. verify that you are using exactly the same cert8.db and key3.db on your 1.5
that work and 1.6a builds that fail

7. try to read your signed e-mails without your private key. To do this, you'll
need to backup key3.db, erase it, and restart mozilla. Tell me if the signature
still verifies (other than the e-mail address not matching) and if so in which
build of mozilla.

Comment 8

[Philip Langdale]

Ok. We don't seem to be getting very far here.

I know this is a slightly pathological certificate and because it doesn't
contain an email address would be useless for actual secure communications, but
the fact remains that PKI is supposed to work, so this is still important in
some sense.

The cert was issued by verisign in 1998 (multiple internet lifetimes ago) as
part of a promotion they had; you got a free cert that would identify you to
websites that require client verification (all zero of them) but would not work
for secure email. I was originally under the impression that they made it
useless for email by not setting the 'can sign mail' and 'can encrypt/decrypt
mail' properties and thought nothing of it. Over the years I have managed to
carry along my same old *.db files from 1998 (netscape 4.x?) and I now see with
mozilla 1.5 that this silly cert is considered to have both signing and
encryption rights. and I can indeed sign messages with it. Of course, they never
verify because there is no sign property set, but other than that it seems ok.

I don't think it can ever actually be used for encryption because mozilla does
email lookup to match certs to recipients.

It is also clear to me that the certs in the verification chain are stale. They
are verisign certs as you have observed but not built-in tokens and I guess is
deprecated by verisign, if that's the right word.

I don't know what you are referring to by nickname.

The CN for my cert is "Philip Langdale".

The immediate signing cert has no CN but has the full name:

"Verisign Website Access CA - Verisign, Inc"

The original root cert which expired in 99 but is still sitting in my db is:

"Verisign Class 1 Primary CA"

With Mozilla 1.5, NSS seems to have picked up on the following as a replacement
cert and the chain for my personal cert goes to it:

"Verisign Class 1 Primary Public Certification Authority"

This root cert and my personal cert both verify according to the cert manager
but the intermediate 'web access' cert does not verify for "unknown reasons".

In Mozilla 1.6 (this is all linux), my personal cert does not verify for
"unknown reasons".

I am using exactly the same db files (same profile dir) for both 1.5 and 1.6a
and have checked the same db files with 1.5 on windows with no difference shown
between 1.5 on both platforms.

Quite frankly, I'm wondering if this is actually not a bug at all but a *bug
fix* between 1.5 and 1.6a. If the immediate signing cert cannot be verified "for
unknown reasons", then surely the signed cert can never be verified. So, is this
a bug in 1.5 where the leaf cert is somehow considered verified becase the root
is verified regardless of the status of the intermediate certs?

The behaviour when I delete my private key and then attempt to read a signed
email is the same in both. In 1.5, the message is that the signature is valid
but the cert cannot be tied to the email address (as expected) but in 1.6a, the
message is that the cert cannot be verified. Interestingly, the public cert is
*not* imported into the cert manager as an "other people" cert. It doesn't seem
to import at all. I believe you told me this should happen.

I hope this is of some use.

Comment 9

[Wan-Teh Chang]

Attachment: All the NSS changes between Mozilla 1.5 and Mozilla 1.6a

There are not that many NSS changes between Mozilla 1.5
and Mozilla 1.6a.  Given that the certificate doesn't
contain an email address, I think the relevant change
is the patch for alg1485.c, for bug 211540.

Philip, I will send you Mozilla 1.6a NSS shared libraries
for Linux, minus the alg1485.c change, to verify that
that is indeed the change that caused your certificate
to not verify in Mozilla 1.6a.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Julien, please attach to this bug (or put in a comment) the output of 
the pp program (or certutil) from the trunk for the relevant cert(s).

The submittor of this bug admits that the cert was intentionally 
created to NOT WORK with SMIME.  Perhaps it has worked in the past,
due to inadequate validity checking in NSS, but that does not necessarily
mean that it *should* work, or that we are obligated to make it work.  

As the submittor wrote, "PKI is supposed to work".  A large part of what
it means to work is to identify invalid and incorrect components of the
security system, and not honor them as if they were valid and correct.

So, let's determine whether this cert/chain is valid PKIX before we
decide (a) that this is a regression (perhaps it is an improvement),
or (b) that we need to fix it.

Comment 11

[Philip Langdale]

Wan-Teh,

I have tried the two libnss3.so files you sent me and it is indeed as you say.
The version without the change to alg1485.c verifies my cert and the version
with the change does not verify my cert.

The only question that remains right now is which is the correct behaviour.

Comment 12

[Julien Pierre]

Nelson,

There is no chain as far as I can tell, only an end certificate. NSS isn't able
to find the issuer on the certificate. Under these circumstances, I don't
understand how any version would validate it.

Here is the pp output for the Verisign cert in question :

C:\nss\39\mozilla\dist\WIN954.0_DBG.OBJ\bin>certutil -d . -L -n "Philip Langdale
's VeriSign Inc. ID"
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            34:75:62:c8:86:66:6e:1a:0d:23:67:59:ab:4d:83:c9
        Signature Algorithm: PKCS #1 MD5 With RSA Encryption
        Issuer:
            "OU=www.verisign.com/RPA Incorp. By Ref. LIAB. LTD. (c) 97 VeriSi
            gn,OU=VeriSign Web Site Access CA,O=VeriSign Inc."
        Validity:
            Not Before: Sat Jun 27 00:00:00 1998
            Not After : Tue Jun 24 23:59:59 2008
        Subject:
            "OID.1.2.840.113549.1.9.2=#13214145317747466859424279454144683154
            573149514731565856556F5641413D3D,CN=Philip Langdale,OU=WebPass ID
             - Netscape Netcenter,OU="www.verisign.com/repository/CPS Incorp.
             by Ref.,LIAB.LTD(c)96",OU=www.verisign.com/RPA Incorp. By Ref. L
            IAB. LTD. (c) 97 VeriSign,OU=VeriSign Web Site Access CA,O=VeriSi
            gn Inc."
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    d6:fe:ec:bb:b6:1a:bc:f3:a7:11:85:ec:19:c1:cf:e4:
                    3e:25:22:8b:b8:8c:9c:0e:89:48:6f:8f:9e:f4:73:36:
                    b3:e4:ed:e7:d1:28:63:b9:4c:e7:1e:13:9c:51:69:1a:
                    59:6d:6b:70:02:d1:ad:31:34:f4:85:da:e3:cf:bc:3b
                Exponent: 65537 (0x10001)
        Signed Extensions:
            Name: Certificate Basic Constraints
            Data: Is not a CA.

            Name: Certificate Policies
            Data:
                Invalid Policy Data:
                    30:80:30:80:06:0b:60:86:48:01:86:f8:45:01:07:01:
                    01:30:80:30:28:06:08:2b:06:01:05:05:07:02:01:16:
                    1c:68:74:74:70:73:3a:2f:2f:77:77:77:2e:76:65:72:
                    69:73:69:67:6e:2e:63:6f:6d:2f:43:50:53:30:62:06:
                    08:2b:06:01:05:05:07:02:02:30:56:30:15:16:0e:56:
                    65:72:69:53:69:67:6e:2c:20:49:6e:63:2e:30:03:02:
                    01:01:1a:3d:56:65:72:69:53:69:67:6e:27:73:20:43:
                    50:53:20:69:6e:63:6f:72:70:2e:20:62:79:20:72:65:
                    66:65:72:65:6e:63:65:20:6c:69:61:62:2e:20:6c:74:
                    64:2e:20:28:63:29:39:37:20:56:65:72:69:53:69:67:
                    6e:00:00:00:00:00:00

            Name: Certificate Type
            Data: <SSL Client>

            Name: OID.2.16.840.1.113733.1.6.3
            Data:
                "d4652bd63f2047029298763c9d2f275069c7359bed1b059da75bc4bc9701
                747da5d5e6141beadb2bd2e89206bd7be1d502409ca1ab42fde3977435"

            Name: OID.2.16.840.1.113733.1.6.6
            Data:
                "1107618:CHNv1"

    Signature Algorithm: PKCS #1 MD5 With RSA Encryption
    Signature:
        b0:e4:00:18:20:c6:11:cf:e9:3a:26:94:99:1e:3e:28:
        87:64:53:fe:97:33:b8:42:12:4d:cd:dd:8c:62:fc:70:
        9f:56:f9:44:2e:49:09:68:77:86:d4:bd:6e:21:44:79:
        2a:fd:f4:bb:b5:89:c6:3e:9e:77:68:14:c9:a8:5d:2a:
        71:09:38:4b:09:b6:1d:5f:8d:1d:67:bc:aa:7c:16:50:
        80:1b:76:ec:78:e0:ee:81:a8:df:5f:20:4b:bf:fb:f9:
        49:1a:7f:2c:24:64:18:a6:17:66:57:9c:ec:85:a4:09:
        4e:2b:59:6d:b2:ad:64:c5:9a:62:dc:38:41:b5:62:4a
    Fingerprint (MD5):
        ED:5C:3D:1D:6F:24:4C:61:78:26:AC:E6:D9:B0:04:EC
    Fingerprint (SHA1):
        B1:3C:6D:E2:FE:5B:15:A3:F5:E3:33:D2:29:B1:5F:51:E7:CD:41:F3

    Certificate Trust Flags:
        SSL Flags:
        Email Flags:
        Object Signing Flags:

Comment 13

[Philip Langdale]

Well, as I understand it the claimed issuer is "VeriSign Web Site Access CA" and
as I described above, this cert is in my db, which I sent to you when you asked.
I agree that if I didn't have this cert, there'd be no way my client cert could
ever verify.

Comment 14

[Julien Pierre]

Philip,

Never mind, I was verifying another one of your certificates earlier, for which
the issuer was missing. For the verisign one, there is a chain, and I get a
failure that the issuer CA is invalid with the current NSS. Will check again
with older version.

Comment 15

[Julien Pierre]

I created a test to verify the cert that fails under the tip and the current
code in the 3.8 branch, but passes under NSS 3.8.1.

With 3.9 :

C:\nss\39\mozilla\dist\WIN954.0_DBG.OBJ\bin>certutil.exe -d . -V -n "Philip Lang
dale's VeriSign Inc. ID" -u S
certutil.exe: certificate is invalid: Certificate type not approved for applicat
ion.

With 3.8.1 :

C:\nss\38\mozilla\dist\WIN954.0_DBG.OBJ\bin>certutil -d . -V -n "Philip Langdale
's VeriSign Inc. ID" -u S
certutil: certificate is valid

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

I'd look at this bug, but the certs are not attached to it. :(

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

Julien,  please export the above cert to an ASCII file using this command:

certutil -d . -L -n "Philip Langdale's VeriSign Inc. ID" -a

and attach it to this bug.  Thanks.

Comment 18

[Julien Pierre]

Philip,

I no longer have this certificate. It was in my e-mail at aol, but I left the
company and no longer have a copy of it. You will need to resend it.

Comment 19

[Julien Pierre]

Philip,

Is this still a problem in Mozilla 1.7b ? Please respond. Without a test case,
we can't fix this bug and it might have to be closed.

Comment 20

[Philip Langdale]

Attachment: The cert in question

Here is my cert as generated by the instructions given.

I hope it helps.

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

I ran dumpasn1 on this cert.  It tells me that this cert is not DER encoded.
It tells me that this cert has numerous indefinite-length encoded sequences.
Here is some of the dumpasn1 output:

 660 30  175:   SEQUENCE {
 663 06    3:     OBJECT IDENTIFIER certificatePolicies (2 5 29 32)
            :       (X.509 id-ce (2 5 29))
 668 04  167:     OCTET STRING, encapsulates {
 671 30 NDEF:         SEQUENCE {
 673 30 NDEF:           SEQUENCE {
 675 06   11:             OBJECT IDENTIFIER
            :               Verisign certificatePolicy 
                               (2 16 840 1 1137331 7 1 1) (Verisign)
 688 30 NDEF:                   SEQUENCE {
 690 30   40:                     SEQUENCE {


So, this cert is invalid, plain and simple.  If, as you suggest, past 
versions of mozilla did not detect this, then those versions were buggy.  

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

A few more comments.

1. NSS believes that certs are supposed to be entirely DER encoded.
Recently, someone challenged that, pointing out that only the "TBSCertificate"
is required by RFC 3280 to be DER encoded.  However, the extensions are
part of the TBSCertitficate, so the DER-encoding requirement applies to them.

2. NSS now has 2 decoders, one for DER-only that is very fast, and one that
does both BER and DER is that is slower and uses a lot more memory.  About
NSS 1.6 (IIRC) NSS was changed to parse certs with the DER-only decoder.
That explains why this cert stopped working in about that release, I believe.


3. Given that the BER-encoded indefinite length sequences are encapsulated
within an OCTET-STRING, which IS DER-encoded, it is CONCEIVABLE to me that 
there is some provision somewhere in one of the relevant ITU standards that
allows the encapsulated contents to be BER-encoded.  I've never seen that
before, but it's conceivable.  So, I will look around and make some 
equiries.  Jullien, you might want to ask your contacts at Sun about this.
Stay tuned.

Comment 23

[Julien Pierre]

Nelson,

Indeed, CERT_DecodeCertificatePoliciesExtension fails in SEC_QuickDERDecodeItem .
However, the change to use QuickDER for this extension was made way back in
augst 2002 for NSS 3.6 . This was integrated in Mozilla 1.2 beta . So, I don't
think this is causing the problem you are seeing.

Comment 24

[Julien Pierre]

Let me clarify. I agree the extension fails to decode because it's not DEr.
However, the fact that the extension doesn't decode doesn't seem to prevent the
cert from being imported and listed in certutil .
CERT_DecodeCertificatePoliciesExtension doesn't seem to be called anywhere in
NSS except from CERT_GetCertCommentString . I don't really see how this
extension could affect S/MIME as I don't believe we use it.

Comment 25

[Wan-Teh Chang]

See comment 9 and comment 11 for a previous attempt
at narrowing down the NSS checkin that caused the
certificate verification change that's the subject
of this bug.

Comment 26

[Robert Relyea]

Nelson, is the subjectAltName also BER encoded?

bob

Comment 27

[Nelson Bolyard (seldom reads bugmail)]

Re: comment 26, Um, this cert has no subject alt name.  See the dump above.

Re: comment 25, this cert is NOT valid for SMIME (regardless of DER/BER).  
    So, I don't see any NSS bug here.  If we had lots of spare time, we could
    go back and try to figure out when and why NSS stopped treating it as 
    valid for SMIME.  But since the current answer is correct, do we care?

Re: comment 24, the complaint about this bug is not that it cannot be imported
    but rather is that PSM does not show it as valid for SMIME.  
    Does the QuickDERDecoder decode indefinite length encoding for 
    SEC_ASN1_ANY ?

Comment 28

[Julien Pierre]

Nelson,

The quickder decoder never decodes indefinite length encoding. When you use
SEC_ASN1_ANY within a template, it tells the decoder to ignore the component
type at that offset - and essentially store the data undecoded, and skip over
the component length. If that component is indefinite-length encoded, then
QuickDER cannot skip over, so decoding will fail.

However, the component at the matching template offset could have
definite-length encodig, but contain subcomponents that have indefinite-length.
That would not be very useful, but I think that's actually what's happening
here. The extension has definite-length, but subcomponents are BER.

I have verified that there is only one call to QuickDER that returns SECFailure
when decoding this cert with certutil -L , for the policy extension . When using
the main template certificate to decode the cert (without digging inside of the
extension components), the QuickDER decoder succeeds.

Comment 29

[Alex Deacon]

Yes, the encoding of the certificatePolicies extension in this certificate is 
wrong.  If I remember correctly (1998 was a long time ago!) this bug was 
discovered and fixed.  Unfortunately some certs made it into the wild. 

Alex