333455 - Multiple addresses in 1 certificate not in Others' Certificates (s/mime)

Status: RESOLVED DUPLICATE of bug 332571

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

Description

[Filip Konvička]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; cs; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Thunderbird 1.5.0.1 release

I've got a free Thawte certificate, using it with TB 1.5.0.1. I've got 2 addresses in this certificate. I can sign the messages when I send mail from both addresses, the receiver can verify the message signatures OK. But the receiver can reply (with encryption) only to messages from the primary address, because the certificate is associated only with the primary address in his Others' Certificates list. (He can verify incoming messages from both addresses though!)

Reproducible: Always

Steps to Reproduce:
1. I get a certificate from Thawte. I've got 2 email addresses in this single certificate, A1 and A2 (i.e., Thawte claim that the certificate may be used to sign and encrypt messages for both A1 and A2).
2. I send a signed message to my friend from address A1.
3. My friend receives the message, verifies that the message signature is ok, and my "public key" appears in his Others' Certificates list. The key is listed as usable for address A1.
4. My friend now can send an encrypted message to A1.
5. I send a signed message to my friend from address A2, using the same certificate as before.
6. My friend receives and verifies the message. But now, there is no new entry in his Others' Certificates list. Only the A1 entry is listed, although there should be both A1 and A2 now.

Actual Results:  
My friend is unable to send encrypted messages to A2, even though he has received and verified a signed message from A2.

Expected Results:  
My friend should have both addresses (A1, A2) in his Others' Certificates list.
He should then be able to send encrypted messages to both A1 and A2.

We could not get it working - we tried removing the certificates and changing the order (first sending the certificate from A2 etc.), but no luck.

Comment 1

[Filip Konvička]

It seems that CERT_SaveSMimeProfile in stanpcertdb.c walks through all e-mails in the cert. Maybe the cert sent does not contain everything from the original certificate?

Comment 2

[Frank Wein [:mcsmurf]]

Can you check in the Details tab of the certificate where the second mail address is listed (and where the first one)?

Comment 3

[Filip Konvička]

Thanks for replying!

Both addresses appear in the same place. They each have an "E = " entry in the "Subject" of the certificate; the only other entry in the Subject is "CN = Thawte Freemail Member". This is the only place that I see the addresses in the Certificate Manager.

Thawte claim the following at the certificate retrieval page:

Certificate Distinguished Name
The certificate was requested for the following distinguished name. If there is an email address in here then the certificate will be trusted for signed email coming from that email address. The certificate may also be trusted for additional email addresses.
Common:	Thawte Freemail Member
Email:	A1
Email:	A2

X.509 SubjectAltName
This certificate contains a set of alternative names for the certificate subscriber. They are listed below:
* Email: A1
* Email: A2

Comment 4

[Frank Wein [:mcsmurf]]

Moving for now.

Comment 5

[Kai Engert (:KaiE:)]

I hope this is the same as bug 335021, let's retest once that gets fixed.

Comment 6

[Kai Engert (:KaiE:)]

A couple of days ago, the hotfix for bug 335021 was picked up by both Mozilla trunk and Mozilla 1.8 branch.

Using a current nightly trunk build or 1.8 branch build, could you please test and confirm this bug is now fixed?
Thanks

Comment 7

[Kai Engert (:KaiE:)]

please let us know if you still have this problem

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

Comment 8

[Filip Konvička]

(In reply to comment #7)
> please let us know if you still have this problem
> 
> *** This bug has been marked as a duplicate of 332571 ***
> 

Release 1.5.0.7 works fine, thanks!