man ldap.conf says:
"never The client will not request or check any server certificate."
It seems that never means it will never check any server certificate (even if given one). I'm assuming there are no exceptions here and that "never" really does mean "never".
Back to the version I'm using, which is 2.2.17. If Howard Chu is correct, this functionality should be in my version ... if the functionality was added in April 2003 ... because 2.2.17 was released in Sep 2004. Or was that date wrong? I tried looking at the versions 1, 2, and 3 CHANGES files, and I couldn't pin down when it was added.
I'm looking for either (1) my version is definately too old and it simply does not have this functionality, or (2) I'm doing something wrong, and what I need to do to fix it is XYZ.
Thanks, - Jeremiah
On 10/18/06, Dieter Kluenter dieter@dkluenter.de wrote:
"Jeremiah Martell" inlovewithgod@gmail.com writes:
Dieter,
Thanks for the response. However, why should I have to do this if I have "TLS_REQCERT never" in my ldap.conf file? Shouldn't that mean openldap doesn't request, check, verify, etc any certificates?
Right, the client does not request for a certificate, but if the server presents one, it of course is beeing checked, man ldap.conf(5) and man slapd.conf(5)
-Dieter
-- Dieter Klünter | Systemberatung http://www.dkluenter.de N 53°37'10.08" E 10°08'02.82" GPG Key ID:8EF7B6C6
Jeremiah Martell wrote:
man ldap.conf says:
"never The client will not request or check any server certificate."
It seems that never means it will never check any server certificate (even if given one). I'm assuming there are no exceptions here and that "never" really does mean "never".
Back to the version I'm using, which is 2.2.17. If Howard Chu is correct, this functionality should be in my version ... if the functionality was added in April 2003 ... because 2.2.17 was released in Sep 2004. Or was that date wrong?
April 2003 was the date the patch went into HEAD. It may have gone into a public release at a much later date, I didn't bother to check. The 2.2.x release series was moved to Historic status quite a while ago; if you're using something that old you're on your own. Nobody on the Project cares about what may or may not be true of dead code. You can compare the CVS logs if you want to know, but if you expect to get help from this mailing list you should use a current version of the code.
On Thu, 19 Oct 2006, Howard Chu wrote:
April 2003 was the date the patch went into HEAD. It may have gone into a public release at a much later date, I didn't bother to check. The 2.2.x release series was moved to Historic status quite a while ago; if you're using something that old you're on your own. Nobody on the Project cares about what may or may not be true of dead code. You can compare the CVS logs if you want to know, but if you expect to get help from this mailing list you should use a current version of the code.
None the less in order to maintain support from the paid for vendor (as *politically* required) some of us do maintain systems with this and even older openldap versions. Unfortunately some of us live in worlds where what we should do and what we are required to do diverge. Perhaps a mailing list for historic version support might be an idea?
At any rate I can say that load balancers with SSL do work even on 2.0.27 (as that is what our current cluster of ldap servers are).
When you create the certificate simpley make the hostname in the cert the hostname of the cluster IP for your load balancer, then add the real server name as the subjectAltName of the certificate. This will allow you to replicate over SSL to the real server name (on the private network) and still query the cluster hostname with SSL and not get certificate errors.
Jeremiah, if you still have problems, send me privately the output from an ldap search using the command line
ldapsearch -Z -d1 ...(rest of your options)...
This should help in determining what the issue with SSL is.
Regards James
At 09:28 AM 10/19/2006, James Bourne wrote:
Perhaps a mailing list for historic version support might be an idea?
Discussion of historic versions of OpenLDAP Software are on-topic here. Howard was stating the reality that many subscribers of this list choose not offer support for historic versions of OpenLDAP Software. His statement shouldn't be taken as precluding those inclined to offer such support from doing so.
However, it should be noted that discussion specific to 3rd party packages of OpenLDAP Software are generally considered off-topic. Such discussions should be directed to a forum provided by that 3rd party or, if none, directed to that 3rd party.
Kurt
James Bourne wrote:
On Thu, 19 Oct 2006, Howard Chu wrote:
April 2003 was the date the patch went into HEAD. It may have gone into a public release at a much later date, I didn't bother to check. The 2.2.x release series was moved to Historic status quite a while ago; if you're using something that old you're on your own. Nobody on the Project cares about what may or may not be true of dead code. You can compare the CVS logs if you want to know, but if you expect to get help from this mailing list you should use a current version of the code.
None the less in order to maintain support from the paid for vendor (as *politically* required) some of us do maintain systems with this and even older openldap versions. Unfortunately some of us live in worlds where what we should do and what we are required to do diverge. Perhaps a mailing list for historic version support might be an idea?
If you're getting support from a paid-for vendor, then GO GET SUPPORT FROM YOUR PAID-FOR VENDOR. I presume that's actually what you're paying them for.
At any rate I can say that load balancers with SSL do work even on 2.0.27 (as that is what our current cluster of ldap servers are).
Yes of course, they work perfectly well when you create certificates that adhere to the published specs. (E.g. RFC 2830, or RFC 4513 which supersedes that.) The use of subjectAltName was already pointed out in this discussion multiple times so either the original poster is just ignoring that advice, or has some other unknown reason to continue beating this dead horse.
On Thu, 19 Oct 2006, Howard Chu wrote:
Yes of course, they work perfectly well when you create certificates that adhere to the published specs. (E.g. RFC 2830, or RFC 4513 which supersedes that.) The use of subjectAltName was already pointed out in this discussion multiple times so either the original poster is just ignoring that advice, or has some other unknown reason to continue beating this dead horse.
This is in the FAQ isn't it?
Regards James
James Bourne wrote:
At any rate I can say that load balancers with SSL do work even on 2.0.27 (as that is what our current cluster of ldap servers are).
When you create the certificate simpley make the hostname in the cert the hostname of the cluster IP for your load balancer, then add the real server name as the subjectAltName of the certificate. This will allow you to replicate over SSL to the real server name (on the private network) and still query the cluster hostname with SSL and not get certificate errors.
This is in the FAQ isn't it?
It probably is, why don't you look? Add it yourself if it's missing, that's what the FAQ-o-Matic is for.
Anyway, as I wrote in the Admin Guide, http://www.openldap.org/doc/admin23/tls.html you should use the real hostname as the CN of the cert DN, and put the cluster name in as an alias. Opposite of what you suggested. Ultimately it works either way.
openldap-software@openldap.org
-
Howard Chu -
James Bourne -
Jeremiah Martell -
Kurt D. Zeilenga