This bug has been created at the request of blingme to allow bug 3193 openldap security update to be validated. It may be related to bug 1978 # service ldap start Starting slapd (ldap + ldaps): [FAILED] Default slapd.conf configuration.. # To allow TLS-enabled connections, create /etc/ssl/openldap/ldap.pem # and uncomment the following lines. #TLSRandFile /dev/random #TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /etc/pki/tls/private/ldap.pem TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem #TLSCACertificatePath /etc/ssl/openldap/ #TLSCACertificateFile /etc/ssl/cacert.pem TLSCACertificateFile /etc/pki/tls/private/ldap.pem #TLSVerifyClient never # ([never]|allow|try|demand) Making changes.. TLSCertificateFile /etc/pki/tls/certs/ldap.pem TLSCACertificateFile /etc/pki/tls/certs/ldap.pem allows the service to start # service ldap start Starting slapd (ldap + ldaps): [ OK ]
For me on Mageia 1, I have private for all three as you showed at the top, and it works fine. On Mageia 2, it was changed by default to use certs for the two lines that you mentioned, but using that configuration does not work. I deleted my ldap.pem files in the process of trying to get this working and they're not being regenerated when starting the service. I then put the two ldap.pem files from Mageia 1 back in place, still no dice. Finally, I changed the two "certs" back to "private" as it was in Mageia 1, and it works! So it appears there are two problems here: 1) auto-generating the ldap.pem files when starting the service if they're not there does not happen (maybe this happens only at package install time?) 2) it does not like the ldap.pem files in certs, it only likes the ones in private
CC: (none) => luigiwalser
On a new install on mageia 1 x86_64, the above change is correct. (In reply to comment #1) > For me on Mageia 1, I have private for all three as you showed at the top, and > it works fine. On Mageia 2, it was changed by default to use certs for the two > lines that you mentioned, but using that configuration does not work. On a new install on mageia 1 x86_64, the above change is correct. > I > deleted my ldap.pem files in the process of trying to get this working and > they're not being regenerated when starting the service. I then put the two > ldap.pem files from Mageia 1 back in place, still no dice. Finally, I changed > the two "certs" back to "private" as it was in Mageia 1, and it works! > > So it appears there are two problems here: > 1) auto-generating the ldap.pem files when starting the service if they're not > there does not happen (maybe this happens only at package install time?) Honestly, no-one should really be using self-signed certs in any serious LDAP setup. Sure, it's a convenience to experiment and get a new install working, but it *really* isn't necessary to generate new certs at service start time (as SSL isn't necessarily a requirement for an LDAP server). A script *is* provided that should generate certs/keys correctly for the default config, /usr/share/openldap/gencert.sh > 2) it does not like the ldap.pem files in certs, it only likes the ones in > private The default behaviour of /usr/share/rpm-helper/create-ssl-certificate is to create separate certificate and the key files. You will notice the key is in private, the cert is in certs, and as such, the file in private should only be used for TLSCertificateKeyFile. If you have combined keys and certs, then they haven't been generated by the rpm-helper. I note that this issue (alignment of config file with changed behaviour of the helper script) was fixed for Mageia 2. I don't see much point in pushing an update for this, as by now, anyone running OpenLDAP on mga1 would have fixed this.
(In reply to comment #2) > I note that this issue (alignment of config file with changed behaviour of the > helper script) was fixed for Mageia 2. So, since my ldap.pem files were generated from MDV 2010.2, only the private ones work, but if they had been generated from Mageia (1 or 2), the certs ones would work as configured by default in Mageia 2? If that's the case, then yes I don't think anything else needs to be done, other than maybe documenting this somewhere more obvious (the changes to the helper script probably should have been described in README.urpmi), but it's not a big deal by this point.
The default config file has been updated in Mageia 1 svn (r269079) to match the correct locations used by the rpm helper script. I don't know if documentation (e.g. README.urpmi) is warranted, as only users upgrading from Mandriva would be affected (assuming users on Mageia 1 had resolved by updating the locations in slapd.conf, rather than moving certs).
(In reply to comment #4) > The default config file has been updated in Mageia 1 svn (r269079) to match the > correct locations used by the rpm helper script. > > I don't know if documentation (e.g. README.urpmi) is warranted, as only users > upgrading from Mandriva would be affected (assuming users on Mageia 1 had > resolved by updating the locations in slapd.conf, rather than moving certs). Well, changing the default config file in Mageia 1 would just move the problem from Mageia 2 back to Mageia 1, which is fine, but if we do ship that later as an update, it would be really good if it had a README.urpmi explaining the changes. Since there doesn't seem to be anyway to get openldap to give a meaningful error message about the problem, it's kind of hard to fix if you don't know what the issue is.
This message is a reminder that Mageia 1 is nearing its end of life. In approximately 25 days from now, Mageia will stop maintaining and issuing updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '1'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 1's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 1 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- Mageia Bugsquad
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => WONTFIX