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

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

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.

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