203235 - New S/MIME certs not being seen until old ones are deleted.

Status: RESOLVED DUPLICATE of bug 209168

(MailNews Core :: Security: S/MIME, defect, P2)

Description

[bill]

scenario:
- Steve sends Bill a signed+encrypted mail using Steve's signing cert number "001".
- Bill can read the email.
- Bill's browser stores Steve's email encryption cert for later use.
- Steve then deletes his old certs.
- Steve then gets a newer cert pair, the signing cert is now number "003".
- Steve sends Bill a new signed and encrypted email and asks for an encrypted reply.
- Bill replies to the message, signs it, and marks it for encryption.
- Steve is unable to read the message because he "doesn't have the correct
certificate".
- Bill goes into his browser cert cache and looks up his certs for Steve.  The
only cert that Bill has is cert number "001".
- Bill deletes certificate #001
- Bill sends another encrypted reply to Steve.
- Steve is able to read the email.

It looks as if the cert store in the brower is not getting updated when people
send signed messages and they have updated their certificate since the recipient
has received a signed email from them before.

This is build Mozilla 1.4, build 2003042408 on mac OS X.

Comment 1

[Stephane Saux]

This should work.
However from the description, you seem to have both certs (you have 001, then
deleting 001, you're able to send the mail - which presuposes that you have 003).

Two things could be going on: insertion of the 003 in the cert db fails when 001
is around I don't know why that would be the case.
somehow, the normal algorithm of using the "most recently issued" cert fails.

kai.

Comment 2

[bill]

clarification:  I have LDAP dbase lookup enabled so that's how I was able to get
Steve's newest cert.

Comment 3

[Kai Engert (:KaiE:)]

Sorry for not having looked at this bug earlier.
This bug sounds like a severe regression to me.
CC'ing Wan-Teh FYI.

But let me try to reproduce the bug first.

If the bug is really in cert importing, I should be able to reproduce without
having to use LDAP, but by sending over signed emails.

Comment 4

[Wan-Teh Chang]

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

Comment 5

[Robert Relyea]

I'm going the change the title, since to an NSS developer it implies that the
problem is in the NSS cert cache, which doesn't seem to be the case (though the
cert cache may be involved in the problem).

Since the two certs have different serial numbers, they both should have
separate cache entries. Since deleting the 'bad' one causes things to work, it's
not a cache consistancy issue. It could be that the cert selection code is
caching the subject record, and it's not getting updated on import of a new
certificate. (This seems the most likely cause).

I'll take a look.

bob

Comment 6

[Kai Engert (:KaiE:)]

Unfortunately I'm unable to reproduce this bug.

It is difficult for me to do the old cert testing with LDAP, so I did everything
without LDAP.

However, LDAP in Mozilla is only supposed to import missing certs or updating
certs. If you have already received the newest cert by reading an email message,
you should be fine already, and any LDAP actions should not influence that - but
in the end we might be required to test it.

I also sent "signed only" messages when sending from the deleting/updating side,
I didn't expect that encryption in addition should influence that, but maybe
that should get tested, too.

I tested with two certs issued by Thawte that have the same subject.

On the side that does the deleting, after having deleted the cert I no longer
can read the formerly received encrypted email message. But the new encrypted
message sent from the "Bill side" was readable with the profile where I deleted
the older certs.

Maybe this bug is only seen if everything is in the same CA?

I used Version 1.3 for the side that deleted the old cert, and Mozilla 1.4
branch for the part that tried to reproduce the "cert does not arrive in
database" bug.

Looks like this bug might be tricky to reproduce.


Any ideas, suggestions for reproducing?

I don't like the idea to get a new corporate cert for each testing cycle :-(

Comment 7

[Samir Gehani]

adt: nsbeta1-

Please renominate and email adt if we have a reproducible testcase and can show
how rampant this will be for our user base.  Thanks.

Comment 8

[Kai Engert (:KaiE:)]

Is it possibly the effect you saw is related to bug 209168 or bug 209166 ?

Comment 9

[Robert Relyea]

Bug 209168 is a possibility because LDAP is involved. Deleting the cert causes it to be 
refetched via LDAP.

Comment 10

[Kai Engert (:KaiE:)]

Marking as a duplicate of bug 209168.

Shadow, if you have reasons to believe it is not a duplicate, please reopen the
bug. Thanks.


*** This bug has been marked as a duplicate of 209168 ***