You are here
Colin Bitterfield - Tue, 2019/06/11 - 21:13
I can connect and verify that things are working on port 389. No connection is available on 636 using SSL.
Do I have a configuration setting wrong or does this need to be enabled?
Forum:
Hi Colin, thanks for getting in touch
According to everything I can see, it should "just work". However, I haven't recently double checked it myself and from your note, it appears to not be the case, at least in your instance.
I've added checking this out to my backlog and will hopefully get to it later today, or at least within the next day or 2 (and will certainly prioritise if you can confirm that there is an issue before I get to it).
In the meantime, there's a couple of things that you can check. First up, double check the AWS Security Group that your instance is using. It should include the port 636 by default. If not, please try adding it to the current security group. Also please let me know and I'll ensure that it gets fixed ASAP.
If port 636 is being allowed by default (or you've now enabled it and still not having any luck), then the next step would be to double check that your server is listening on port 636. To do that log in via SSH and run the following command (assuming running as root; otherwise prefix with 'sudo'):
You should see port 636 listed there in the output. If it's not listening, then there is something wrong with the config. Again, please let me know so I can prioritise further investigation.
Failing that, you may get some hints of what is going wrong from the journal and/or logs. TBH, I'm not sure if OpenLDAP (slapd) logging is enabled by default, but the journal should include any entries of significance. Unfortunately I don't have a copy of the OpenLDAP server handy, but as I hinted above, the OpenLDAP service should be called slapd. So to check the journal, should be something like this (again prefix with 'sudo' if not running as root):
If logging is enabled, then I would expect there to be a slapd log file within /var/log somewhere. This should assist finding it (if it exists - again prefix sudo if not running as root):
FWIW the config file (where you can enable logging if it's not) should be found at /etc/ldap/slapd.conf. And the config items related to logging are 'logfile' and 'loglevel'. To apply config changes your need to restart slapd, i.e. 'service slapd restart'.
Hopefully, I'll get to this shortly and be able to head you in the right direction (before you post back) but as I say, if you can confirm any of these are issues, please let me know and I'll re-prioritise to develop a work around for you, with an aim to fix and re-release ASAP.
Thanks again for posting.
Some more info...
Due to my unfamiliarity with OpenLDAP, I'm not sure how much more value this post will add. However, I have done some basic testing and it appears sort of ok from what I can gather, although my final test via OpenSSL doesn't appear quite right...
I am testing a local LXC container so I couldn't check the AWS security group. But otherwise, I'm using the same version (i.e. v15.0) so it should essentially be the same as what you have.
On my server OpenLDAP is listening (on all interfaces) on port 636:
There are no errors in the journal that I could see. There are also a range of certificate related files in the /etc/ldap/tls directory:
However, it appears that there is something not quite right... A connection via OpenSSL (from my Linux desktop) doesn't appear to be showing any errors, but isn't showing any certificate and/or cypher info either?!:
$ openssl s_client -connect 192.168.1.113:636 CONNECTED(00000003) write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 176 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1560326371 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no ---TBH, I'm not 100% sure how it's meant to look WRT OpenLDAP, but I'm pretty sure that isn't right?! Probably needs some more investigation...
Additional information LDAPS issues and troubleshooting
The LDAP server works fine on port 389. My application does not support self-signed certificates.
I tried the openssl and I see the same issue.
There are a couple of other issues that I see.
1. It's difficult to add an SSL certificate that is not from Let's Encrypt. We have our own DIGICert and the confconsole does provide a method for adding it.
2. The logging of the OpenSSL (slapd) is in the new cn=config which is nearly impossible to understand how to modify. The issue is that I can't find an easy method to turn on DEBUG level logging and there is no slapd.log (or openldap.log). That should also be configurable in confconsole.
3. The Webmin interface does not have a LDAP/Slapd module loaded and you can't load the module due to a dependency on perl NET::Ldap
4. I have checked all of the AWS security groups and verified that they are good. I can access on 22, 80,443, 12320,12321, and 636 is configured.
I've done a little more reading...
I've done a little more reading but unfortunately, I still don't have a conclusive answer for you. :( It seems that there are 2 ways to configure SSL certs (or more correctly TLS certs) for OpenLDAP. The legacy one uses port 636 for SSL/TLS (LDAPS), the other uses the default port 389 for both secure and insecure traffic (if I understand correctly, it first tries secure, then falls back to insecure if that doesn't work). The latter appears to be the preferred method these days (with port 636 still supported for legacy clients that can't use SSL/TLS via port 389).
Although having said that, I get the same response from OpenSSL when trying to connect to port 389 (as I do for port 636). So whilst it appears that in theory the TurnKey appliance supports both, there still seems to be something missing. So we're not really any closer... :(
To explicitly respond to your questions:
1. Yes that's correct. Confconsole does not have a plugin which supports adding certificates from any other source (other than generating Let's Encrypt certs). So you'll need to configure that manually. Certificates can come in range of formats so I can't explicitly tell you exactly how to do it, but I did write up a blog post last year on how to convert different certificate formats to ones that will work with Debian (the basis of TurnKey). There is also a quite dated, but likely still relevant blog post written by Alon covering third party certs. Hopefully either or both of those will be of some value.
Please note though that both of those blogs are in reference to web servers. I.e. they will be relevant for setting up a cert for phpLDAPadmin (runs behind LigHTTPd). It may take a little fiddling to get it working with OpenLDAP itself (after this initial issue is resolved...).
2. In Debian 9/Stretch (the basis of all v15.x appliances) the OpenLDAP logs are combined within the Syslog. In theory it should be possible to get it to log to a separate file, however, I fiddled with that bit and couldn't get it working... So you have 2 options, either configure the logging (to syslog) to be debug level and view the log entries via journalctl. Or alternatively, stop the service and launch it interactively via the commandline (which will output logs to the SSH session).
Personally, I think that the former is better. To do that, first set the OpenLDAP syslog level to debug (i.e. add "-s -1" to the SLAPD_OPTIONS in the /etc/default/slapd file). Here's a sed line to do that for you (prefix all commands with sudo if not running as root):
Then restart slapd:
You should now see OpenLDAP debug log entries in the journal. Here are a few handy journalctl commands:
Personally I find the last can be really useful for troubleshooting if you open mutliple SSH sessions, one "following" the log, whilst running commands, etc in another.
To disable debug when you're done:
The other way is to just run it directly in the terminal. I suspect the debug syslog should be sufficient, but for completeness:
3. To install perl NET::Ldap:
4. Ok well that's a bugger... I can only assume then that there is something not quite right with the config then... Hopefully the info above might assist to get you headed in the right direction.
Extra info and resources I'll aim to circle back around to this ASAP and have a closer look myself. In the meantime, here's some links that may be of some assistance for further research. If you find anything of value, it'd be awesome if you post back.
Debian OpenLDAP wiki page Note: TurnKey v15.x is based on Debian 9/Stretch - also Debian wiki pages can be hit and miss; it looks like the info towards the top is relatively new, with much of the info further down outdated... Debian Stretch ldap.conf man page Debian Stretch slapd.conf man page Ubuntu 18.04 OpenLDAP wiki page Note: Ubuntu is also based on Debian, so this will likely be "mostly" relevant (if not completely). OpenLDAP 2.4 Admin guide - Upstream documentation. OpenLDAP "FAQ-O-matic" OpenLDAP mailing list(s) (I suspect "Technical" is the one you'd want...)
Additional information LDAPS issues and troubleshooting
The information you provided was exactly what I needed. The SED commands did the trick. It put the logs to syslog but that was good enough for us to troubleshoot the issue.
I was able to install certificates for LigHTTPd without much issue. There was a guide on Digicert for it. I use NGINX or Apache not much experience with LigHTTPd.
On the LDAPS, I haven't found a way to verify the SSL certificate on the server. The usual OpenSSL trick doesn't work. I get the same results as the comment from Jeremy Davis.
Right now I am looking for a tool that supports LDAPS for reading the SSL certificate. This would also validate it was working on SSL.
We have it all working on LDAP (non-SSL).
If anyone has an idea of how to test for the certificate that would be helpful.
Hi Colin, we think we have a fix...
After a ton of digging and a bit of testing, we think we have isolated the issue. It seems that during the initialisation process, at one point, we restart the OpenLDAP service. But under some circumstance, the service isn't quite ready for the commands that followed. But rather than erroring, the configuration continues, but is incomplete.
I can't 100% guarantee we're completely out of the woods, but it should now be working...
If you could test it on your end would be great. Please note that it will require you to re-initialise the service, so it would pay to ensure that you have a backup of any work you've done. So once you've created your backup, please run the following:
if [[ $USER != "root" ]]; then sudo su fi FILE="usr/lib/inithooks/bin/openldap-reinit.sh" URL="https://raw.githubusercontent.com/turnkeylinux-apps/openldap/master/overlay" wget -O /$FILE $URL/$FILE /usr/lib/inithooks/bin/openldap-reinit.sh YOUR_DOMAIN YOUR_LDAP_ADMIN_PASSWORDWhere you replace YOUR_DOMAIN & YOUR_LDAP_ADMIN_PASSWORD with your actual domain and password.
(Oops, I just realised that there was a wget line missing - I've just updated to include that).
I will test this later today
I will test the fix script later today.
Great thanks Colin
Hopefully that will do the trick. I look forward to hearing how it goes.
That worked.
The information provided here was very helpful in solving the issue.
v/r
Great, thanks for confirming!
I was fairly confident that would fix it, but thanks so much for writing back to confirm.
FWIW following your bug report, further investigation and testing revealed that there was a race condition during the initialisation of OpenLDAP. That meant that it is/was only an intermittent issue (which by their nature are often much harder to pin down).
Thanks so much for reporting your issue with our OpenLDAP appliance. We've rebuilt it (with the fix included) and will publish an updated/fixed version (TurnKey OpenLDAP v15.1) ASAP. Please note that you will likely get a notification about this new version, but as you've already installed the fix, there is limited value for you in updating.
Also, if you feel inclined, it'd be super awesome if you could write a review of your experience with TurnKey OpenLDAP on the AWS Marketplace.
Add new comment