GNOME Bugzilla – Bug 653385
ldaps fails with server using self-signed certificate
Last modified: 2011-06-30 20:18:28 UTC
[This is a duplicate bug report from https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/801828] LDAP fails when using it over SSL, port 636. In fact, TLS seems to have problems too - but most of our testing has been with SSL/port 636 option set. Here is the configuration from the .xml file: <?xml version="1.0"?> <group uid="1308802122.3214.17@abc-desktop" name="On LDAP Servers" base_uri="ldap://" readonly="no"><source uid="1308966745.1776.0@abc-desktop" name="Entic.net" uri="ldap://ds1-sjc.entic.net:636/uid=admin,ou=people,o=entic.net??sub?" relative_uri="ds1-sjc.entic.net:636/uid=admin,ou=people,o=entic.net??sub?"><properties><property name="completion" value="true"/><property name="binddn" value="uid=admin,ou=people,o=entic.net"/><property name="auth" value="ldap/simple-binddn"/><property name="remember_password" value="false"/><property name="ssl" value="always"/><property name="limit" value="100"/><property name="default" value="true"/><property name="timeout" value="3"/><property name="can-browse" value="1"/></properties></source></group> There seems to be a few different bugs open in the recent past related to this. I've tried tinkering with the "ssl" property but without much luck. We have a few customers who use Evolution with our free LDAP hosting service, http://entic.net/CF (CloudFace) and this is not a problem on the server. The logs on the server appear to show clear-text data over LDAPS.
Thanks for a bug report. Is this same as bug #640083, and do patches from there help you, please? If not, is it possible to get some test account on your server to see what is going wrong, please?
You can use: uid=demo,ou=people,o=entic.net evo123 ldaps://ds1-sjc.entic.net:636 I also found it strange that when I first entered this information into Evolution, and selected 636, it would change the pull down option to be "Try TLS ..." or something of that sort. It should really just do LDAP over SSL. Instead, it should do TLS when a port != 636. I do not currently have Evolution/Ubuntu in front me of me try the patches.
Thanks for the test account. I cannot connect to the server neither with evolution, not with ldap search. If I try this command: $ ldapsearch -L -h ds1-sjc.entic.net -w evo123 -p 636 \ -D uid=demo,ou=people,o=entic.net -b uid=demo,ou=people,o=entic.net then it ends with: > ldap_result: Can't contact LDAP server (-1) and when I add -Z, then I get > ldap_start_tls: Can't contact LDAP server (-1) > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Interesting thing is that if I remove the port parameter from the initial command, then it works as expected and lists search results: > ... > # search result > > # numResponses: 34 > # numEntries: 33 Is it possible that 636 port is blocked from the outside?
You are not doing a proper SSL connection via ldapsearch. http://directory.fedoraproject.org/wiki/Howto:SSL#Use_ldapsearch_with_SSL You might also need a -x to make it do a SIMPLE authentication instead of SASL. You can also do telnet ds1-sjc.entic.net 636, and you should get a connection.
Ah, great, thanks, with this line (without left spaces) TLS_REQCERT allow in ~/.ldaprc, and this command: $ ldapsearch -x -H ldaps://ds1-sjc.entic.net -w evo123 \ -D uid=demo,ou=people,o=entic.net -b uid=demo,ou=people,o=entic.net I get same results like without SSL, but this time the password is not sent on the wire. I'm looking how to persuade evolution to do the same.
Interesting, my workaround is to create the ~/.ldaprc file with the content as stated in the previous comment, then evolution starts working. Without that file I get a failure like with the ldapsearch (the same command as above), where the "server down" error masks an SSL error: > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed (self signed certificate in certificate chain) I didn't find a way how to persuade openldap to behave like with the file from the C code yet, but I'll try.
Created attachment 191003 [details] [review] eds patch for evolution; I'm not sure, maybe this is a bug in openldap, because it doesn't respect local ldap context settings on the LDAP_OPT_X_TLS_REQUIRE_CERT option, but it's using the global options, which explains why it worked correctly with ~/.ldaprc, but not when I did the same change as in this patch, but on the blpriv->ldap, instead of the global options. I do not know how correct it is either, with respect of security concerns, but I'm committing it either, because with this change, and self-signed certificate on the server, I'm able to read contacts from the LDAP server over ldaps.
err, "for evolution-data-server;", I meant... Created commit 04a5981 in eds master (3.1.3+) Created commit ad7e932 in eds gnome-3-0 (3.0.3+)
Yup, I think that would do it. The certificate we use is valid, signed by a CA. The reason this isn't working is because the openldap libraries don't come with the CA roots with them. You could bundle some standard (copy from firefox the cert8.db) certificates and then set LDAP_OPT_X_TLS_CERTFILE/CERTDIR options. Then, when you make that ldaps connection, the certificate should be recognized. Right now, they aren't being recognized, so setting it to ALLOW makes it work. Even if the certificate expired and is bad, it will be allowed... in this case. Setting this option is a quick fix though! Thanks, looking forward to using the fixed version.