[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
failover config: servers with same DNS address and TLS, subjectAltName extension
- To: openldap-software@openldap.org
- Subject: failover config: servers with same DNS address and TLS, subjectAltName extension
- From: Emmanuel Dreyfus <manu@netbsd.org>
- Date: Mon, 23 Jul 2007 13:51:19 +0000
- Content-disposition: inline
- User-agent: Mutt/1.4.2.3i
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