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)

31 Branch
x86
macOS
defect
Not set
major

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
but does it work without the error 19.
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.
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.
(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)
Still waiting for our LDAP-admin to install a new certificate (chain), will give more infos ASAP

Thank you
Flags: needinfo?(reinfried.o.peter)
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.
(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)
Looks good, just tested with 52.5.2 and works fine for me!
Flags: needinfo?(reinfried.o.peter)
(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
We use DigiCert certificates and at the moment I use LDAP without Bind-DN within our network.
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.
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.
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?]
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)
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
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.
(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
Flags: needinfo?(shopik)

It's not working with TB 68.2.0

Kind regards
Pepe

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.

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.