174634 - SSL certificate chaining with imported CA broken after 1.2a

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Andreas Lange]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021015
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021015

The URL uses a certificate chain: CA -> SSL signing -> certificate. This chain
is recognized in previous versions of Mozilla, but in the current trunk the
certificate wont be recognized as valid even though the CA is imported.

The URL is using a SSL certificate certified with "UNIT Best-Effort CA 2nd SSL
signing certificate", which in turn is based on "UNIT Best-Effort CA Root
Certificate". The latter is documented and can be found at
http://www.ida.liu.se/ca/.

Reproducible: Always

Steps to Reproduce:
1. Import CA cert from http://www.ida.liu.se/ca/beca-root-pem.crt
2. Try https://www.ida.liu.se/


Actual Results:  
"Unable to verify the identity of www.ida.liu.se as a trusted site"

Expected Results:  
Opened the page in secure mode.

With CA imported in profile, tested with:
release 1.0 - OK
trunk 20020730 - OK
release 1.2a - OK
trunk 20021001 - Fails
trunk 20021015 - Fails

Comment 1

[Wan-Teh Chang]

Ian, could you take a look at this bug?  Thanks.

Comment 2

[Ian McGreer]

This is a result of the bugfix for path construction.  The chain is malformed,
and NSS is behaving correctly now (it wasn't before).

There are three certs in the chain.  The leaf cert, www.ida.liu.se, has an
authority key identifier extension.  This extension has both the keyIdentifier
and issuer/serial fields set.

The (intended) next cert in the chain is "UNIT Best-Effort CA 2nd SSL Signing
Certificate".  Interestingly, the subjectKeyIdentifier extension of this cert
matches the keyIdentifier field of www.ida.liu.se.  The serial numbers match as
well.  However, the issuers do not.  Here is the CN from www.ida.liu.se's
authority key identifier extension:

   C-Set  (45)
      C-Sequence  (43)
         Object Identifier  (3)
            2 5 4 3 (X520 Common Name)
         Printable String  (36)
            "UNIT Best-Effort CA Root Certificate"

This obviously points to the root CA, not the intermediate.  Here is the CN from
the intermediate:

   C-Set  (56)
      C-Sequence  (54)
         Object Identifier  (3)
            2 5 4 3 (X520 Common Name)
         Printable String  (47)
            "UNIT Best-Effort CA 2nd SSL Signing Certificate"

Note the mismatch.  It is clear that whoever constructed the cert chain put the
wrong issuer field into the authority key identifier extension of the server cert.

Marking invalid.

Comment 3

[Ian McGreer]

Attachment: for posterity, a .tgz of the chain certs

Comment 4

[Ian McGreer]

Nelson pointed out the error in comment #2 that is the source of this bug.  The
path construction patch is incorrectly comparing the authCertIssuer field to the
issuer's subject, as opposed to the issuer's issuer.  This bug needs to be fixed.

Comment 5

[Ian McGreer]

Attachment: compare authCertIssuer with issuer->derIssuer

have tested patch with chain.

Comment 6

[Wan-Teh Chang]

Comment on attachment 103232 [details] [diff] [review]
compare authCertIssuer with issuer->derIssuer

r=wtc.

Bob, Nelson, Terry, could you also review this patch?

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

r=nelsonb

Comment 8

[hico2]

If I read Comment #2 correctly, it says the certificates are wrong, doesn't it?
I don't think it's the case, as I've got problem with similar chained setup, and
certificates are AFAIK ok.

To demonstrate: Import root CA from http://kca.uniba.sk, then go to
https://mail.fphil.uniba.sk. It doesn't validate the page, says "Unable to
verify the identity of .." and only the leaf certificate is present in detailed
view.

The intermediate certificate in the chain is supplied by the server, together
with the mail.fphil.uniba.sk certificate. Worked ok with 1.0 and 1.2a, doesn't
work with 1.2b and 2002102108. Works with IE.

Comment 9

[Andreas Lange]

Read comment 4 again, and why not test the patch?

We have tried the patch in our deparment's testing of 1.2b, and it works fine.

Is there any chance this will get sr and a before 1.2 final?

Comment 10

[Ian McGreer]

patch has been checked in to tip and NSS_3_6_BRANCH.  Wan-Teh, I'll leave the
client tag up to you.

Comment 11

[Wan-Teh Chang]

Marked the bug fixed.

Comment 12

[Thomas Schoepf]

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

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 14

[Kai Engert (:KaiE:)]

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

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

a=dbaron for pushing the NSS_CLIENT_TAG (used by the Mozilla trunk) during the
closure for 1.2final to pick up this fix (along with bug 158683, bug 164744, bug
172678 and bug 172732).

Comment 16

[Wan-Teh Chang]

I just moved the NSS_CLIENT_TAG.

Comment 17

[Robert Relyea]

Comment on attachment 103232 [details] [diff] [review]
compare authCertIssuer with issuer->derIssuer

r=relyea both correct and low risk.

Comment 18

[John Unruh]

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

Comment 19

[Jan Noppen]

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