Hi,
I am trying to upgrade from 2.3.42 to 2.4.15 and my setup uses single-master replication over TLS. When I do the upgrade I have noticed that replication fails. I have reproduced the problem in my lab, using a single server and multiple slapd instances, and I get the following error on the slave:
[root@otm-hp11 cnd]# ./slapd -f slapdSlave.conf -d sync -h "ldap://47.11.48.221:20389 ldaps://47.11.48.221:20636" @(#) $OpenLDAP: slapd 2.4.15 (Feb 25 2009 22:27:30) $ worganc@otm-hp11:/home/worganc/openldap_build/openldap-2.4.15/servers/sl apd bdb_db_open: warning - no DB_CONFIG file found in directory /opt/nortel/cnd/slave-data: (2). Expect poor performance for suffix "dc=Nortel,dc=com". slapd starting TLS certificate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. slap_client_connect: URI=ldaps://47.11.48.221:10636 DN="cn=replicationagent,ou=replication,dc=nortel,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=983 retrying (4 retries left)
The corresponding trace on the master is:
TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca.
Based on the error messages, I thought that there was a problem with the certificates I am using, but when I revert the slapd executable to the old 2.3.42 version, replication succeeds. Were more stringent CA checks added between 2.3.42 and 2.4.15? Note that the same OpenSSL version was used to build both slapd executables (0.9.8b). Also, the same configuration options were used to build both versions.
Cheers,
Craig
Craig Worgan wrote:
Hi,
I am trying to upgrade from 2.3.42 to 2.4.15 and my setup uses single-master replication over TLS. When I do the upgrade I have noticed that replication fails. I have reproduced the problem in my lab, using a single server and multiple slapd instances, and I get the following error on the slave:
[root@otm-hp11 cnd]# ./slapd -f slapdSlave.conf -d sync -h "ldap://47.11.48.221:20389 ldaps://47.11.48.221:20636" @(#) $OpenLDAP: slapd 2.4.15 (Feb 25 2009 22:27:30) $ worganc@otm-hp11:/home/worganc/openldap_build/openldap-2.4.15/servers/slapd bdb_db_open: warning - no DB_CONFIG file found in directory /opt/nortel/cnd/slave-data: (2). Expect poor performance for suffix "dc=Nortel,dc=com". slapd starting TLS certificate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. slap_client_connect: URI=ldaps://47.11.48.221:10636 DN="cn=replicationagent,ou=replication,dc=nortel,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=983 retrying (4 retries left)
The corresponding trace on the master is:
TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca.
Are your 2.3.42 and your 2.4.15 instances both identically configured to be aware of your CA's public certificate ?
Based on the error messages, I thought that there was a problem with the certificates I am using, but when I revert the slapd executable to the old 2.3.42 version, replication succeeds. Were more stringent CA checks added between 2.3.42 and 2.4.15? Note that the same OpenSSL version was used to build both slapd executables (0.9.8b). Also, the same configuration options were used to build both versions.
Cheers,
Craig
--On Thursday, February 26, 2009 1:13 PM -0500 Craig Worgan worganc@nortel.com wrote:
Based on the error messages, I thought that there was a problem with the certificates I am using, but when I revert the slapd executable to the old 2.3.42 version, replication succeeds. Were more stringent CA checks added between 2.3.42 and 2.4.15?
A number of changes have been made to the TLS related code since 2.3. Additionally, TLS configuration for syncrepl is now part of the syncrepl stanza. See the admin guide:
http://www.openldap.org/doc/admin24/slapdconfig.html#syncrepl
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi George,
They are both identically configured in all ways including their TLS settings. Quanah has pointed out that TLS configuration syncrepl has changed in 2.4. I am currently testing in my lab.
Thanks,
Craig
-----Original Message----- From: openldap-software-bounces+worganc=nortel.com@openldap.org [mailto:openldap-software-bounces+worganc=nortel.com@openldap.org] On Behalf Of George Holbert Sent: Thursday, February 26, 2009 1:35 PM To: openldap-software@openldap.org Subject: Re: Single-master replication over TLS fails in 2.4.15
Craig Worgan wrote:
Hi,
I am trying to upgrade from 2.3.42 to 2.4.15 and my setup uses single-master replication over TLS. When I do the upgrade I have noticed that replication fails. I have reproduced the problem in my lab, using a single server and multiple slapd instances, and I get the
following error on the slave:
[root@otm-hp11 cnd]# ./slapd -f slapdSlave.conf -d sync -h "ldap://47.11.48.221:20389 ldaps://47.11.48.221:20636" @(#) $OpenLDAP: slapd 2.4.15 (Feb 25 2009 22:27:30) $
worganc@otm-hp11:/home/worganc/openldap_build/openldap-2.4.15/servers/ slapd
bdb_db_open: warning - no DB_CONFIG file found in directory /opt/nortel/cnd/slave-data: (2). Expect poor performance for suffix "dc=Nortel,dc=com". slapd starting TLS certificate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. slap_client_connect: URI=ldaps://47.11.48.221:10636 DN="cn=replicationagent,ou=replication,dc=nortel,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=983 retrying (4 retries left)
The corresponding trace on the master is:
TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca.
Are your 2.3.42 and your 2.4.15 instances both identically configured to be aware of your CA's public certificate ?
Based on the error messages, I thought that there was a problem with the certificates I am using, but when I revert the slapd executable to
the old 2.3.42 version, replication succeeds. Were more stringent CA checks added between 2.3.42 and 2.4.15? Note that the same OpenSSL version was used to build both slapd executables (0.9.8b). Also, the same configuration options were used to build both versions.
Cheers,
Craig
Thanks Quanah,
Adding the pertinent TLS directives to my syncrepl configuration fixes the problem.
Cheers,
Craig
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Thursday, February 26, 2009 1:43 PM To: Worgan, Craig (BVW:9T16); openldap-software@openldap.org Subject: Re: Single-master replication over TLS fails in 2.4.15
--On Thursday, February 26, 2009 1:13 PM -0500 Craig Worgan worganc@nortel.com wrote:
Based on the error messages, I thought that there was a problem with
the
certificates I am using, but when I revert the slapd executable to the old 2.3.42 version, replication succeeds. Were more stringent CA
checks
added between 2.3.42 and 2.4.15?
A number of changes have been made to the TLS related code since 2.3. Additionally, TLS configuration for syncrepl is now part of the syncrepl
stanza. See the admin guide:
http://www.openldap.org/doc/admin24/slapdconfig.html#syncrepl
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Craig Worgan wrote:
Hi,
I am trying to upgrade from 2.3.42 to 2.4.15 and my setup uses single-master replication over TLS. When I do the upgrade I have noticed that replication fails. I have reproduced the problem in my lab, using a single server and multiple slapd instances, and I get the following error on the slave:
[root@otm-hp11 cnd]# ./slapd -f slapdSlave.conf -d sync -h "ldap://47.11.48.221:20389 ldaps://47.11.48.221:20636" @(#) $OpenLDAP: slapd 2.4.15 (Feb 25 2009 22:27:30) $ worganc@otm-hp11:/home/worganc/openldap_build/openldap-2.4.15/servers/slapd bdb_db_open: warning - no DB_CONFIG file found in directory /opt/nortel/cnd/slave-data: (2). Expect poor performance for suffix "dc=Nortel,dc=com". slapd starting TLS certificate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. slap_client_connect: URI=ldaps://47.11.48.221:10636 DN="cn=replicationagent,ou=replication,dc=nortel,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=983 retrying (4 retries left)
The corresponding trace on the master is:
TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca.
Sounds like you didn't configure a TLSCACertificateFile on the consumer.
Based on the error messages, I thought that there was a problem with the certificates I am using, but when I revert the slapd executable to the old 2.3.42 version, replication succeeds. Were more stringent CA checks added between 2.3.42 and 2.4.15? Note that the same OpenSSL version was used to build both slapd executables (0.9.8b). Also, the same configuration options were used to build both versions.
Cheers,
Craig
Hi Howard,
I actually thought that my certificate was bad, until I went back to 2.3 with the same certificate and configuration and it worked fine. Quanah pointed out the new TLS related syncrepl options which, when I added them to my config, fixed the problem. Thing is, I pointed the syncrepl options to the same certificate I am using for the TLS* server certificate directives. I am using a compound certificate, so my TLS related config looks like this:
... TLSCertificateFile 0.pem TLSCACertificateFile 0.pem TLSCertificateKeyFile 0.pem ... syncrepl rid=983 provider=ldaps://myhost.nortel.com:10636 type=refreshAndPersist searchbase=dc=nortel,dc=com bindmethod=simple binddn=cn=someaccount,dc=nortel,dc=com credentials=secret retry="30 +" tls_cert=0.pem tls_cacert=0.pem tls_key=0.pem
In 2.4, if you configure syncrepl over TLS and omit the new options, does OpenLDAP use the values that are configured for the server certificate settings (TLS*), if any? If so, I'm confused as to why it failed for me originally.
Cheers,
Craig
-----Original Message----- From: openldap-software-bounces+worganc=nortel.com@openldap.org [mailto:openldap-software-bounces+worganc=nortel.com@openldap.org] On Behalf Of Howard Chu Sent: Thursday, February 26, 2009 4:30 PM To: Worgan, Craig (BVW:9T16) Cc: openldap-software@openldap.org Subject: Re: Single-master replication over TLS fails in 2.4.15
Craig Worgan wrote:
Hi,
I am trying to upgrade from 2.3.42 to 2.4.15 and my setup uses single-master replication over TLS. When I do the upgrade I have noticed that replication fails. I have reproduced the problem in my lab, using a single server and multiple slapd instances, and I get the
following error on the slave:
[root@otm-hp11 cnd]# ./slapd -f slapdSlave.conf -d sync -h "ldap://47.11.48.221:20389 ldaps://47.11.48.221:20636" @(#) $OpenLDAP: slapd 2.4.15 (Feb 25 2009 22:27:30) $
worganc@otm-hp11:/home/worganc/openldap_build/openldap-2.4.15/servers/ slapd
bdb_db_open: warning - no DB_CONFIG file found in directory /opt/nortel/cnd/slave-data: (2). Expect poor performance for suffix "dc=Nortel,dc=com". slapd starting TLS certificate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. slap_client_connect: URI=ldaps://47.11.48.221:10636 DN="cn=replicationagent,ou=replication,dc=nortel,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=983 retrying (4 retries left)
The corresponding trace on the master is:
TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca.
Sounds like you didn't configure a TLSCACertificateFile on the consumer.
Based on the error messages, I thought that there was a problem with the certificates I am using, but when I revert the slapd executable to
the old 2.3.42 version, replication succeeds. Were more stringent CA checks added between 2.3.42 and 2.4.15? Note that the same OpenSSL version was used to build both slapd executables (0.9.8b). Also, the same configuration options were used to build both versions.
Cheers,
Craig
Craig Worgan wrote:
Hi Howard,
I actually thought that my certificate was bad, until I went back to 2.3 with the same certificate and configuration and it worked fine. Quanah pointed out the new TLS related syncrepl options which, when I added them to my config, fixed the problem. Thing is, I pointed the syncrepl options to the same certificate I am using for the TLS* server certificate directives. I am using a compound certificate, so my TLS related config looks like this:
... TLSCertificateFile 0.pem TLSCACertificateFile 0.pem TLSCertificateKeyFile 0.pem
Combining the private and public elements of the certs into one file is not wise.
... syncrepl rid=983 provider=ldaps://myhost.nortel.com:10636 type=refreshAndPersist searchbase=dc=nortel,dc=com bindmethod=simple binddn=cn=someaccount,dc=nortel,dc=com credentials=secret retry="30 +" tls_cert=0.pem tls_cacert=0.pem tls_key=0.pem
In 2.4, if you configure syncrepl over TLS and omit the new options, does OpenLDAP use the values that are configured for the server certificate settings (TLS*), if any?
That's already explicitly stated in the slapd.conf(5) manpage.
If so, I'm confused as to why it failed for me originally.
I have no idea, it works for me.
On Thu, 2009-02-26 at 14:56 -0800, Howard Chu wrote:
In 2.4, if you configure syncrepl over TLS and omit the new options, does OpenLDAP use the values that are configured for the server certificate settings (TLS*), if any?
That's already explicitly stated in the slapd.conf(5) manpage.
If so, I'm confused as to why it failed for me originally.
I have no idea, it works for me.
Meh!
Craig: Try issuing two certs for your replica. One for the "server" services, one for the "client" service.
Sign them both by the same Root CA, or two different intermediary CAs (which you can daisy chain), but differentiate them with Netscape Certificate Use extensions for your own reference
OpenSSL.cnf:
[ v3_req_ext ] subjectAltName=email:copy nsCertType = client, email, objsign # .2 = Client, .1 = Server extendedKeyUsage = 1.3.6.1.5.5.7.3.2 # extendedKeyUsage = 1.3.6.1.5.5.7.3.1 # Other Variation extendedKeyUsage=serverAuth extendedKeyUsage=clientAuth
For example, your replica may sync with your master using a management interface which it sources its client TCP connection to the master from:
e.g., some-name.facil.organization.tld
-- The client cert will be signed with this hostname in the CN=
Then, it may serve its LDAP replia off of a "service VIP", possibly a HA/Load-Balanced IP address:
e.g., ldap.organization.tld
The Server cert can be signed with this hostname in the CN=
I'm hoping to maybe submit some massive documentation improvements that outline sound practices and affiliated recommended configurations.
~BAS
Brian A. Seklecki wrote:
On Thu, 2009-02-26 at 14:56 -0800, Howard Chu wrote:
In 2.4, if you configure syncrepl over TLS and omit the new options, does OpenLDAP use the values that are configured for the server certificate settings (TLS*), if any?
That's already explicitly stated in the slapd.conf(5) manpage.
If so, I'm confused as to why it failed for me originally.
I have no idea, it works for me.
Meh!
Craig: Try issuing two certs for your replica. One for the "server" services, one for the "client" service.
Sign them both by the same Root CA, or two different intermediary CAs (which you can daisy chain), but differentiate them with Netscape Certificate Use extensions for your own reference
You're assuming he even has a CA cert. From the looks of it, he's using a single self-signed cert for everything. The Admin Guide already tells you to use a CA cert and separate server and client certs, but some people just don't seem to bother reading or following docs. All the documentation in the world is useless if nobody pays any attention.
We have an internal certificate authority which issues certificates to us. The authority provides certificates as a single file containing the certificate, the CA certificate (or chain) and the private key. We have no control over this, but I have forwarded the concern over the single file approach that Howard brought up previously to my CA team.
Based on the input to this chain, we will start using separate certificates for the server and client.
I do spend a fair amount of time in the OpenLDAP documentation, especially prior to resorting to the mailing list. This time around, I didn't see the answers I needed in the Admin Guide. I'll go back and look again. If it's still not clear I'd be happy to help out with the documentation.
Thanks everyone,
Craig
-----Original Message----- From: openldap-software-bounces+worganc=nortel.com@openldap.org [mailto:openldap-software-bounces+worganc=nortel.com@openldap.org] On Behalf Of Howard Chu Sent: Friday, February 27, 2009 6:06 PM To: Brian A. Seklecki Cc: Worgan, Craig (BVW:9T16); openldap-software@openldap.org Subject: Re: Single-master replication over TLS fails in 2.4.15
Brian A. Seklecki wrote:
On Thu, 2009-02-26 at 14:56 -0800, Howard Chu wrote:
In 2.4, if you configure syncrepl over TLS and omit the new options,
does OpenLDAP use the values that are configured for the server certificate settings (TLS*), if any?
That's already explicitly stated in the slapd.conf(5) manpage.
If so, I'm confused as to why it failed for me originally.
I have no idea, it works for me.
Meh!
Craig: Try issuing two certs for your replica. One for the "server" services, one for the "client" service.
Sign them both by the same Root CA, or two different intermediary
CAs
(which you can daisy chain), but differentiate them with Netscape Certificate Use extensions for your own reference
You're assuming he even has a CA cert. From the looks of it, he's using a single self-signed cert for everything. The Admin Guide already tells you to use a CA cert and separate server and client certs, but some people just don't seem to bother reading or following docs. All the documentation in the world is useless if nobody pays any attention.
--On Saturday, February 28, 2009 10:25 AM -0500 Craig Worgan worganc@nortel.com wrote:
We have an internal certificate authority which issues certificates to us. The authority provides certificates as a single file containing the certificate, the CA certificate (or chain) and the private key. We have no control over this, but I have forwarded the concern over the single file approach that Howard brought up previously to my CA team.
When I received certs that way, I manually separated them out before deploying them. ;) They are only text files after all. :)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org