Hello,
I'm trying to upgrade an openLdap server from Fedora Core 13 (openldap-servers-2.4.21-11) to Redhat Enterprise 6 (openldap-servers-2.4.23-15.el6.x86_64). In this new setup, my local bdb backend works: I can query the LDAP server on this backend using an "ldaps://" connection (it is using a server certificate).
However, the Syncrepl replication process fails to establish the "ldaps://" session to my syncrepl-providers. Indeed, the TLS layer complains that my _server's certificate_ isn't a valid _client certificate_ (with error 8101 - SEC_ERROR_INADEQUATE_CERT_TYPE): but I don't want client-side authentication!
In the past syncrepl didn't try to use the server certificate as a client certificate, and I haven't seen any reference to this in the documentation. I first thought it could have been related to ITS#6791 but I don't think so anymore because it only affects Syncrepl.
Do you think I've missed something in the setup?
Thanks in advance, Thibault
Here is an excerpt of slapd startup log in debug-mode: ---------------------------------------------------------- ldap_connect_to_host: Trying 10.10.10.10:636 ldap_pvt_connect: fd: 21 tm: -1 async: 0 TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is not valid - error -8101:Unknown code ___f 91. TLS: error: unable to set up client certificate authentication for certificate named PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: unable to set up client certificate authentication using PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: could not initialize moznss security context - error -8101:Unknown code ___f 91 TLS: can't create ssl handle. slap_client_connect: URI=ldaps://otherldap.mydom.fr DN="cn=myreplicationAccount,dc=mydom,dc=fr" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=125 rc -1 retrying (9 retries left) ----------------------------------------------------------
Here is my syncrepl setup: --------------------------------------------------------- syncrepl rid=125 provider=ldaps://otherldap.mydom.fr type=refreshOnly interval=00:00:03:00 retry="60 10 300 +" searchbase="dc=subranch,dc=mydom,dc=fr" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=myreplicationAccount,dc=mydom,dc=fr" credentials="MyVerySecretPassword" ---------------------------------------------------------
My setup related to TLS: --------------------------------------------------------- TLSCipherSuite HIGH TLSCertificateFile /etc/ssl/certs/myldap.mydom.fr-cert.pem TLSCertificateKeyFile /etc/ssl/keys/myldap.mydom.fr-key.pem TLSCACertificateFile /etc/ssl/cacerts/cacert.pem ---------------------------------------------------------
And eventually my /etc/openldap/ldap.conf: --------------------------------------------------------- TLS_CACERT /etc/ssl/cacerts/cacert.pem ---------------------------------------------------------
--On Monday, July 11, 2011 10:32 AM +0200 Thibault Le Meur Thibault.LeMeur@supelec.fr wrote:
Hello,
I'm trying to upgrade an openLdap server from Fedora Core 13 (openldap-servers-2.4.21-11) to Redhat Enterprise 6 (openldap-servers-2.4.23-15.el6.x86_64). In this new setup, my local bdb backend works: I can query the LDAP server on this backend using an "ldaps://" connection (it is using a server certificate).
However, the Syncrepl replication process fails to establish the "ldaps://" session to my syncrepl-providers. Indeed, the TLS layer complains that my _server's certificate_ isn't a valid _client certificate_ (with error 8101 - SEC_ERROR_INADEQUATE_CERT_TYPE): but I don't want client-side authentication!
In the past syncrepl didn't try to use the server certificate as a client certificate, and I haven't seen any reference to this in the documentation. I first thought it could have been related to ITS#6791 but I don't think so anymore because it only affects Syncrepl.
Do you think I've missed something in the setup?
Thanks in advance, Thibault
Here is an excerpt of slapd startup log in debug-mode:
ldap_connect_to_host: Trying 10.10.10.10:636 ldap_pvt_connect: fd: 21 tm: -1 async: 0 TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is not valid - error -8101:Unknown code ___f 91.
This looks like a bug with MozNSS. You will need to contact RedHat for support.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 07/11/2011 09:21 AM, Quanah Gibson-Mount wrote:
--On Monday, July 11, 2011 10:32 AM +0200 Thibault Le Meur Thibault.LeMeur@supelec.fr wrote:
Hello,
I'm trying to upgrade an openLdap server from Fedora Core 13 (openldap-servers-2.4.21-11) to Redhat Enterprise 6 (openldap-servers-2.4.23-15.el6.x86_64). In this new setup, my local bdb backend works: I can query the LDAP server on this backend using an "ldaps://" connection (it is using a server certificate).
However, the Syncrepl replication process fails to establish the "ldaps://" session to my syncrepl-providers. Indeed, the TLS layer complains that my _server's certificate_ isn't a valid _client certificate_ (with error 8101 - SEC_ERROR_INADEQUATE_CERT_TYPE): but I don't want client-side authentication!
In the past syncrepl didn't try to use the server certificate as a client certificate, and I haven't seen any reference to this in the documentation. I first thought it could have been related to ITS#6791 but I don't think so anymore because it only affects Syncrepl.
Do you think I've missed something in the setup?
Thanks in advance, Thibault
Here is an excerpt of slapd startup log in debug-mode:
ldap_connect_to_host: Trying 10.10.10.10:636 ldap_pvt_connect: fd: 21 tm: -1 async: 0 TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is not valid - error -8101:Unknown code ___f 91.
Can you do openssl x509 -in /path/to/cert.pem -text and paste the output here? /path/to/cert.pem is the file containing the cert which has the Subject DN: CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR
Is this the server cert of the remote server (i.e. not the syncrepl client).
Be sure to obscure any sensitive data in the -text output before sending.
This looks like a bug with MozNSS. You will need to contact RedHat for support.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
Hi Rich,
Thanks for your answer.
Le 11/07/2011 17:30, Rich Megginson a écrit :
Can you do openssl x509 -in /path/to/cert.pem -text and paste the output here? /path/to/cert.pem is the file containing the cert which has the Subject DN: CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR
Is this the server cert of the remote server (i.e. not the syncrepl client).
This is the certificate defined as my main LDAP server's certificate (used to enable ldaps connection). It is not the syncrepl provider's certificate, nor a certificate intended to be used to authenticate my main LDAP server to the provider.
Be sure to obscure any sensitive data in the -text output before sending.
Here's the certificate with identication fields modified, though a public certificate shouldn't contain such critical data (I wouldn't have sent my private key though ;-) ).
What is interresting here, I think is the "TLS Web Server Authentication, Code Signing" value for the "X509v3 Extended Key Usage" extension. This means that the certificate is not to be used as a client authentication certificate, so syncrepl is right in stating that the SSL connection can't be established. Though the question is, why on earth is my server trying to use my Server's certificate as a client certificate while connecting to the syncrepl ldaps provider! It should instead only check the provider's Server certificate and then binds using the provided credential to authenticate to the provider.
------------------------------------------------------------------- Certificate: Data: Version: 3 (0x2) Serial Number: 221 (0xdd) Signature Algorithm: sha1WithRSAEncryption Issuer: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myCA/emailAddress=thibault.lemeur@supelec.fr Validity Not Before: Oct 2 16:42:15 2007 GMT Not After : Dec 14 16:42:15 2012 GMT Subject: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myldap.mydom.fr Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:aa:2e:a1:15:f3:a1:50:5a:f3:8c:d8:18:07:47: ef:37:83:b8:d6:5f:e3:ad:10:1e:8b:ce:8a:00:e3: 27:ac:75:7d:47:1a:74:31:b9:f1:9e:54:2c:44:82: 86:94:d6:36:ab:2e:88:1d:6b:b1:9c:5c:66:ad:32: 2c:46:6b:1b:fe:a2:cc:d6:30:13:8e:e8:de:c2:60: 90:73:5c:8c:e1:93:49:e8:94:ab:4b:0a:5f:8f:ff: a6:1a:46:19:20:ab:cc:c6:69:7d:81:8c:16:90:b4: 02:bd:f8:c5:64:3f:03:d5:b6:94:a5:84:f5:58:01: ed:79:40:a7:8b:23:99:41:23:54:43:93:fa:71:9b: aa:5d:93:74:6c:02:e8:4c:d7:c1:99:85:19:01:5b: d3:76:ee:f8:7e:eb:82:b1:51:4a:78:7b:7d:85:a3: e2:8c:55:b6:93:b3:a0:f6:52:8f:8c:25:98:56:c1: b6:86:fc:a2:07:74:00:27:56:c5:05:7f:8e:c3:f2: 4a:26:1a:9f:65:42:aa:8e:bb:62:36:f5:f7:cf:e5: 1e:97:19:27:37:33:33:3c:9c:a3:d1:0f:a7:fd:55: c7:66:20:08:02:7c:4b:39:39:ce:9b:78:c6:33:07: 5b:41:08:e4:71:ee:a9:f4:ae:f7:03:5b:42:c0:64: 6e:81 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: TinyCA Generated Certificate X509v3 Subject Key Identifier: 7C:0D:57:20:C4:AD:35:D3:ED:E3:DE:FE:83:5E:DF:A4:F0:BB:4F:84 X509v3 Authority Key Identifier:
keyid:7D:86:22:B4:83:06:D7:49:7F:9A:BF:D6:83:41:BB:69:E5:65:6C:6E
DirName:/C=FR/ST=myst/L=myloc/O=myorg/OU=myou/CN=myCA/emailAddress=thibault.lemeur@supelec.fr serial:00
X509v3 Issuer Alternative Name: <EMPTY>
Netscape SSL Server Name: myldap.mydom.fr X509v3 Subject Alternative Name: DNS:ldap, DNS:ldapalias1, DNS:ldapalias2, DNS:ldapalias1.mydom.fr, DNS:ldapalias2.mydom.fr, DNS:ldap.mydom.fr, DNS:myldap, DNS:myldap.mydom.fr X509v3 Extended Key Usage: critical TLS Web Server Authentication, Code Signing Signature Algorithm: sha1WithRSAEncryption a4:c4:58:03:f5:4f:d5:d5:4b:65:a4:6e:ca:16:21:fd:8c:49: 06:0c:ce:74:20:17:40:c7:0f:f1:3a:15:fb:9b:37:07:4b:e2: 2a:aa:1a:cc:0b:0c:f0:aa:3c:32:17:27:1f:1d:50:e9:ff:16: 55:04:90:a9:61:37:b0:f0:95:a0:c8:cf:7d:7b:0b:ed:09:a8: 92:3e:86:a5:d1:13:7b:ae:6d:d4:99:96:4f:bf:b0:d4:84:58: 94:50:91:60:75:7e:24:30:15:d6:64:70:80:09:76:df:1f:27: 4b:3d:1c:53:b7:4e:ba:5e:d2:20:11:53:ab:32:ec:27:0c:32: 53:90 -------------------------------------------------------------------
Regards, Thibault
On 07/11/2011 10:07 AM, Thibault Le Meur wrote:
Hi Rich,
Thanks for your answer.
Le 11/07/2011 17:30, Rich Megginson a écrit :
Can you do openssl x509 -in /path/to/cert.pem -text and paste the output here? /path/to/cert.pem is the file containing the cert which has the Subject DN: CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR
Is this the server cert of the remote server (i.e. not the syncrepl client).
This is the certificate defined as my main LDAP server's certificate (used to enable ldaps connection). It is not the syncrepl provider's certificate, nor a certificate intended to be used to authenticate my main LDAP server to the provider.
Be sure to obscure any sensitive data in the -text output before sending.
Here's the certificate with identication fields modified, though a public certificate shouldn't contain such critical data (I wouldn't have sent my private key though ;-) ).
What is interresting here, I think is the "TLS Web Server Authentication, Code Signing" value for the "X509v3 Extended Key Usage" extension. This means that the certificate is not to be used as a client authentication certificate, so syncrepl is right in stating that the SSL connection can't be established. Though the question is, why on earth is my server trying to use my Server's certificate as a client certificate while connecting to the syncrepl ldaps provider! It should instead only check the provider's Server certificate and then binds using the provided credential to authenticate to the provider.
I think what is happening is that the syncrepl crypto context is "inheriting" from the main server crypto context. You want it to "inherit" the CA certificate from the main crypto context but not the server certificate. Please open an ITS for this. I'll have to figure out how this was working in openssl.
Certificate: Data: Version: 3 (0x2) Serial Number: 221 (0xdd) Signature Algorithm: sha1WithRSAEncryption Issuer: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myCA/emailAddress=thibault.lemeur@supelec.fr Validity Not Before: Oct 2 16:42:15 2007 GMT Not After : Dec 14 16:42:15 2012 GMT Subject: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myldap.mydom.fr Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:aa:2e:a1:15:f3:a1:50:5a:f3:8c:d8:18:07:47: ef:37:83:b8:d6:5f:e3:ad:10:1e:8b:ce:8a:00:e3: 27:ac:75:7d:47:1a:74:31:b9:f1:9e:54:2c:44:82: 86:94:d6:36:ab:2e:88:1d:6b:b1:9c:5c:66:ad:32: 2c:46:6b:1b:fe:a2:cc:d6:30:13:8e:e8:de:c2:60: 90:73:5c:8c:e1:93:49:e8:94:ab:4b:0a:5f:8f:ff: a6:1a:46:19:20:ab:cc:c6:69:7d:81:8c:16:90:b4: 02:bd:f8:c5:64:3f:03:d5:b6:94:a5:84:f5:58:01: ed:79:40:a7:8b:23:99:41:23:54:43:93:fa:71:9b: aa:5d:93:74:6c:02:e8:4c:d7:c1:99:85:19:01:5b: d3:76:ee:f8:7e:eb:82:b1:51:4a:78:7b:7d:85:a3: e2:8c:55:b6:93:b3:a0:f6:52:8f:8c:25:98:56:c1: b6:86:fc:a2:07:74:00:27:56:c5:05:7f:8e:c3:f2: 4a:26:1a:9f:65:42:aa:8e:bb:62:36:f5:f7:cf:e5: 1e:97:19:27:37:33:33:3c:9c:a3:d1:0f:a7:fd:55: c7:66:20:08:02:7c:4b:39:39:ce:9b:78:c6:33:07: 5b:41:08:e4:71:ee:a9:f4:ae:f7:03:5b:42:c0:64: 6e:81 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: TinyCA Generated Certificate X509v3 Subject Key Identifier:
7C:0D:57:20:C4:AD:35:D3:ED:E3:DE:FE:83:5E:DF:A4:F0:BB:4F:84 X509v3 Authority Key Identifier:
keyid:7D:86:22:B4:83:06:D7:49:7F:9A:BF:D6:83:41:BB:69:E5:65:6C:6E
DirName:/C=FR/ST=myst/L=myloc/O=myorg/OU=myou/CN=myCA/emailAddress=thibault.lemeur@supelec.fr serial:00
X509v3 Issuer Alternative Name:<EMPTY>
Netscape SSL Server Name: myldap.mydom.fr X509v3 Subject Alternative Name: DNS:ldap, DNS:ldapalias1, DNS:ldapalias2,DNS:ldapalias1.mydom.fr, DNS:ldapalias2.mydom.fr, DNS:ldap.mydom.fr, DNS:myldap, DNS:myldap.mydom.fr X509v3 Extended Key Usage: critical TLS Web Server Authentication, Code Signing Signature Algorithm: sha1WithRSAEncryption a4:c4:58:03:f5:4f:d5:d5:4b:65:a4:6e:ca:16:21:fd:8c:49: 06:0c:ce:74:20:17:40:c7:0f:f1:3a:15:fb:9b:37:07:4b:e2: 2a:aa:1a:cc:0b:0c:f0:aa:3c:32:17:27:1f:1d:50:e9:ff:16: 55:04:90:a9:61:37:b0:f0:95:a0:c8:cf:7d:7b:0b:ed:09:a8: 92:3e:86:a5:d1:13:7b:ae:6d:d4:99:96:4f:bf:b0:d4:84:58: 94:50:91:60:75:7e:24:30:15:d6:64:70:80:09:76:df:1f:27: 4b:3d:1c:53:b7:4e:ba:5e:d2:20:11:53:ab:32:ec:27:0c:32: 53:90
Regards, Thibault
Le 11/07/2011 18:29, Rich Megginson a écrit :
I think what is happening is that the syncrepl crypto context is "inheriting" from the main server crypto context.
Yes, this looks like this.
You want it to "inherit" the CA certificate from the main crypto context but not the server certificate.
Not necessarily. When linked to openssl, openldap used to use the /etc/openldap/ldap.conf file to read the client-side SSL configuration.
Please open an ITS for this. I'll have to figure out how this was working in openssl.
Done: ITS#6994
Regards, Thibault
Thibault Le Meur wrote:
Le 11/07/2011 18:29, Rich Megginson a écrit :
I think what is happening is that the syncrepl crypto context is "inheriting" from the main server crypto context.
Yes, this looks like this.
Yes, that's documented in slapd.conf(5).
You want it to "inherit" the CA certificate from the main crypto context but not the server certificate.
Not necessarily. When linked to openssl, openldap used to use the /etc/openldap/ldap.conf file to read the client-side SSL configuration.
Please open an ITS for this. I'll have to figure out how this was working in openssl.
Done: ITS#6994
Sounds to me like there's no bug here and the ITS report is invalid. If you want separate TLS settings for syncrepl you must put them in the syncrepl directive.
On 07/11/2011 02:24 PM, Howard Chu wrote:
Thibault Le Meur wrote:
Le 11/07/2011 18:29, Rich Megginson a écrit :
I think what is happening is that the syncrepl crypto context is "inheriting" from the main server crypto context.
Yes, this looks like this.
Yes, that's documented in slapd.conf(5).
What's documented where? I'm looking at the latest 2_4 branch slapd.conf and slapd-config man pages at the syncrepl directive/olcSyncrepl attribute - I don't see anything about how tls settings will use the main context if a syncrepl specific setting is not specified.
You want it to "inherit" the CA certificate from the main crypto context but not the server certificate.
Not necessarily. When linked to openssl, openldap used to use the /etc/openldap/ldap.conf file to read the client-side SSL configuration.
Please open an ITS for this. I'll have to figure out how this was working in openssl.
Done: ITS#6994
Sounds to me like there's no bug here and the ITS report is invalid. If you want separate TLS settings for syncrepl you must put them in the syncrepl directive.
My goal for openldap with moznss support is that it will work exactly like openldap with openssl worked - you should not even know (or care) that a different crypto implementation is being used. Since this is not the case with this particular issue, I consider it a bug in the moznss crypto implementation of openldap.
Hello,
Le 12/07/2011 04:34, Rich Megginson a écrit :
working in openssl.
Done: ITS#6994
Sounds to me like there's no bug here and the ITS report is invalid. If you want separate TLS settings for syncrepl you must put them in the syncrepl directive.
Please open an ITS for this. I'll have to figure out how this was My goal for openldap with moznss support is that it will work exactly like openldap with openssl worked - you should not even know (or care) that a different crypto implementation is being used. Since this is not the case with this particular issue, I consider it a bug in the moznss crypto implementation of openldap.
In fact I cannot guarantee that the current behaviour of openldap 2.4.23, when linked to openssl, would be to use a brand new TLS context: indeed my working system uses openldap 2.4.21 linked to openssl. I'll try to test on a Fedora 15 in which OpenLdap may be linked to openssl.
Thibault
On 07/12/2011 05:24 AM, Thibault Le Meur wrote:
Hello,
Le 12/07/2011 04:34, Rich Megginson a écrit :
working in openssl.
Done: ITS#6994
Sounds to me like there's no bug here and the ITS report is invalid. If you want separate TLS settings for syncrepl you must put them in the syncrepl directive.
Please open an ITS for this. I'll have to figure out how this was My goal for openldap with moznss support is that it will work exactly like openldap with openssl worked - you should not even know (or care) that a different crypto implementation is being used. Since this is not the case with this particular issue, I consider it a bug in the moznss crypto implementation of openldap.
In fact I cannot guarantee that the current behaviour of openldap 2.4.23, when linked to openssl, would be to use a brand new TLS context: indeed my working system uses openldap 2.4.21 linked to openssl. I'll try to test on a Fedora 15 in which OpenLdap may be linked to openssl.
It's not. Fedora 14 and later, and RHEL 6.1 and later, all use openldap (2.4.23 or greater) with moznss instead of openssl.
Thibault
Hello,
Le 11/07/2011 22:24, Howard Chu a écrit :
Thibault Le Meur wrote:
Le 11/07/2011 18:29, Rich Megginson a écrit : Not necessarily. When linked to openssl, openldap used to use the /etc/openldap/ldap.conf file to read the client-side SSL configuration.
Please open an ITS for this. I'll have to figure out how this was working in openssl.
Done: ITS#6994
Sounds to me like there's no bug here and the ITS report is invalid. If you want separate TLS settings for syncrepl you must put them in the syncrepl directive.
Indeed, there is a new set of TLS parameters that can be given to the syncrepl processes. However, even when defining the tls_cacert="/etc/ssl/cacerts/cacert.pem" parameter syncrepl fails to connect to ldaps:// providers because it still inherits the "client certs" from the main context. There is no tls_forget_previous_tls_context parameter so that unless I try to overwrite the tls_cert and tls_key parameter (something I don't want to do in my particular setup) I can't get rid of the global TLS context.
Regards, Thibault
--On Monday, July 11, 2011 6:44 PM +0200 Thibault Le Meur Thibault.LeMeur@supelec.fr wrote:
Le 11/07/2011 18:29, Rich Megginson a écrit :
I think what is happening is that the syncrepl crypto context is "inheriting" from the main server crypto context.
Yes, this looks like this.
You want it to "inherit" the CA certificate from the main crypto context but not the server certificate.
Not necessarily. When linked to openssl, openldap used to use the /etc/openldap/ldap.conf file to read the client-side SSL configuration.
Please open an ITS for this. I'll have to figure out how this was working in openssl.
Done: ITS#6994
Actually syncrepl has its own configuration now for SSL/TLS.
olcSyncrepl: rid=<replica ID> provider=ldap[s]://<hostname>[:port] searchbase=<base DN> [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of retries>]+] [filter=<filter str>] [scope=sub|one|base|subord] [attrs=<attr list>] [exattrs=<attr list>] [attrsonly] [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off] [network-timeout=<seconds>] [timeout=<seconds>] [bindmethod=simple|sasl] [binddn=<dn>] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>] [realm=<realm>] [secprops=<properties>] [keepalive=<idle>:<probes>:<interval>] [starttls=yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_ciphersuite=<ciphers>] [tls_crlcheck=none|peer|all] [suffixmassage=<real DN>] [logbase=<base DN>] [logfilter=<filter str>] [syncdata=default|accesslog|changelog]
Note the tls_cacertdir, etc., options.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Le 11/07/2011 17:21, Quanah Gibson-Mount a écrit :
This looks like a bug with MozNSS. You will need to contact RedHat for support.
Thank you for your answer, i didn't realize that OpenLdap on RedHat wasn't linked against openssl but with another library.
I guess that Rich Megginson may help in this particular case ;-)
Regards, Thibault
On 07/11/2011 10:10 AM, Thibault Le Meur wrote:
Le 11/07/2011 17:21, Quanah Gibson-Mount a écrit :
This looks like a bug with MozNSS. You will need to contact RedHat for support.
Thank you for your answer, i didn't realize that OpenLdap on RedHat wasn't linked against openssl but with another library.
I guess that Rich Megginson may help in this particular case ;-)
Yes - mea culpa for openldap + moznss problems.
Regards, Thibault
openldap-technical@openldap.org
-
Howard Chu -
Quanah Gibson-Mount -
Rich Megginson -
Thibault Le Meur