Opened 16 years ago
Last modified 7 years ago
#3142 new defect
TLS doesn't work
Reported by: | Owned by: | Emmanuel Blot | |
---|---|---|---|
Priority: | normal | Component: | LdapPlugin |
Severity: | normal | Keywords: | tls patch |
Cc: | cbonar, Bruno Harbulot | Trac Release: | 0.10 |
Description
TLS support in the LDAP plugin is broken.
First of all, IIRC TLS works over port 389, not 636 (which is the SSL port, SSL != TLS). This should be fixed in api.py
Also, there are no options to set certificates in trac.ini. (It doesn't use the (CA) certificate set in /etc/openldap/ldap.conf, does it?) I guess to make TLS really work there is still some work to do.
Anyway, I didn't have time to dive into this any further. I hope this can be fixed by someone else.
Or perhaps I missed something, in which case the Wiki documentation should be updated to explain how TLS works with ldapplugin.
Thanks!
Attachments (1)
Change History (6)
comment:1 Changed 16 years ago by
Cc: | cbonar added; anonymous removed |
---|
Changed 15 years ago by
Attachment: | certverif-and-starttls.patch added |
---|
Added support for START_TLS and certificate verification
comment:2 Changed 15 years ago by
Cc: | Bruno Harbulot added |
---|
I've just added a patch to support START_TLS and certificate verification. (For some reason, nothing appears in if you click on the link with the "pretty" view, but the patch is there if you the "Original Format" link at the bottom of the page.)
TLS and SSL are the same thing (or close enough in this context); what's fundamentally different is the use of START_TLS.
A direct TLS connection is done to a port expecting TLS connections initially (via ldaps://
, port 636 usually for LDAP), whereas using START_TLS initiates a non-encrypted connection (ldap://
, usually on port 389 for LDAP) and then switches on TLS on the same connection, using the appropriate START_TLS command.
I've thus added the use_start_tls
option in this patch. START_TLS will be used if this is set to true and if use_tls=false
. If use_tls=true
, the initial connection will be made using TLS. (I've only made use_tls
win over use_start_tls
to keep compatibility with the previous settings.)
Since TLS connections (whether-or-not using START_TLS) are not actually secure if the client doesn't verify the server certificate, I've also added options to point to CA certificates:
tls_cacertdir=/path/to/ca/cert/dir
: This option expects a directory containing trusted CA certificates. Unfortunately, this doesn't seem to be supported by GnuTLS, if your client library has been compiled against it.
tls_cacertfile=/path/to/ca/cert/file
: This option expects a file containing a set of concatenated CA certificates (in PEM format). This works for me (especially, if this option is set and the certificate isn't trusted by one of the CAs, the connection fails as it should).
comment:3 Changed 15 years ago by
I should perhaps add the versions with which I've tested this:
- Trac 0.11.6
- Ldap plugin rev 5686 with patch from #6183
comment:5 Changed 7 years ago by
Keywords: | patch added |
---|
Hello
I've made the same assertion : startTLS doesn't seem to work with ldapplugin 0.10.
Here are some steps to reproduce the problem :
1) Installed openldap 2.4.11 (on Debian Lenny)
2) Slapd configured to accept startTLS connections on port 389 (as recommended in the manual)
(Running it with the following command, in order to have debug information :
)
3) Tested ok with the following command :
4) Installed ldapplugin 0.10 from svn
5) trac.ini of my project as follows :
(Note : I've tried all kind of combinations, this is the most complete one, but all the others gave the same result)
6) When I connect to my project (let's say http://esgaroth/trac/myproject), I've the following error :
and, on the ldap server side :
... I don't see any 'start_tls'...
7) When I change use_tls = true for use_tls = false in trac.ini, it works (I can reach my project's page).
Hope this helps..