For future reference, here is what I had to do to get multiple LDAP servers answering on the same DNS address and using TLS.
The DNS contains this records: srv1 IN A 192.0.2.4 srv2 IN A 192.0.2.5 ldap 1 IN A 192.0.2.4 ldap 1 IN A 192.0.2.5
The clients have this in ldap.conf: BASE dc=example,dc=net TLS_CACERT /etc/openssl/certs/ca.crt URI ldaps://ldap.example.net:636 TLS_REQCERT demand # Cannot get this working! #TLS_CRLCHECK peer
# For login/password over TLS SASL_MECH PLAIN SASL_SECPROPS none
In order to have this working, we need x509 certificate that have the subjectAltName extension. This is not an OpenLDAP-specific problem, but the information about how to do it seems difficult to find, hence, here is the result of my experiments.
1) Creating a CSR On the LDAP servers, we need to setup OpenSSL for generating the certificate request (CSR). We need this in the [ req ] section of /etc/openssl/openssl.cnf: req_extensions = v3_req
The, we need a [ v3_req ] section: [ v3_req ] basicConstraints = CA:FALSE subjectAltName = "DNS:ldap.example.net, DNS:srv1.example.net"
It seems the subjectAltName has to be set in the config file. I found no way to have it prompted by the openssl command.
If you don't have a private key yet, generate it: # ( umask 077; openssl genrsa > /etc/openssl/private/srv1.key )
Next, make the CSR: # openssl req -new -key /etc/openssl/private/srv1.key -out srv1.csr Answers to the questions openssl ask. The common name is srv1.example.net
Of course the same must be done on srv2
2) Signing the certificate On the machine that holds your certificate authority, some setup is also needed in openssl.cnf:
In the [ CA_default ] section (or in [ ca ]), copy_extensions = copy
Note that this will copy any extensions, so you have to be careful about what you are signing. See the WARNINGS section of openssl_ca.
Sign it (I assume your CA setup already work, here) # openssl ca -key /etc/openssl/private/ca.crt -in srv1.csr -out src1.crt # openssl ca -key /etc/openssl/private/ca.crt -in srv2.csr -out src2.crt
3) Configuring slapd Install ca.crt and srv1.crt (srv2.crt) on srv1 (srv2), and configure slapd, with this in slapd.conf: TLSCertificateFile /etc/openssl/certs/srv1.crt TLSCertificateKeyFile /etc/openssl/private/srv1.key TLSCACertificateFile /etc/openssl/certs/ca.crt TLSVerifyClient allow sasl-secprops none
Then, restart slapd, and the thing should work.
4) Having this working with syncrepl
An add-on: now let's imagine srv1 and srv2 are syncrepl-powered replica. The master is ldap0.example.net. In order to avoid pushing sensitive data to a rogue machine that would claim being a replica, we want to use client and server TLS certificate authentication for syncrepl exchange.
Note that on the consumer, the same certificate must be used for syncrepl and for the ldaps:// service. This is alimitation in OpenLDAP 2.3.x
4.1) On the syncrepl consumer (srv1 and srv2), in slapd.conf: syncrepl rid=24 type=refreshAndPersist searchbase="dc=example,dc=net" starttls=critical bindmethod=sasl saslmech=EXTERNAL retry=3,1,10,2,60,+
Make sure rid is different on srv1 and srv2. Don't forget to add entryUUID and entryCSN to the index of your databases (see http://www.openldap.org/doc/admin23/syncrepl.html#Configuring%20Syncrepl)
4.2) On the syncrepl producer (ldap0), in slapd.conf: TLSCertificateFile /etc/openssl/certs/ldao0.crt TLSCertificateKeyFile /etc/openssl/private/ldap0.crt TLSCACertificateFile /etc/openssl/certs/ca.crt TLSVerifyClient allow
# This allows login/password protected by TLS (for users) sasl-secprops none
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
# ACL to allow syncrepl consumer to get userPassword through TLS session # while regular users will not be able to see them access to attrs=userPassword by anonymous auth by self write by dn.regex="cn=srv1.example.net" read by dn.regex="cn=srv2.example.net" read by * none
access to * by * read
-- Emmanue Dreyfus manu@netbsd.org
--On July 23, 2007 1:51:19 PM +0000 Emmanuel Dreyfus manu@netbsd.org wrote:
For future reference, here is what I had to do to get multiple LDAP servers answering on the same DNS address and using TLS.
The clients have this in ldap.conf: BASE dc=example,dc=net TLS_CACERT /etc/openssl/certs/ca.crt URI ldaps://ldap.example.net:636 TLS_REQCERT demand # Cannot get this working! # TLS_CRLCHECK peer
Just note that using SSL over port 636 is not a defined protocol, and may go away in the future. Avoidance of its use when possible recommended.
- Having this working with syncrepl
4.1) On the syncrepl consumer (srv1 and srv2), in slapd.conf: syncrepl rid=24 type=refreshAndPersist searchbase="dc=example,dc=net" starttls=critical bindmethod=sasl saslmech=EXTERNAL retry=3,1,10,2,60,+
Make sure rid is different on srv1 and srv2.
RID only needs to be unique inside a single configuration (i.e., for a single slapd instance). Both your replicas could use the same RID.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount quanah@zimbra.com wrote:
Just note that using SSL over port 636 is not a defined protocol, and may go away in the future. Avoidance of its use when possible recommended.
I have this in /etc/services: ldaps 636/tcp ldap protocol over TLS/SSL (was sldap)
And checking the authoritative source confirms it's registered. http://www.iana.org/assignments/port-numbers
So what's wrong with LDAP/SSL over port 636?
Make sure rid is different on srv1 and srv2.
RID only needs to be unique inside a single configuration (i.e., for a single slapd instance). Both your replicas could use the same RID.
I wasn't aware, thank you for the comment.
--On July 23, 2007 10:09:33 PM +0200 Emmanuel Dreyfus manu@netbsd.org wrote:
Quanah Gibson-Mount quanah@zimbra.com wrote:
Just note that using SSL over port 636 is not a defined protocol, and may go away in the future. Avoidance of its use when possible recommended.
I have this in /etc/services: ldaps 636/tcp ldap protocol over TLS/SSL (was sldap)
And checking the authoritative source confirms it's registered. http://www.iana.org/assignments/port-numbers
So what's wrong with LDAP/SSL over port 636?
It is not defined by any RFC, it is simply a hack that was put in to address an issue with LDAPv2. LDAPv3 implements the RFC defined STARTTLS operation (RFC 2830). Just because it is registered with iana doesn't mean it is something that's been truly defined. As such, it faces the possibility of disappearing in the future.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
manu@netbsd.org (Emmanuel Dreyfus) writes:
Quanah Gibson-Mount quanah@zimbra.com wrote:
Just note that using SSL over port 636 is not a defined protocol, and may go away in the future. Avoidance of its use when possible recommended.
I have this in /etc/services: ldaps 636/tcp ldap protocol over TLS/SSL (was sldap)
And checking the authoritative source confirms it's registered. http://www.iana.org/assignments/port-numbers
So what's wrong with LDAP/SSL over port 636?
There is a general trend for all IETF protocols away from using TLS on a separate port and towards using the standard port and STARTTLS. Allocating a second port for every major protocol, one with TLS and one without, was becoming wasteful of additional ports and there's no need for it given STARTTLS.
Quanah,
Quanah Gibson-Mount wrote:
Just note that using SSL over port 636 is not a defined protocol, and may go away in the future. Avoidance of its use when possible recommended.
- IMO StartTLS ext. op. is flawed because there's no way to mandate the use of it before a misbehaving LDAP client has a chance to send credentials on the wire. - Also StartTLS ext. op. is rarely supported by LDAP clients.
=> If the OpenLDAP developers were really crazy enough to remove support for LDAPS from OpenLDAP I'd kick OpenLDAP out of my business immediately. Period.
Ciao, Michael.
Michael Ströder wrote:
Quanah,
Quanah Gibson-Mount wrote:
Just note that using SSL over port 636 is not a defined protocol, and may go away in the future. Avoidance of its use when possible recommended.
- IMO StartTLS ext. op. is flawed because there's no way to mandate the
use of it before a misbehaving LDAP client has a chance to send credentials on the wire.
I agree. But it's too late to fix this in LDAPv3.
- Also StartTLS ext. op. is rarely supported by LDAP clients.
True, but I don't see that we have any influence over that.
=> If the OpenLDAP developers were really crazy enough to remove support for LDAPS from OpenLDAP I'd kick OpenLDAP out of my business immediately. Period.
If someone at IANA were to tell us that this number assignment was officially withdrawn, then we would drop it. We really wouldn't have much choice, nor would any other implementor that wanted to claim that their LDAP product was fully IETF-compliant.
Howard Chu wrote:
Michael Ströder wrote:
=> If the OpenLDAP developers were really crazy enough to remove support for LDAPS from OpenLDAP I'd kick OpenLDAP out of my business immediately. Period.
If someone at IANA were to tell us that this number assignment was officially withdrawn, then we would drop it. We really wouldn't have much choice, nor would any other implementor that wanted to claim that their LDAP product was fully IETF-compliant.
Sorry, but the assignment of a port number by IANA is not really required for supporting LDAP over SSL/TLS on a separate port since you could happily use ldaps://host:636 or any other port anyway and still be IETF-compliant.
Ciao, Michael.
Howard Chu hyc@symas.com writes:
If someone at IANA were to tell us that this number assignment was officially withdrawn, then we would drop it. We really wouldn't have much choice, nor would any other implementor that wanted to claim that their LDAP product was fully IETF-compliant.
Thankfully, it's pretty unlikely this will happen any time soon. There are still free low-numbered ports, the whole low-numbered port thing is becoming less of an issue, and even among the assignments, there are ones that are far more obscure and less used than ldaps.
On Mon, Jul 23, 2007 at 01:51:19PM +0000, Emmanuel Dreyfus wrote:
In order to have this working, we need x509 certificate that have the subjectAltName extension. This is not an OpenLDAP-specific problem, but the information about how to do it seems difficult to find, hence, here is the result of my experiments.
- Creating a CSR
On the LDAP servers, we need to setup OpenSSL for generating the certificate request (CSR). We need this in the [ req ] section of /etc/openssl/openssl.cnf: req_extensions = v3_req
The, we need a [ v3_req ] section: [ v3_req ] basicConstraints = CA:FALSE subjectAltName = "DNS:ldap.example.net, DNS:srv1.example.net"
I actually found that I could use the following: [ dev_ldap ] subjectAltName=DNS:ldap.example.com basicConstraints=CA:FALSE
I then used 'srv1.example.net' as the CN for the certificate. The OpenSSL libraries were quite happy with this; I can refer to the host as ldap.example.com or srv1.example.com and certificate verification will succeed.
Then, to sign, I use `openssl ca -extensions dev_ldap -in srv1.csr \ -out srv1.crt'.
This allowed me to use the 'dev_ldap' extension set only for my development config while issuing all other certificates fell back to the 'v3_req' default configuration. It also seems cleaner to me to only specify the actual alternate name in the AltName field.
It seems the subjectAltName has to be set in the config file. I found no way to have it prompted by the openssl command.
This was my experience too.
Emmanuel Dreyfus wrote:
For future reference, here is what I had to do to get multiple LDAP servers answering on the same DNS address and using TLS.
The DNS contains this records: srv1 IN A 192.0.2.4 srv2 IN A 192.0.2.5 ldap 1 IN A 192.0.2.4 ldap 1 IN A 192.0.2.5
The clients have this in ldap.conf: BASE dc=example,dc=net TLS_CACERT /etc/openssl/certs/ca.crt URI ldaps://ldap.example.net:636 TLS_REQCERT demand # Cannot get this working! #TLS_CRLCHECK peer
This only works with recent OpenSSL 0.9.8 releases. You didn't mention which version of OpenSSL you're using. And since this entire subject is purely an OpenSSL matter and not an LDAP matter, that's a pretty key piece of information.
In order to have this working, we need x509 certificate that have the subjectAltName extension. This is not an OpenLDAP-specific problem, but the information about how to do it seems difficult to find, hence, here is the result of my experiments.
The information is all at your fingertips. You just haven't absorbed it yet.
- Creating a CSR
On the LDAP servers, we need to setup OpenSSL for generating the certificate request (CSR). We need this in the [ req ] section of /etc/openssl/openssl.cnf: req_extensions = v3_req
The, we need a [ v3_req ] section: [ v3_req ] basicConstraints = CA:FALSE subjectAltName = "DNS:ldap.example.net, DNS:srv1.example.net"
It seems the subjectAltName has to be set in the config file. I found no way to have it prompted by the openssl command.
No, but you can obtain the value through an environment variable, to avoid having to re-edit the file all the time. Again, this is documented in the OpenSSL config file manpage. http://www.openssl.org/docs/apps/config.html#
e.g. setenv ALTNAME "DNS:ldap.example.net"
### subjectAltName=$ENV::ALTNAME ###
Also note "subject alternative name" means exactly that - it lists *alternative* names for the identity. You don't have to list the real name here, since that's already going into the subject CN. It does no harm, but it does no good either. (And it makes your cert bigger than it needs to be...)
If you don't have a private key yet, generate it: # ( umask 077; openssl genrsa > /etc/openssl/private/srv1.key )
Next, make the CSR: # openssl req -new -key /etc/openssl/private/srv1.key -out srv1.csr Answers to the questions openssl ask. The common name is srv1.example.net
Of course the same must be done on srv2
- Signing the certificate
On the machine that holds your certificate authority, some setup is also needed in openssl.cnf:
In the [ CA_default ] section (or in [ ca ]), copy_extensions = copy
Note that this will copy any extensions, so you have to be careful about what you are signing. See the WARNINGS section of openssl_ca.
Sign it (I assume your CA setup already work, here) # openssl ca -key /etc/openssl/private/ca.crt -in srv1.csr -out src1.crt # openssl ca -key /etc/openssl/private/ca.crt -in srv2.csr -out src2.crt
Typo there, src1.crt should be srv1.crt. Likewise for src2/srv2. Pay attention to what you're doing.
- Configuring slapd
Install ca.crt and srv1.crt (srv2.crt) on srv1 (srv2), and configure slapd, with this in slapd.conf: TLSCertificateFile /etc/openssl/certs/srv1.crt TLSCertificateKeyFile /etc/openssl/private/srv1.key TLSCACertificateFile /etc/openssl/certs/ca.crt TLSVerifyClient allow sasl-secprops none
Setting "sasl-secprops none" is never a good idea. Why did you put this here?
Then, restart slapd, and the thing should work.
- Having this working with syncrepl
An add-on: now let's imagine srv1 and srv2 are syncrepl-powered replica. The master is ldap0.example.net. In order to avoid pushing sensitive data to a rogue machine that would claim being a replica, we want to use client and server TLS certificate authentication for syncrepl exchange.
Note that on the consumer, the same certificate must be used for syncrepl and for the ldaps:// service. This is alimitation in OpenLDAP 2.3.x
4.1) On the syncrepl consumer (srv1 and srv2), in slapd.conf: syncrepl rid=24 type=refreshAndPersist searchbase="dc=example,dc=net" starttls=critical bindmethod=sasl saslmech=EXTERNAL retry=3,1,10,2,60,+
Make sure rid is different on srv1 and srv2.
As already noted by others, rid only needs to be unique within a single slapd configuration.
Don't forget to add entryUUID and entryCSN to the index of your databases (see http://www.openldap.org/doc/admin23/syncrepl.html#Configuring%20Syncrepl)
4.2) On the syncrepl producer (ldap0), in slapd.conf: TLSCertificateFile /etc/openssl/certs/ldao0.crt TLSCertificateKeyFile /etc/openssl/private/ldap0.crt TLSCACertificateFile /etc/openssl/certs/ca.crt TLSVerifyClient allow
# This allows login/password protected by TLS (for users) sasl-secprops none
No, that's not what it does. It turns off all security requirements in the SASL layer, allowing all insecure mechanisms to be used. A rather big mistake, after you've gone to the trouble of enabling secure authentication with certificates.
On Mon, Jul 23, 2007 at 09:58:37PM -0700, Howard Chu wrote:
# Cannot get this working! #TLS_CRLCHECK peer
This only works with recent OpenSSL 0.9.8 releases. You didn't mention which version of OpenSSL you're using. And since this entire subject is purely an OpenSSL matter and not an LDAP matter, that's a pretty key piece of information.
I used 0.9.7d. That information (a minimal version of OpenSSL is required for it to work) is quite important. Where was I supposed to find it? I've lost a few hours trying to get CRLworking, I'd have been better reading the right document.
In order to have this working, we need x509 certificate that have the subjectAltName extension. This is not an OpenLDAP-specific problem, but the information about how to do it seems difficult to find, hence, here is the result of my experiments.
The information is all at your fingertips. You just haven't absorbed it yet.
I beleive the information (which exists, I agree) is not very well oriented for the newcomer that tries to set up a new configuration.
Also note "subject alternative name" means exactly that - it lists *alternative* names for the identity. You don't have to list the real name here, since that's already going into the subject CN. It does no harm, but it does no good either. (And it makes your cert bigger than it needs to be...)
Thanks for that hint.
Install ca.crt and srv1.crt (srv2.crt) on srv1 (srv2), and configure slapd, with this in slapd.conf: TLSCertificateFile /etc/openssl/certs/srv1.crt TLSCertificateKeyFile /etc/openssl/private/srv1.key TLSCACertificateFile /etc/openssl/certs/ca.crt TLSVerifyClient allow sasl-secprops none
Setting "sasl-secprops none" is never a good idea. Why did you put this here?
I have users using plaintext login/password through TLS. Those are validated through SASL. As I understood, using plaintext password requires "sasl-secprops none", is that wrong?
No, that's not what it does. It turns off all security requirements in the SASL layer, allowing all insecure mechanisms to be used. A rather big mistake, after you've gone to the trouble of enabling secure authentication with certificates.
In my setup, the syncrepl consumer uses certificate and gets sensitive information such as userPassword. Users can use plaintext password over TLS and cannot get password hashes. Is it that odd?
Emmanuel Dreyfus wrote:
On Mon, Jul 23, 2007 at 09:58:37PM -0700, Howard Chu wrote:
# Cannot get this working! #TLS_CRLCHECK peer
This only works with recent OpenSSL 0.9.8 releases. You didn't mention which version of OpenSSL you're using. And since this entire subject is purely an OpenSSL matter and not an LDAP matter, that's a pretty key piece of information.
I used 0.9.7d. That information (a minimal version of OpenSSL is required for it to work) is quite important. Where was I supposed to find it? I've lost a few hours trying to get CRLworking, I'd have been better reading the right document.
When you run OpenLDAP's configure script you will see:
checking OpenSSL library version (CRL checking capability)... no
indicating that your OpenSSL library doesn't support it. Otherwise I suppose you would see in your OpenSSL release notes/docs.
Install ca.crt and srv1.crt (srv2.crt) on srv1 (srv2), and configure slapd, with this in slapd.conf: TLSCertificateFile /etc/openssl/certs/srv1.crt TLSCertificateKeyFile /etc/openssl/private/srv1.key TLSCACertificateFile /etc/openssl/certs/ca.crt TLSVerifyClient allow sasl-secprops none
Setting "sasl-secprops none" is never a good idea. Why did you put this here?
I have users using plaintext login/password through TLS. Those are validated through SASL. As I understood, using plaintext password requires "sasl-secprops none", is that wrong?
No, that's not what it does. It turns off all security requirements in the SASL layer, allowing all insecure mechanisms to be used. A rather big mistake, after you've gone to the trouble of enabling secure authentication with certificates.
In my setup, the syncrepl consumer uses certificate and gets sensitive information such as userPassword. Users can use plaintext password over TLS and cannot get password hashes. Is it that odd?
You posted your email as if it was a general solution for anybody trying to solve the aliased server name problem for TLS certificates. This part of your config is not part of that general solution, it is specific to your deployment. In particular, the sasl-secprops setting is a global option and affects all connections, whether they use TLS or not. As such, you are allowing users to use login/plain over cleartext connections as well as TLS connections. You might have taken precautions against this in the other parts of your slapd.conf (using the security directive) but you didn't indicate those precautions anywhere in what you posted. So you will mislead anyone following your advice into leaving their servers quite vulnerable.
If you've actually got information in your directory that you've gone to the trouble of protecting with TLS, you should never allow plaintext authentication mechanisms. Use CRAM-MD5 at least.
Howard Chu hyc@symas.com wrote:
When you run OpenLDAP's configure script you will see:
checking OpenSSL library version (CRL checking capability)... no
indicating that your OpenSSL library doesn't support it. Otherwise I suppose you would see in your OpenSSL release notes/docs.
Yes, I discovered HAVE_OPENSSL_CRL. The problem is that this test validates at mine, despite OpenSSL version (0.9.7d)
configure:19757: checking OpenSSL library version (CRL checking capability) configure:19791: result: yes
And then if I use TLS_CRLCHECK, LDAP operation will fail:
ldap_bind: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
I hope you'll agree with me that this is *very* misleading if CRL checks are not supposed to work with 0.9.7d.
You posted your email as if it was a general solution for anybody trying to solve the aliased server name problem for TLS certificates.
Quoting myself: "here is the result of my experiments"
I wouldn't call that a claim of being an authoritative guide. I posted it there with the hope it could be useful to other looking for the piece of information I missed. It was not perfect, but that's not a problem, since you and other kindly pointed out the errors. If you don't discourage me too much, I may even post an update with your comments included.
This part of your config is not part of that general solution, it is specific to your deployment. In particular, the sasl-secprops setting is a global option and affects all connections, whether they use TLS or not. As such, you are allowing users to use login/plain over cleartext connections as well as TLS connections. You might have taken precautions against this in the other parts of your slapd.conf (using the security directive)
Yes, I have this. Is it fine? security simple_bind=128
but you didn't indicate those precautions anywhere in what you posted. So you will mislead anyone following your advice into leaving their servers quite vulnerable.
I hope people do some testing before rolling a copy/pasted configuration in production...
--On Tuesday, July 24, 2007 9:18 PM +0200 Emmanuel Dreyfus manu@netbsd.org wrote:
but you didn't indicate those precautions anywhere in what you posted. So you will mislead anyone following your advice into leaving their servers quite vulnerable.
I hope people do some testing before rolling a copy/pasted configuration in production...
Experience shows they generally don't. Your posts will likely show up now in google searches by people who aren't really interested in going and actually reading documentation, and/or end up in some forsaken "how-to". :/ It happens often. I periodically troll google searches of ldap how-to's and ask people to either take them down or fix them, depending on how incorrect they are. Sometimes, the people are even responsible enough to fix them.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Wed, Jul 25, 2007 at 08:53:22AM -0700, Quanah Gibson-Mount wrote:
I hope people do some testing before rolling a copy/pasted configuration in production...
Experience shows they generally don't. Your posts will likely show up now in google searches by people who aren't really interested in going and actually reading documentation, and/or end up in some forsaken "how-to". :/
I hope so. I have been googling for a starting point without much success, hence the desire to add some information. Indeed iit's not perfect, but it's just a post in a mailing list, it's not a FAQ entry. And since people point out the mistakes in the thread, the curious reader should have everything needed at hand to succeed.
What do you prefer? 1) The beginner find hardly no information, gives up after 2 days of failures, and will claim everywhere that OpenLDAP is the most frustrating software he had to deal with
or
2) It finds some hints with follow-up comments and can either screw his setup by just copy/pasting without a though, or read the thread and find the missing pieces he needs by himself.
--On Wednesday, July 25, 2007 4:07 PM +0000 Emmanuel Dreyfus manu@netbsd.org wrote:
On Wed, Jul 25, 2007 at 08:53:22AM -0700, Quanah Gibson-Mount wrote:
I hope people do some testing before rolling a copy/pasted configuration in production...
Experience shows they generally don't. Your posts will likely show up now in google searches by people who aren't really interested in going and actually reading documentation, and/or end up in some forsaken "how-to". :/
I hope so. I have been googling for a starting point without much success, hence the desire to add some information. Indeed iit's not perfect, but it's just a post in a mailing list, it's not a FAQ entry. And since people point out the mistakes in the thread, the curious reader should have everything needed at hand to succeed.
What do you prefer?
- The beginner find hardly no information, gives up after 2 days of
failures, and will claim everywhere that OpenLDAP is the most frustrating software he had to deal with
As pointed out by Howard multiple times, nearly everything you "couldn't find" was actually available online, in the form of published documentation, by the folks who provided the software. The fact that you went to Google *before* going to the sites that actually distribute the software and reading their documentation is unfortunately the same thing many other people do to. And then they tend to complain about the lack of documentation.
- It finds some hints with follow-up comments and can either screw his
setup by just copy/pasting without a though, or read the thread and find the missing pieces he needs by himself.
They'll screw up their set up, and then they'll send barages of email asking why things didn't work, because they expect it to work the first time, and then they'll go around claming that OpenLDAP or some other software is the most frustrating software to deal with because they get told to actually go read the documentation.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount quanah@zimbra.com wrote:
As pointed out by Howard multiple times, nearly everything you "couldn't find" was actually available online, in the form of published documentation, by the folks who provided the software.
If you speak about the subjectAltName stuff, there is IMO a huge gap getween OpenSSL reference documentation and how to actually do it. The information is there, but there is a lot of required reading if you want to do something. And there are a lot of mistake to do before getting it done (cf my first attempt with subjectAltName outside the extension section)
The fact that you went to Google *before* going to the sites that actually distribute the software and reading their documentation is unfortunately the same thing many other people do to. And then they tend to complain about the lack of documentation.
Okay, so that could surprise you, but I actually started by searching the OpenLDAP doc and FAQ. Then the OpenSSL web site, then Google...
That item is worth an OpenLDAP FAQ entry IMO, even if it's not really an OpenLDAP problem. How one contribute FAQ entries, BTW? I just add it to Faq-O-Matic?
--On Wednesday, July 25, 2007 7:36 PM +0200 Emmanuel Dreyfus manu@netbsd.org wrote:
Okay, so that could surprise you, but I actually started by searching the OpenLDAP doc and FAQ. Then the OpenSSL web site, then Google...
That item is worth an OpenLDAP FAQ entry IMO, even if it's not really an OpenLDAP problem. How one contribute FAQ entries, BTW? I just add it to Faq-O-Matic?
Yep, anyone can write FAQ entries.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Emmanuel Dreyfus wrote:
Quanah Gibson-Mount quanah@zimbra.com wrote:
As pointed out by Howard multiple times, nearly everything you "couldn't find" was actually available online, in the form of published documentation, by the folks who provided the software.
If you speak about the subjectAltName stuff, there is IMO a huge gap getween OpenSSL reference documentation and how to actually do it. The information is there, but there is a lot of required reading if you want to do something. And there are a lot of mistake to do before getting it done (cf my first attempt with subjectAltName outside the extension section)
Since it is an OpenSSL topic, it would make the most sense for you to submit some suggested doc changes to the OpenSSL team. Though I suspect that in the 7 or so years that OpenLDAP has supported OpenSSL, many people have been confronted with this problem, read the docs, and implemented the solution and moved on to the next thing, without any fuss. As such, the relative ease with which the problem is typically solved doesn't merit a writeup for Google to find.
It may just mean there is a language barrier, something that would better be served by a translation of OpenSSL docs into French.
The fact that you went to Google *before* going to the sites that actually distribute the software and reading their documentation is unfortunately the same thing many other people do to. And then they tend to complain about the lack of documentation.
Okay, so that could surprise you, but I actually started by searching the OpenLDAP doc and FAQ. Then the OpenSSL web site, then Google...
That item is worth an OpenLDAP FAQ entry IMO, even if it's not really an OpenLDAP problem. How one contribute FAQ entries, BTW? I just add it to Faq-O-Matic?
Yes, anybody can add entries to the FAQ (hasn't that been said enough times already?), and you're welcome to add your corrected writeup there.
Howard Chu hyc@symas.com wrote:
Though I suspect that in the 7 or so years that OpenLDAP has supported OpenSSL, many people have been confronted with this problem, read the docs, and implemented the solution and moved on to the next thing, without any fuss.
I am not sure I'm the only one that have the feeling he has lost too many time to bring the parts together for a recurrent usage that could have been better documented. Feedback from other users would be interesting.
It may just mean there is a language barrier, something that would better be served by a translation of OpenSSL docs into French.
So in your opinion, I'm basically compaining because I can't read english? This is getting rude. :-/
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
Though I suspect that in the 7 or so years that OpenLDAP has supported OpenSSL, many people have been confronted with this problem, read the docs, and implemented the solution and moved on to the next thing, without any fuss.
I am not sure I'm the only one that have the feeling he has lost too many time to bring the parts together for a recurrent usage that could have been better documented. Feedback from other users would be interesting.
It may just mean there is a language barrier, something that would better be served by a translation of OpenSSL docs into French.
So in your opinion, I'm basically compaining because I can't read english? This is getting rude. :-/
It seems to me that you cannot read what is plainly in front of your face, for whatever reason. The fact that you can use environment variables to augment the OpenSSL configuration file is clearly documented at the top of the OpenSSL config(5) manual page. The use of "subjectAltName" has multiple examples in the default openssl.cnf file that is bundled with every OpenSSL release. The meaning of the word "alternative" in subjectAlternativeName is plain English, and again even the OpenLDAP Admin Guide says "Additional alias names and wildcards may be present in the subjectAltName certificate extension." The FAQ-o-Matic is pretty explicit too.
http://www.openldap.org/doc/admin23/tls.html#TLS%20Certificates http://www.openldap.org/faq/index.cgi?file=185
Yet despite all the work you've put into this you've missed all of these very obvious things.
Your initial assertion that the documentation for this topic is hidden or unavailable is clearly wrong. You assertion that it is in general difficult to understand doesn't seem well supported either; googling for "subjectaltname openldap" returns hundreds of hits. So it falls to just the fact that you had a hard time understanding it.
Howard Chu hyc@symas.com wrote:
This is getting rude. :-/
It seems to me that you cannot read what is plainly in front of your face, for whatever reason.
While I acknowledge the quality of your work on the OpenLDAP project, I suspect you still have some progress to make when talking with users. You are turning this discussion about the obviousness of some obscure toptic into personnal attacks, and I won't follow up.
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
This is getting rude. :-/
It seems to me that you cannot read what is plainly in front of your face, for whatever reason.
While I acknowledge the quality of your work on the OpenLDAP project, I suspect you still have some progress to make when talking with users. You are turning this discussion about the obviousness of some obscure toptic into personnal attacks, and I won't follow up.
I don't know you well enough to get personal, nor do I have anything to gain from making an attack. I am simply debugging - you've drawn attention to a difficulty that apparently no one else is having. My only interest on this list is in identifying root causes of problems, nothing more.
On Tuesday 24 July 2007 21:18, Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
When you run OpenLDAP's configure script you will see:
checking OpenSSL library version (CRL checking capability)... no
indicating that your OpenSSL library doesn't support it. Otherwise I suppose you would see in your OpenSSL release notes/docs.
Yes, I discovered HAVE_OPENSSL_CRL. The problem is that this test validates at mine, despite OpenSSL version (0.9.7d)
configure:19757: checking OpenSSL library version (CRL checking capability) configure:19791: result: yes
And then if I use TLS_CRLCHECK, LDAP operation will fail:
ldap_bind: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
I hope you'll agree with me that this is *very* misleading if CRL checks are not supposed to work with 0.9.7d.
They should work with 0.9.7d. IIRC that was the version I used when implementing CRL support. Note: As stated in the man-pages (ldap.conf(5) and slapd.conf(5)), when you want to use CRLs you have to specify a CACERTDIR. That directory has to be correctly hashed (using c_rehash).
Ralf Haferkamp rhafer@suse.de wrote:
Note: As stated in the man-pages (ldap.conf(5) and slapd.conf(5)), when you want to use CRLs you have to specify a CACERTDIR. That directory has to be correctly hashed (using c_rehash).
Yes, I tried this but did not have success either. I'll come back on it later.
On Jul 26, 2007, at 1:28 AM, Ralf Haferkamp wrote:
[... re CRL checks ...]
They should work with 0.9.7d. IIRC that was the version I used when implementing CRL support.
Right.
Note: As stated in the man-pages (ldap.conf(5) and slapd.conf(5)), when you want to use CRLs you have to specify a CACERTDIR. That directory has to be correctly hashed (using c_rehash).
I don't use CACERTDIR, I put the CRL in the CA certificate.
That works, but there's a maintenance problem. Our CRLs expire, fairly quickly, and that breaks certificate verification, so once we have a CRL, we have to keep it up to date whether we care about it or not. There doesn't seem to be any way to reload a CRL (OpenSSL bug 1424, Nov 8 2006), so we have to restart slapd for each update. Does the CACERTDIR approach avoid this problem?
Donn Cave, donn@u.washington.edu
Am Do 26 Jul 2007 18:39:22 CEST schrieb Donn Cave donn@u.washington.edu:
On Jul 26, 2007, at 1:28 AM, Ralf Haferkamp wrote:
[... re CRL checks ...]
They should work with 0.9.7d. IIRC that was the version I used when implementing CRL support.
Right.
Note: As stated in the man-pages (ldap.conf(5) and slapd.conf(5)), when you want to use CRLs you have to specify a CACERTDIR. That directory has to be correctly hashed (using c_rehash).
I don't use CACERTDIR, I put the CRL in the CA certificate.
Ah, ok that should work as well.
That works, but there's a maintenance problem. Our CRLs expire, fairly quickly, and that breaks certificate verification, so once we have a CRL, we have to keep it up to date whether we care about it or not. There doesn't seem to be any way to reload a CRL (OpenSSL bug 1424, Nov 8 2006), so we have to restart slapd for each update. Does the CACERTDIR approach avoid this problem?
No, unfortunately not.
I have found this thread quite useful, it has tied together many lose ends for me.
There is one more point I would like clarified. The subject says in part "failover config". However:
On Mon, Jul 23, 2007 at 01:51:19PM +0000, Emmanuel Dreyfus wrote:
For future reference, here is what I had to do to get multiple LDAP servers answering on the same DNS address and using TLS.
The DNS contains this records: srv1 IN A 192.0.2.4 srv2 IN A 192.0.2.5 ldap 1 IN A 192.0.2.4 ldap 1 IN A 192.0.2.5
As the text says, this is multiple LDAP servers answering on the same DNS address. Where is the "fail-over" part? Is that assumed to be configured somewhere else?
No doubt this question is outside the scope of this list, but it would be useful to have this clarified if this thread lives on to be a HOWTO.
Cheers.
Norman Gaywood ngaywood@une.edu.au wrote:
The DNS contains this records: srv1 IN A 192.0.2.4 srv2 IN A 192.0.2.5 ldap 1 IN A 192.0.2.4 ldap 1 IN A 192.0.2.5
As the text says, this is multiple LDAP servers answering on the same DNS address. Where is the "fail-over" part? Is that assumed to be configured somewhere else?
On the client, you have this in ldap.conf URI ldaps://ldap.example.net:636
The client will spread its requests on srv1 and srv2. If one is down, then it will try the next one until one works.
The worst case is if one of {srv1, srv2} accept the connexion but take forever to answer (a situation you can have in some kernel crashes, on heavy loads, or if you simulated it by sending a kill -STOP to slapd). In that situation the client connects and will timeout. The timeout setting is left to the application. pam_ldap has bind_timelimit, for instance. OpenLDAP command-line tools (ldapsearch and friends) are stick with a hardcoded timeout that cannot be user-configured without rebuilding the sources.
No doubt this question is outside the scope of this list, but it would be useful to have this clarified if this thread lives on to be a HOWTO.
IMO, it's not outside the scope of the list. The list is about using OpenLDAP for doing things with it, right?
openldap-software@openldap.org
-
Christopher Cowart -
Donn Cave -
Emmanuel Dreyfus -
Howard Chu -
manu＠netbsd.org
-
Michael Ströder -
Norman Gaywood -
Quanah Gibson-Mount -
Ralf Haferkamp -
Russ Allbery