Closed Bug 572074 Opened 9 years ago Closed 8 years ago

Certificate for mail encryption not found using LDAP

Categories

(Thunderbird :: Security, defect)

x86
Windows XP
defect
Not set

Tracking

(thunderbird6 fixed, thunderbird7 fixed)

RESOLVED FIXED
Thunderbird 8.0
Tracking Status
thunderbird6 --- fixed
thunderbird7 --- fixed

People

(Reporter: jeremie.stordeur, Assigned: dardokleiner)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.9) Gecko/20100401 Ubuntu/9.10 (karmic) Firefox/3.5.9
Build Identifier: 3.0.4

I configured a LDAP server as an address book and it is working fine : I have the name completion and I retrieve the address mail correctly.
But when I ask for mail encryption, it says there is no certificate for mail encryption available for the user on the server.
Of course the CA is already imported as a trusted authority and when I import the certificate manualy from the LDAP server to my desktop and then in Thunderbird, the mail encryption works fine.
More important, when I use an older version of Thunderbird : 2.0.0.24, the certificate is correctly imported and saved from the LDAP server.

Reproducible: Always
Anything in tools -> Error console ?
No, I just get the message :
"L'envoi du message a échoué.
Vous avez demandé le chiffrement de ce message, mais l'application n'a pas trouvé de certificat de chiffrement pour user@domain.fr"
translated ->
"the sending of the message failed.
You asked for the encryption of the message but the application didn't find any encryption's certificate for user@domain.com"
Nikolay can you confirm ?
Jeremie, so you saying 2.0.0.24 version automatically import your personal certificate via ldap while 3.0.4 not?
Yes indeed, but it is not exactlty my "personal" certificate. It is the certificate of the person I'm writing to.
I was having the same problem, but in my case it seemed to be only usability issue.

I have configured LDAP as source. Address completition works.
When writing email I click "S/MIME" and I see list of certificates for all recipients, but those from LDAP have got certificate missing.

As soon as I tick to encncrypt, certificates are downloaded from LDAP and then clicking "S/MIME" again shows the certificates available.

This was unexpected behaviour when I have seen it for the first time. 
I would say it would be more comfortable to have certificates downloaded when clicking "S/MIME" for the first time, despite the fact that message is currently not ticked to be encrypted.

Please Jeremie could you check your problem is same as mine?
Best regards
Michal Ambroz
I can confirm the behavior described by "Michal Amborz" in comment 6 above.

[Environment]

OS: Fedora 12 x86_64
Kernel: kernel-2.6.32.26-175.fc12.x86_64

Thunderbird version info:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10

Add-ons:
DoD Coonfiguration 1.2.1 (from Forge.mil)
Lightning 1.0b2pre
Provider for Google Calendar 0.6b2pre

[Smart Card drivers and services]

Smart Card drivers/libraries: cackey-0.5.20-1.x86_64 (from Forge.mil)
Smart Card daemon: pcsc-lite-1.5.2-5.fc12.x86_64

[Configuration]

Thunderbird Preferences:
========================
Category: Composition
Tab: Addressing

Address Autocompletion:
[x] Local Address Books
[x] Directory Server: [DoD 411]
[x] Automatically add outgoing e-mail addresses to my: [Collected Addresses]

Category: Advanced
Tab: Certificates
Button: [Security Devices]
Device Manager:
	Module: CACKey PKCS#11 Module
	Path: /usr/lib64/libcackey.so
========================


Thunderbird Account Settings:
=============================
Composition & Addressing:
    Addressing:
        (.) Use my global LDAP server preferences for this account

Security:
    Digital Signing:
        [my digital certificate:Identity #1]
        [ ] Digitally sign messages (by default)
        (un-checked)
    Encryption
        [my digital certificate:Identity #2]
        (.) Never (do not use encryption)

=============================


[Actions to reproduce]

Click button: [Write]

Begin typing in recipient names and select addresses from "DoD 411" directory lookup drop-down list.

In composer, click drop-down: [Security]->[View Security Info]
    (both checkboxes un-checked)
    [ ] Encrypt This Message
    [ ] Digitally Sign This Message

    "Message Security" dialog opens
    Shows both recipients' Certificate status "Not Found"

Click box to "Digitally Sign"

    Progress bar at bottom appears but unfilled
    Envelope icon appears with red circle on top

Click envelope icon
	"Message Security" dialog opens showing:
	Digitally Signed: Yes
	Encrypted: No
	Both recipients' Certificate status "Not Found"

Click box to "Encrypt"

Clicked on padlock icon
	Immediately following click, see a pop-up saying something about downloading certs that quickly disappears, followed by the "Message Security" dialog.
	Digitally Signed: Yes
	Encrypted: Yes
	Both recipients' Certificate status now shows "Valid" along with "Issued" and "Expires" dates.


[Additional Info]

Using Certificate Manager, in the [People] tab, I can see the new contacts listed with their certificates and issued/expiration dates.

Checking the "Collected Addresses" in address book confirms addressees were added.

All subsequent messages sent to recipients who's addresses and certificates have been stored in addressbook and certificate manager show up immediately in auto-completion and their certificate status is listed as valid regardless of whether security check-boxes are marked.
I can also confirm this behavior - however in our case we could nail it down to the presence or absence of Extended Usage Key parameter "E-Mail Protection". We are able to retrieve certificates from LDAP only if EUK is set to "E-Mail Protection". If not, we observe the same behavior as Jeremie.
The signature of the nsILDAPOperation::searchExt function changed but the certificate fetching code was not updated.
Assignee: nobody → dardokleiner
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment on attachment 544560 [details] [diff] [review]
nsILDAPOperation::searchExt no longer takes aAttrCount

Ain't sure Mark is an appropriate reviewer, but it's LDAP code so going with him for now.
Attachment #544560 - Flags: review?(mbanner)
See: mozilla/directory/xpcom/base/public/nsILDAPOperation.idl

Used to be:
    * @param aAttrCount        Number of attributes we request (0 for all)
    * @param aAttributes       Array of strings, holding the attrs we need

Is now:
     * @param aAttributes       Comma separated list of values, holding the
     *                          attributes we need
Attachment #544560 - Attachment is obsolete: true
Attachment #544560 - Flags: review?(mbanner)
Attachment #544569 - Flags: review?(mbanner)
Comment on attachment 544569 [details] [diff] [review]
wanted_attributes should no longer be an Array, searchExt call now takes a comma-separated string of attributes

Thanks for the patch, I suspect this isn't the original issue in this bug, as that was reported against 3.0 and this regressed between 3.1 and 5.0, however, we'll run with it here, and we can always file a new issue if the original reporter is still having problems.
Attachment #544569 - Flags: review?(mbanner) → review+
I can confirm that the patch fixes the LDAP problem in Thunderbird 5 for me.

In my setup, a freshly build Thunderbird 5 under Ubuntu (source from http://hg.mozilla.org/releases/comm-2.0) was not able to import any certificates from an LDAP directory.

After applying the changes from the patch and rebuilding, Thunderbird was able to import certificates again.
(In reply to comment #13)
> In my setup, a freshly build Thunderbird 5 under Ubuntu (source from
> http://hg.mozilla.org/releases/comm-2.0) was not able to import any
> certificates from an LDAP directory.

Thunderbird 5 was shipped from http://hg.mozilla.org/releases/comm-miramar/

All future Thunderbird releases will be shipped from http://hg.mozilla.org/releases/comm-release/
Oops. Sorry for the noise. Will recheck with comm-miramar... .
Checked in: http://hg.mozilla.org/comm-central/rev/fd34f29cd4b8
Blocks: 633150
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 8.0
Attachment #544569 - Flags: approval-comm-beta?
Attachment #544569 - Flags: approval-comm-aurora?
Attachment #544569 - Flags: approval-comm-beta?
Attachment #544569 - Flags: approval-comm-beta+
Attachment #544569 - Flags: approval-comm-aurora?
Attachment #544569 - Flags: approval-comm-aurora+
Duplicate of this bug: 679389
Doesn't seem to be fixed. I'm using TB 17.0.3 and get the following logging:

-1980254432[7f6288d5e040]: nsLDAPOperation::SearchExt(): called with aBaseDn = 'o=XXX, c=DE'; aFilter = '(|(mail=*spe*)(cn=*spe*)(givenName=*spe*)(sn=*spe*))'; aAttributes = description,notes,title,sn,surname,mozillaHomeLocalityName,givenName,mozillaHomeState,mail,mozillaWorkUrl,workurl,labeledURI,o,company,mozillaNickname,xmozillanickname,mobile,cellphone,carphone,modifytimestamp,nsAIMid,nscpaimscreenname,telephoneNumber,birthyear,c,countryname,mozillaHomeStreet,cn,commonname,postalCode,zip,mozillaCustom1,custom1,mozillaHomeCountryName,homePhone,st,region,mozillaCustom2,custom2,mozillaSecondEmail,xmozillasecondemail,facsimiletelephonenumber,fax,mozillaCustom3,custom3,mozillaUseHtmlMail,xmozillausehtmlmail,mozillaHomeStreet2,birthday,street,streetaddress,postOfficeBox,mozillaCustom4,custom4,mozillaHomeUrl,homeurl,l,locality,pager,pagerphone,ou,department,departmentnumber,orgunit,birthmonth,mozillaWorkStreet2,mozillaHomePostalCode,objectClass; aSizeLimit = 100


So, there is no userCertificate requested.
I don't know how to reopen this ticket.
you need to open a new one
You need to log in before you can comment on or make changes to this bug.