Open
Bug 1043302
Opened 10 years ago
Updated 1 year ago
LDAP search/autocomplete using SSL doesn't work for TB 31.0. Without SSL still works. Certificate manually trusted in certificate manager is ignored by LDAP-connecting code.
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
UNCONFIRMED
People
(Reporter: reinfried.o.peter, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [regression: TB31?])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140716183446 Steps to reproduce: Updating to Thunderbird 31.0 Actual results: When I tried to send emails to someone whos address should be found at our LDAP server autocomplete didn't work. When I changed the settings to use LDAP without SSL it works, switching again to port 636 (SSL) it again doesn't work. Expected results: LDAP query/autocomplete should work for port 636 (SSL), too.
What software runs your LDAP sever PEPE? Is there a certificate in the certificate manager for the LDAP server? Could you supply an LDAP log so we can have a look at what is actually happening. See instructions for logging here https://wiki.mozilla.org/MailNews:Logging
Hello Matt, the LDAP server runs Novell eDirectory and uses a self signed certificate (I don't know why, because we can order as many certificates as we want from Comodo), the LDAP admin is on vacation. openssl s_client shows: [...] New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: 6742722CCDA556CB7A33C9C6943A190249005698231B5E5905868DFB5E9C3B33 Session-ID-ctx: Master-Key: F760647D5813663C9BD9137BE5831D3A110BF9B5FAF788E0FF26A205CF6E37495D4B5BA27901BCC13B2808C8445DBA55 Key-Arg : None Start Time: 1407219107 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) And I can't find a certificate in the certificate manager. LDAP log: 1965237008[100338370]: nsLDAPOperation::SimpleBind(): called; bindName = ''; 1965237008[100338370]: nsLDAPOperation::SearchExt(): called with aBaseDn = 'OU=Bedienstete,O=tug'; aFilter = '(|(cn=byty**)(mail=byty**)(sn=byty**))'; aAttributes = cn,commonname,mail,objectClass; aSizeLimit = 100 and Mr. Bytyqi will not be found. If I change to port 389 (no SSL) the LDAP log file reads: 1965237008[100338370]: nsLDAPOperation::SimpleBind(): called; bindName = ''; 1965237008[100338370]: pending operation added; total pending operations now = 1 471601152[116db8420]: pending operation removed; total pending operations now = 0 1965237008[100338370]: nsLDAPOperation::SearchExt(): called with aBaseDn = 'OU=Bedienstete,O=tug'; aFilter = '(|(cn=byt**)(mail=byt**)(sn=byt**))'; aAttributes = cn,commonname,mail,objectClass; aSizeLimit = 100 1965237008[100338370]: pending operation added; total pending operations now = 1 471601152[116db8420]: pending operation removed; total pending operations now = 0 1965237008[100338370]: nsLDAPMessage::GetDn(): dn = 'cn=Bytyqi\, Abedin,ou=Bedienstete,o=TUG' Regards Pepe
I am pretty sure it is the self signed certificate, but the normal procedure is a dialog to pop up asking for an exception to be granted. That error 19 indicates that the self signed certificate has no trust authority ie Under Authorities there should be (I assume) your company as a trusted CA.
Maybe there are some problems with certificate manager? I can find our certificates under "Equifax Secure Inc." which is wrong: Equifax Secure Inc. MD5 Collissions Inc exchange.tugraz.at portal.tugraz.at virtualsbox01.tugraz.at mailrelay.tugraz.at I deleted "MD5" and it switched to Kaspersky LAB exchange.tugraz.at portal.tugraz.at virtualsbox01.tugraz.at mailrelay.tugraz.at I deleted virtualsbox01 and exchange and it switched to TERENA mailrelay.tugraz.at portal.tugraz.at addons.mozilla.org and now I can find ldap.tugraz.at, too: EDIR ldap.tugraz.at After deleting mailrelay and restarting it looks like: The USERTRUST network addons.mozilla.org portal.tugraz.at And after deleting addons.mozilla.org it looks again like TERENA portal.tugraz.at
Sorry: no, doesn't work. If I use a PERL-Script (using Net::LDAP) the same LDAP server is answering regardless of ldaps or ldap.
Comment 7•10 years ago
|
||
Does it work if you set security.use_mozillapkix_verification to false (Preferences | Advanced | General > Config editor...)
Keywords: regression
no, doesn't work. Maybe we should wait until the LDAP admin is back? I'll ask him to install a valid certificate and I'll inform you about the tests, then.
Comment 9•10 years ago
|
||
(In reply to Pepe from comment #8) > no, doesn't work. > Maybe we should wait until the LDAP admin is back? > I'll ask him to install a valid certificate and I'll inform you about the > tests, then. Pepe, what'd you find?
Severity: normal → major
Flags: needinfo?(reinfried.o.peter)
Reporter | ||
Comment 10•10 years ago
|
||
Still waiting for our LDAP-admin to install a new certificate (chain), will give more infos ASAP Thank you
Flags: needinfo?(reinfried.o.peter)
Comment 11•7 years ago
|
||
Hi all I know this is a very old bug report, and I'm wondering if to report a new one or continue here. Anyway, the bug still exists in TB 45.8.0 (tested on Linux). Basically, TB does not honour the CAs added manually to the certificate manager for LDAP connections, and does also not allow to add exceptions for them. I have: - issued a certificate for our LDAP server (OpenLDAP) from our private CA - added the CA's certificate to TB's certificate manager's trusted authorities - configured TB to connect via LDAPS on port 636 Even when turning on all possible debugging ( export NSPR_LOG_MODULES=ldap:5,ldapautocomplete:5 ), the only message logged is: 846464832[7f8131193220]: nsLDAPOperation::SimpleBind(): called; bindName = '[omitted]' A tcpdump of the connection shows that TB is rejecting the handshake after receiving the server certificates with a "Bad Certificate" alert: Secure Sockets Layer TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Bad Certificate) Content Type: Alert (21) Version: TLS 1.2 (0x0303) Length: 2 Alert Message Level: Fatal (2) Description: Bad Certificate (42) Also, there's no possibility to add an exception for that connection (even if that shouldn't be necessary as the CA is already trusted in the certmgr). As soon as I replace the certificate with one from a public CA in the certmgr's "Builtin Object Token" (eg. StartCom), the connection succeeds without problems.
Comment 13•6 years ago
|
||
(In reply to Pepe from comment #10) > Still waiting for our LDAP-admin to install a new certificate (chain), will > give more infos ASAP Good results? Bad?
Flags: needinfo?(reinfried.o.peter)
Reporter | ||
Comment 14•6 years ago
|
||
Looks good, just tested with 52.5.2 and works fine for me!
Flags: needinfo?(reinfried.o.peter)
Comment 15•6 years ago
|
||
(In reply to Pepe from comment #14) > Looks good, just tested with 52.5.2 and works fine for me! Did you install a certificate from a public CA on the LDAP server? It's still not working here with a certificate from a private CA and tb 52.5.0
Reporter | ||
Comment 16•6 years ago
|
||
We use DigiCert certificates and at the moment I use LDAP without Bind-DN within our network.
Reporter | ||
Comment 17•6 years ago
|
||
And some other change has been done: We don't use Novell's eDirectory any longer, now we use OpenLDAP and Active Directory, both working with SSL.
Comment 18•6 years ago
|
||
So, the original behaviour hasn't changed in the 4 years this bug is alive ... CAs that were manually trusted in the certmgr are ignored by the LDAP-connecting code. It seems nobody is going to fix this.
Comment 19•5 years ago
|
||
Perhaps Kaie or Nikolay have an idea - see comment 11
Flags: needinfo?(shopik)
Flags: needinfo?(kaie)
Summary: LDAP search/autocomplete using SSL doesn't work for TB 31.0 any loger, without SSL it still works. → LDAP search/autocomplete using SSL doesn't work for TB 31.0. Without SSL still works. Certificate manually trusted in certificate manager is ignored by LDAP-connecting code.
Whiteboard: [regression: TB31?]
Comment 20•5 years ago
|
||
Based on past experience, In most scenarios I debugged, the attempt to setup a private PKI missed important properties when creating the certificates. The first step is to find out why exactly the certificate is rejected, because a cert can be rejected for many reasons. Maybe your private PKI doesn't comply with the many modern expectations of cert attributes. You could try to setup a very simple test webserver that uses your certificate on port 443, import your CA into firefox, and use it to connect to your webserver. Firefox and thunderbird/ldap probably the same validation code, and the error page that firefox display for rejected certificates might contain more details. If you make it easy for us to connect to your ldap server (you could give us your CA certificate and hostname in private), or to your test web server, then we could connect to it using tools, and have a look.
Flags: needinfo?(kaie)
Reporter | ||
Comment 21•5 years ago
|
||
As far as I can see it is working now (TB 60). I didn't try it for a long time, so I don't know since which version it is working. We are still using the same kind of certificates and certificate chain like here: https://security.tugraz.at/ Best regards Pepe
Comment 22•5 years ago
|
||
It does not work for me (TB 60.3.1 on Linux). I have tried to get debug information, but neither of the below yields any output: export NSPR_LOG_MODULES=ldap:5 export MOZ_LOG_MODULES=ldap:5 export NSPR_LOG_MODULES=LDAP:5 export MOZ_LOG_MODULES=LDAP:5 Neither Firefox nor Thunderbird have a problem connecting to servers presenting certificates from the private CA. You can check the certificate at directory dot xfer dot ch on the standard ldaps port.
Comment 23•5 years ago
|
||
(In reply to Markus Wernig from comment #22) > export NSPR_LOG_MODULES=ldap:5 > export MOZ_LOG_MODULES=ldap:5 > export NSPR_LOG_MODULES=LDAP:5 > export MOZ_LOG_MODULES=LDAP:5 OK, so it's MOZ_LOG=LDAP:5 now ... This also does not result in any output during operation, but when shutting down thunderbird (and only after the main window has disappeared), some debug info is written, albeit not very useful: [2559:Main Thread]: D/LDAP nsLDAPOperation::SimpleBind(): called; bindName = 'ou=user,ou=some-ou,ou=some-other-ou,dc=dc,dc=country'; [2559:Main Thread]: D/LDAP nsLDAPOperation::SimpleBind(): called; bindName = 'ou=user,ou=some-ou,ou=some-other-ou,dc=dc,dc=country'; [2559:Main Thread]: D/LDAP unbinding [2559:Main Thread]: D/LDAP unbound [2559:Main Thread]: D/LDAP unbinding [2559:Main Thread]: D/LDAP unbound
Updated•5 years ago
|
Flags: needinfo?(shopik)
Reporter | ||
Comment 24•5 years ago
|
||
It's not working with TB 68.2.0
Kind regards
Pepe
Comment 25•1 year ago
|
||
I tested LDAP with a secured connection over SSL in Thunderbird stable v102 and Beta v112 and can confirm that LDAP search works for me. This bug may still be valid for self-signed or un-trusted certificates.
Reporter | ||
Comment 26•1 year ago
|
||
Tested with 102.9.0 (64-Bit), looks good, thank you!
You need to log in
before you can comment on or make changes to this bug.
Description
•