SSL certificate chaining with imported CA broken after 1.2a

RESOLVED FIXED in 3.6.1

Status

NSS
Libraries
P1
normal
RESOLVED FIXED
15 years ago
13 years ago

People

(Reporter: Andreas Lange, Assigned: Ian McGreer)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
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

15 years ago
Ian, could you take a look at this bug?  Thanks.
Assignee: wtc → ian.mcgreer
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

15 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
(Assignee)

Comment 3

15 years ago
Created attachment 103188 [details]
for posterity, a .tgz of the chain certs
(Assignee)

Comment 4

15 years ago
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.
Status: RESOLVED → REOPENED
OS: Linux → All
Priority: -- → P1
Resolution: INVALID → ---
Target Milestone: --- → 3.6.1
Version: unspecified → 3.6
(Assignee)

Comment 5

15 years ago
Created attachment 103232 [details] [diff] [review]
compare authCertIssuer with issuer->derIssuer


have tested patch with chain.

Comment 6

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

r=wtc.

Bob, Nelson, Terry, could you also review this patch?
Attachment #103232 - Flags: review+
r=nelsonb

Comment 8

15 years ago
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.
(Reporter)

Comment 9

15 years ago
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?
(Assignee)

Comment 10

15 years ago
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

15 years ago
Marked the bug fixed.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 12

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

Updated

15 years ago
Blocks: 173939
*** Bug 173939 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Blocks: 176574

Updated

15 years ago
No longer blocks: 176574

Comment 14

15 years ago
*** Bug 173939 has been marked as a duplicate of this bug. ***
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

15 years ago
I just moved the NSS_CLIENT_TAG.

Comment 17

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

r=relyea both correct and low risk.

Comment 18

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

Comment 19

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

Updated

15 years ago
Blocks: 175858
You need to log in before you can comment on or make changes to this bug.