Closed Bug 165127 Opened 22 years ago Closed 22 years ago

Fetching certificate for encryption fails

Categories

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

Product:
MailNews Core
Component:
Security: S/MIME
Version:
Other Branch
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
psm2.4

People

(Reporter: j.schirrmacher, Assigned: KaiE)

References

Details

Attachments

(2 files)

Screenshot of certificate status
46.12 KB, image/gif
Details
Screenshot of error dialog box
50.22 KB, image/gif
Details 
When using encryption with an existing certificate in Mozilla 1.1 (released
version) for another person, sending a mail results in an error "sending of
message failed. Unable to encrypt message. Please check..." althogh it worked
before upgrading from Moz 1.0 (released version) with the same certificate.

Sending a mail to myself works.

Reproduces on Linux and Windows 2000
Reassigned to PSM for investigation.
Assignee: wtc → ssaux
Component: Build → S/MIME
Product: NSS → PSM
QA Contact: wtc → carosendahl
Joachim, after you see this error message, can you use "view message security
info" to see what is cauing the problem.

Could you quote the information that is displayed there?
What does the "status" column say for the other person's certificate?

Message security info for the not working adressee says "Status: valid",
"Issued:15.05.2002" and "Expires: 15.05.2003".

Strangely with another adressee it works... but I'm sure, with M1.0 the other
one works too.

Meanwhile a couple of other errors occured when sending encrypted mail.
Sometimes Mozilla just crashes (on Linux). Some other the following message
comes up:

-- snip
Downloading certFetchingStatus.xml

You have chosen a file of type: "XML-based user interface language"
[mozilla.application/cached-xul] from chrome://messenger-smime/content/

What should mozilla do with this file?
 - open using an application
 - save file to disk
-- snip

with the message window still open and not responding to any mouse activity any
more. Downloading results in an empty file.


couple of things to look at;

1.  Check the CA cert of the addressee that is failing.  Make sure that it is
present in the CA tab and is trusted.

2.  Try a new profile, read in the user's message and attempt to reply
encrypted.  If that fails, then number 1 is most likely the problem.

Let me know if this works or not.

    
    

    
  


  

    
    

    
  
The error occurs on sending a new mail message to a colleague - not on replying
to mail from him. The CA is Thawte Freemail CA, valid 'til 2021-01-01 for both
certificates, his and mine.

    
    

    
  
Are all of the trust bits set on the issuing CA in the CA tab?  Try checking and
unchecking them and verify that the CA cert in the CA tab is the same cert as
the one thawte used to sign your freemail certs (expires in 2020 or something
liek that)

Also, check your colleague's cert to see if it contains multiple email
addresses, which thawte currently allows, but mozilla currently does not
support.  If it does contain multiple email addresses, the current behavior is
random. 

    
    

    
  
All of the trust bits are set on the issuing CA in the CA tab.
I checked them and unchecked them, still doesn't work.
Verified that the CA cert in the CA tab is the same cert as the one thawte used
to sign my and my colleagues freemail certs.

Saw, that I had two certificates from my colleague, each with one e-mail
address, one the valid one and the other an older, expired one. Deleted the old
one but still don't works...

I would attach the public key of the certificate if I'd know a method for
exporting it. Do you know one?


    
    

    
  
That's all really strange. Maybe there is a regression in 1.1. Could you try
once again with 1.0.1?

If that doesn't help either, could you try to recreate your cert database from
scratch (Exporting all your certs, make sure you will not loose any safed web
passwords by not using encryption, erase *.db in your profile directory,
re-import your certs).

Re that problem with "certFetchingStatus", that is the name of a dialog that
will be shown while Mozilla is trying to download certificates from a LDAP
directory. Mozilla should not prompt you offering you to download that file,
that's definitively a bug. Unfortunately I was never able to reproduce. A
colleague reported that problem, but only saw it exactly once, and it never
happened again. I only can suspect that something went wrong internally in
Mozilla's chrome regristration. If the profile you are currently using was used
with a lot of different Mozilla test versions, please note that a damage might
happen due to a bug in a daily build. It is worth trying with a fresh profile or
at least security databases.


    
    

    
  
Kai, I would like to test exporting all certificates, delete the *.db files from
the profile and re-import the certificates again. But I'm sorry I don't know how
to export them - could you give me a hint?

Maybe some more information from me: you mentioned LDAP... I have a LDAP server
configured for finding e-mail addresses. I will deactivate LDAP and try again...
no. No difference.

    
    

    
  
It's only possible to export your own user certificates. There is a backup
button in cert manager.

For all the other certificates it's not possible to export them. It would be
better anyway if you just recreated the trust you need by importing your own CAs
(if necessary), and get the email certificates from other people by clicking on
their signed mail once.

However, I just remember an issue that might be related. Have a look at bug
163900. (Not solved yet)

    
    

    
  
Ok, I tired this. Still doesn't work. Maybe it is only the certificate from my
colleague which seems valid (see
http://bugzilla.mozilla.org/attachment.cgi?id=97096&action=view) but isn't? Do I
have any chance to attach this cert to this bug?

    
    

    
  
Let's try it the hard way.

In recent builds of Mozilla (trunk, unstable), there is the new feature to
explicitly trust a person's email certificate.

Please get a recent build from ftp.mozilla.org from latest-trunk.
First, try to see whether that newer build alone fixes your problem.

If it still does not, go to edit/prefs/privacy/certs/manager/other people.
First, use "view" to see whether that cert is indeed trusted.

Select that person's cert and click the edit button. Trust it. Now try again to
send your mail.

If that still doesn't work, I'm clueless, and would assume that not the
recipient cert is the cause, but your own cert. But I think you said you can
send mail to other's. That's weird.

Are you in Wiesbaden?


    
    

    
  
Just downloaded the latest trunk and checked the "trust" boxes for the cert and
the CA. The error "sending of message failed. Unable to encrypt message. Please
check..." resists, but it didn't crash until now and didn't trry to download
certFetchingStatus.xml.

Now I switched back to 1.1 (Release) because I can't open the messenger window
(new mail works) and the browser is very slow on my computer. Now it seems that
it works just the same. Maybe the lastest-trunk-version modified the certs somehow?

So the only remaining error is the "sending of message failed. Unable to encrypt
message. Please check...", although certs are valid.

No, I'm not in Wiesbaden, I'm in Mainz.

    
    

    
  
can you have your colleague mail me a signed message so I can take a look?  CC
kai also.

    
    

    
  
Sounds to me like the installation is corrupt at this point.  Delete the
netscape directory where the binaries exist and reinstall.

Also check that under mail&newsgroup settings that you have configured your
smime certs.

    
    

    
  
I received the mail from Andreas. That mail looks perfectly ok. Mozilla shows a
"valid signature" icon.

I tried with:
- Mozilla 1.0.1 branch
- Mozilla 1.1 release
- Mozilla trunk

All work for me.

Either your certificate database is corrupted, or something else must go wrong,
but I don't have an idea what that should be.

I feel tempted to drive over to Mainz to have a look ;-)

    
    

    
  
Please ignore my previous comment. For a moment I forgot that you complain about
being unable to encrypt.


I'm now able to reproduce your problem!

Replying encrypted to the message works with Mozilla 1.0.x
It does not work with 1.1 or the current trunk.

I'll debug what is happening here.

Assignee: ssaux → kaie
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1+

    
  
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 2.4

    
    

    
  
NS7.0: The Freemail RSA CA seems to be only validated for SSL CA privileges.  

Mozilla 1.0 and Outlook recognize it as an email CA.


    
    

    
  
Also, NS7.0 RTM seems to think the Freemail RSA CA expires on 8/29/2002. 
Outlook seems to think that it is 2004.

I used a new profile, read in andreas' message, and then checked the Freemail
RSA CA within cert manager.

    
    

    
  
I found that bug 150708 is causing this.

My report that it is Mozilla version dependent is wrong.
It is actually profile dependent.

Andreas seems to use a weak crypto S/Mime application, is that correct?


    
    

    
  
In addition to this bug, there are more problems.

Andreas' certificate was issued by an expired intermediate certificate from
Thawte (expired 1 week ago). If you create a new Mozilla profile, and read the
test message from Andreas, the signature is reported as being invalid, because
the intermediate has expired.

Thawte fixed this problem using a trick. It issued another intermediate
certificate that has the same subject, the same "issued at" date, but a longer
validity (until 2004).

If you have already dealed with other people using Thawte certs, you probably
already have that fixed intermediate cert, too. I have it in my profiles.

However, in signed mails that Andreas sends out, there is still the old expired
intermediate cert included, that is why it is being reported as invalid when
receiving with a new profile.

Anyway, I believe this is not causing the problem seen in this bug.



    
    

    
  
Adding dependencies.
Although it might look like bug 150708 is already fixed, Mozilla does not use
that version of the lower crypto library NSS yet. As a result, this problem will
be fixed, as soon as Mozilla is changed to use NSS 3.6. There is a bug that
tracks that change. See bug number nssclienttag36.

Depends on: 150708, nssclienttag36

    
    

    
  
Can you pull down the latest nightly build and confirm whether this problem
still exists?

I have verified that the use of weak crypto now works in the latest builds.

The issue with the duplicate Thawte certs is beyond our control - That was a
mistake on Thawte's part.


    
    

    
  
Yeah! With te 2002100121 build of Mozilla I can successfully send encrypted
Mails to Andreas! Seems to work qite well! Thank you!

    
    

    
  
Fixed with the NSS 3.6 introduction onto the trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
Verified
Status: RESOLVED → VERIFIED

    
  
Product: PSM → Core

    
  
Product: Core → MailNews Core
QA Contact: carosendahl → s.mime

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: