308651 - Can't build certificate path after CA certificate changeover

Status: RESOLVED WORKSFORME

(NSS :: Build, defect)

Description

[Kirill Bludilin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

If CA make self certificate changeover, in other words issue self certificate
with old keys and new certificate, certificates issued before changeover become
invalid. I think this take place because when build certificate path issuer
certificate find by Issuer DN and not Key Identifier in Authority Key Identifier
extension.

Reproducible: Always

Steps to Reproduce:
1. Create CA.
2. Issue end-user certificate with with Key Identifier in Authority Key
Identifier extension
3. Changeover CA certificate with new DN and old keys.
4. Install new CA certificate in Firefox or Thunderbird.
5. Verify end-user certificate.

Actual Results:  
Cerfificate become invalid hoowaver it is valid.

Expected Results:  
Certificate must be valid.

Comment 1

[Wan-Teh Chang]

Julien, could you take a look at this?  Thanks.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Do the old and new CA certs have the same serial number?

I think the old and new CA certs, and a subordinate cert that demonstrates
the problem should be attached to this bug before it is confirmed.

Comment 3

[Kirill Bludilin]

Attachment: New CA certificate

Comment 4

[Kirill Bludilin]

Attachment: Old CA certificate

Comment 5

[Kirill Bludilin]

Attachment: End user certificate

Comment 6

[Kirill Bludilin]

Of cource old and new certificates have diffirent serial numbers.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Attachment: human readable pretty print of 3 certs

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

I see no NSS bug here.   It all works for me exactly as expected.

To test, I put both of the above CA certs into a new cert DB, trusted 
as email CAs.  Then I tested the ee cert for validity as an email 
signer and as an email recipient.  It passed both tests.

# create new cert db in $bug
certutil -N -d $bug
# add both root CA certs to it
certutil -A -n ca_new -t 'C,C,' -a -i $bug/ca_new.crt -d $bug
certutil -A -n ca_old -t 'C,C,' -a -i $bug/ca_old.crt -d $bug
certutil -L -d $bug
# convert ee cert to binary DER
grep -v .----- $bug/ee.crt | atob -o $bug/ee.der 
# test ee cert for S/MIME signer  (sign/verify)
vfychain -d $bug -u 4 $bug/ee.der
# test ee cert for S/MIME recipient (en/decryption)
vfychain -d $bug -u 5 $bug/ee.der


results are:

ca_new                                                       C,C,
ca_old                                                       C,C,
Chain is good!
Chain is good!

As an aside I don't see how it could ever have worked with thet ee cert
and that "old" CA cert, since the ee cert's issuer name did not match
the old CA certs's subject name.  (and I claim it did not)

But this bug says that the chain doesn't validate when the new root is 
in place, and the above results show that it does.

Comment 9

[Julien Pierre]

Nelson,

My guess is that the reporter had a problem at step 4, during the installation of the new CA certificate . If the new CA certificate was installed, but not trusted, then validation will fail . And indeed, certs that previously validated and chained to the older, trusted CA cert, will no longer validate when the newer, untrusted CA cert is added. This is because the current certificate path building algorithm in NSS always picks the newest certificate. The libpkix project will solve that problem by examining multiple possible certification paths until a valid one is found. This would have the benefit of making the validation continue to work until the time that the old CA cert expires in this case.

Unfortunately, it's easy to "install" cert without trusting them, because NSS will import all certs from an SSL server cert chain as untrusted temporary certificates. Thus, the renewed certs can become poison certs.
However, in general, the SSL cert chains aren't supposed to contain trusted roots, so this problem should be rare.

Comment 10

[Kirill Bludilin]

Nelson, I think your test was not right. Trouble arise when CA make changeover (issue certificate with same key pair and dirrerent subject and/or issuer). In this case when CA issue certificate to new subscriber there is new issuer field in  certificate. But in other user cert DB contain old CA cert only, he not neeed to update CA cert in this case. Now chain will not valid until user update CA cert, that it's not right.
I think it's bug.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Reporter:  In comment 0, you write:
> I think this take place because when build certificate path issuer certificate 
> find by Issuer DN and not Key Identifier in Authority Key Identifier extension.

I think you meant that you believe the cert chain builder should find the 
issuer by it subject key ID, even if the issuer's subject name no longer matches
the issued cert's issuer name.  That simply wrong, and does not match RFC 3280.
Subject Key ID helps the choose among multiple potential issuer certs with the same subject name and the issued cert's issuer name.  It does not allow one to 
overlook (ignore) the subject name in the issuer cert.

But perhaps there is simply a language/translation problem, and you did not 
mean to imply that you expect to find an issuer cert even when its subject
name is the not expected issuer name.  

Now, if you can show me a set of certs that actively demonstrate the problem
you're experiencing, so that the problem is reproducible, I'll take another
look.  In the mean time, I have no evidence of any actual flaw here.