User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705) Build Identifier: Thunderbird version 1.5 (20051201) Previously (versions 1.0.x) when the address book was configured to interface to an external LDAP directory, userCertificate was fetched (and used by TB) as well as other attributes. Unfortunately this isn't the case in TB 1.5. I've examined the LDAP request both locally and on the server side and userCertificate is simply not a part of the request. I've noticed that inserting the line pref("ldap_2.servers.default.attrmap.x", "usercertificate"); in "mailnews.js" does effect the requests to include the userCertificate, but of course it doesn't show up in the Thunderbird application while x does not map to anything internally. I assume that this should be rather simple to fix for people with insight in the code? Reproducible: Always

LDAP email certificate fetching is implemented in file mozilla/mailnews/extensions/smime/resources/content/certFetchingStatus.js In the past this was hooked into some mailnews init code, maybe something broke that?

Looks like this is missing 1.8.0.3, try 1.8.0.4

It looks like the cert fetcher gets an error code back from the call to: gLdapOperation.simpleBind(null); which translates to: anonymous bind disallowed.

At least for me, my problem is that the cert fetching ldap search doesn't pass in the login credentials nor the stored password for the ldap server. Just for grins, I manually passed in auth.dn text into the ldap connectio init call: http://lxr.mozilla.org/mozilla/source/mailnews/extensions/smime/resources/content/certFetchingStatus.js#90 and then in the call to SimpleBind, I hard coded my password: http://lxr.mozilla.org/mozilla/source/mailnews/extensions/smime/resources/content/certFetchingStatus.js#146 And then I saw us go through and ask for the cert attribute (there was none so I couldn't actually verify that we add the cert correctly), and the ldap query looked good and we got a response to the search.

Peter, does your LDAP server require a username and a password to connect with?

This patch makes the cert fetching code work when using ldap servers that require username / password credentials. You will get the password prompt on top of the cert fetching dialog if we don't have a stored password for the ldap server. I don't know if this was Peter's problem. It would be good to hear back if his ldap server requires a username / password. Our in house ldap server doesn't support certificates, but I was able to verify that we now correctly search for the cert attribute. If we can get some feedback from Peter, I would like to fast track this for 1.8.0.3 again.

This patch makes the cert fetching code work when using ldap servers that require username / password credentials. You will get the password prompt on top of the cert fetching dialog if we don't have a stored password for the ldap server. I don't know if this was Peter's problem. It would be good to hear back if his ldap server requires a username / password. Our in house ldap server doesn't support certificates, but I was able to verify that we now correctly search for the cert attribute. If we can get some feedback from Peter, I would like to fast track this for 1.8.0.3 again.

Comment on attachment 219789 [details] [diff] [review] support login and password for cert certificate ldap searching bugzilla's being grouchy. sorry for the duplicate request

(In reply to comment #5) > Peter, does your LDAP server require a username and a password to connect with? Nope, you can try it out at: - host: dir.certifikat.dk - port: 389 - searchbase: c=DK Note that we discard wildcards to avoid simple harvesting, but you can request my certificate by filtering on my exact email (pld@tdc.dk) Best regards Peter Lind Damkjaer

(In reply to comment #9) > (In reply to comment #5) > > Peter, does your LDAP server require a username and a password to connect with? > > Nope, you can try it out at: > - host: dir.certifikat.dk > - port: 389 > - searchbase: c=DK > > Note that we discard wildcards to avoid simple harvesting, but you can request > my certificate by filtering on my exact email (pld@tdc.dk) > > Best regards > Peter Lind Damkjaer > Heh. When I tried to connect to dir.certifikat.dk to search for your e-mail address, I got a username/password prompt :). Maybe I didn't configure the directory properly...

(In reply to comment #10) > Heh. When I tried to connect to dir.certifikat.dk to search for your e-mail > address, I got a username/password prompt :). Maybe I didn't configure the > directory properly... Weird, the server does allow anonymous LDAP request. You can verify this by sending a request from a RFC2255-enabled browser (e.g. MSIE): ldap://dir.certifikat.dk/c=DK??sub?(mail=pld%40tdc.dk) or by making a request from a commandline-lapdsearch (not sure how this is exactly done). Regards Peter

I've added your LDAP directory Peter and good news (at least for me), a freshly downloaded 1.5.0.2 build is correctly finding your certificate. I'll attach a screen shot of what I see with a 1.5.0.2 build.

screen shot showing that we found the certificate from the ldap directory. Taken from 1.5.0.2

(In reply to comment #12) > I've added your LDAP directory Peter and good news (at least for me), a freshly > downloaded 1.5.0.2 build is correctly finding your certificate. > I'll attach a screen shot of what I see with a 1.5.0.2 build. I can confirm that my problem seems solved in 1.5.0.2 build. It also works for me now.

clearing the regression flag. I'd still like to add the support for login/pwd information for this on the trunk and 1.8.1 branch.

I think what's left for this issue can wait for thunderbird 2.

clarifying the summary.

(In reply to comment #12) > I've added your LDAP directory Peter and good news (at least for me), a freshly > downloaded 1.5.0.2 build is correctly finding your certificate. > > I'll attach a screen shot of what I see with a 1.5.0.2 build. > Not sure how you did this, but a freshly downloaded and installed Thunderbird 1.5.0.2 (20060308) build DOES NOT request the userCertificate attribute. Per an ethereal capture, the attributes requested are: Attribute: company Attribute: o Attribute: mail Attribute: street Attribute: streetaddress Attribute: postOfficeBox Attribute: mozillaUseHtmlMail Attribute: xmozillausehtmlmail Attribute: mozillaCustom2 Attribute: custom2 Attribute: mozillaHomeCountryName Attribute: department Attribute: departmentnumber Attribute: ou Attribute: orgunit Attribute: mobile Attribute: cellphone Attribute: carphone Attribute: telephoneNumber Attribute: title Attribute: mozillaCustom1 Attribute: custom1 Attribute: mozillaNickname Attribute: xmozillanickname Attribute: mozillaWorkUrl Attribute: workurl Attribute: fax Attribute: facsimiletelephonenumber Attribute: mozillaSecondEmail Attribute: xmozillasecondemail Attribute: mozillaCustom4 Attribute: custom4 Attribute: nsAIMid Attribute: nscpaimscreenname Attribute: givenName Attribute: l Attribute: locality Attribute: homePhone Attribute: mozillaHomeUrl Attribute: homeurl Attribute: mozillaHomeStreet Attribute: st Attribute: region Attribute: mozillaHomePostalCode Attribute: mozillaHomeLocalityName Attribute: mozillaCustom3 Attribute: custom3 Attribute: birthyear Attribute: mozillaWorkStreet2 Attribute: mozillaHomeStreet2 Attribute: postalCode Attribute: zip Attribute: c Attribute: countryname Attribute: pager Attribute: pagerphone Attribute: sn Attribute: surname Attribute: mozillaHomeState Attribute: description Attribute: notes Attribute: modifytimestamp Attribute: cn Attribute: commonname -JSP

I think we optionally fetch certs from ldap when doing s/mime...

(In reply to comment #18) > > Not sure how you did this, but a freshly downloaded and installed Thunderbird > 1.5.0.2 (20060308) build DOES NOT request the userCertificate attribute. Compose a mail message, use menu "options / security / encrypt this message", and either use "view security info" or try to send the message, and you should see an ldap request to fetch the cert.

> Compose a mail message, use menu "options / security / encrypt this message", > and either use "view security info" or try to send the message, and you should > see an ldap request to fetch the cert. > 1) Opened a new 'compose' 2) Set options->security->encrypt this message 3) Typed the name of the user I want to send to in the address book search. * LDAP query made here, *no userCertificate attribute requested*. 4) Selected matching address from the query repsonse screen, it is now in the To: field 5) Add some text and hit send. * "Sending of Messge Failed\nYou specified encryption for this message, but the application failed to find an encryption certificate for [name in To:]" * No additional LDAP query made 6) Chose view->Message Security Info * I see the recipient listed with status of "Not Found" * No additional LDAP query made. If I use only the address book to do the lookup, still no userCertificate attribute being requested. -JSP

Hey Dan, any chance you'll have some time to review this ldap cert patch?

(In reply to comment #22) > Hey Dan, any chance you'll have some time to review this ldap cert patch? > We are having the same issue (bug post 354525) when trying to fetch certificates using anonymous bind. Will there be a patch for this bug anytime soon?

Comment on attachment 219790 [details] [diff] [review] support login and password for cert certificate ldap searching trying david.

fixed branch and trunk.

*** Bug 294457 has been marked as a duplicate of this bug. ***

*** Bug 149013 has been marked as a duplicate of this bug. ***

BUG still exists in some other way now - using 2.0.0.12 (20080213) The LDAP Search will only be used as long as no @ is encountered while typing into the TO Field I.e. i type : john.doe In the LDAP Request logs i see (|(cn=jo*)(mail=jo*)(sn=jo*)) (|(cn=joh*)(mail=joh*)(sn=joh*)) (|(cn=john*)(mail=john*)(sn=john*)) (|(cn=john.*)(mail=john.*)(sn=john.*)) (|(cn=john.d*)(mail=john.d*)(sn=john.d*)) (|(cn=john.do*)(mail=john.do*)(sn=john.do*)) (|(cn=john.doe*)(mail=john.doe*)(sn=john.doe*)) so for every char i typ a lookup is down (type ahead) which is correct - but as soon as i start with the @ - no lookup is being performed! john.doe@somewhere.com In other words - when LDAP is only indexed by email (default) this will never work! Please fix it that way - that LDAP lookup does NOT stop at "@"

please somebody reopen this bug again

(In reply to comment #29) > please somebody reopen this bug again > Please can you file a different bug for your issue after search for other possible duplicates. Your bug does not appear to be related to issues of authentication.

as requested i open up a new bug https://bugzilla.mozilla.org/show_bug.cgi?id=454563