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

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

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

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.