Dear Tech list,
I'd like to use CRL's to regulate client connections to my slapd server. So i've build working certs and keys with gnutls. The whole keysetup is tested and working properly, by invoking gnu-serv and gnu-cli i could succesfully create connections and drop clients in my revocation list.
In order to use this in slapd/ldap utils i use this settings,
slapd.conf, TLSCACertificateFile /etc/ldap/ssl/ca-cert.pem TLSCertificateFile /etc/ldap/ssl/clients/lrc-ldap.crt TLSCertificateKeyFile /etc/ldap/ssl/clients/lrc-ldap.key TLSCRLFile /etc/ldap/ssl/crl.pem TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSVerifyClient hard
ldap.conf # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ldap/ssl/ca-cert.pem TLS_CERT /etc/ldap/ssl/clients/lrc-ldapsearch.crt TLS_KEY /etc/ldap/ssl/clients/lrc-ldapsearch.key TLS_REQCERT hard
Slapd debug, 55353d59 slapd starting 55353d5b conn=1000 fd=16 ACCEPT from IP=10.50.2.12:50764 (IP=0.0.0.0:636) TLS: can't accept: No certificate was found.. 55353d5b conn=1000 fd=16 closed (TLS negotiation failure)
ldapsearch debug, ldap_start_tls: Can't contact LDAP server (-1) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 0000: 30 05 02 01 02 42 00 0....B. ldap_write: want=7 error=Broken pipe ldap_free_connection: actually freed
As far as i can see and found info my client and servers TLS settings are configured properly. What i really don't get is that the client doesnt send his certs to the server.
Best regards, E.therepa
E.therepa wrote:
Dear Tech list,
I'd like to use CRL's to regulate client connections to my slapd server. So i've build working certs and keys with gnutls. The whole keysetup is tested and working properly, by invoking gnu-serv and gnu-cli i could succesfully create connections and drop clients in my revocation list.
In order to use this in slapd/ldap utils i use this settings,
slapd.conf, TLSCACertificateFile /etc/ldap/ssl/ca-cert.pem TLSCertificateFile /etc/ldap/ssl/clients/lrc-ldap.crt TLSCertificateKeyFile /etc/ldap/ssl/clients/lrc-ldap.key TLSCRLFile /etc/ldap/ssl/crl.pem TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSVerifyClient hard
ldap.conf # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ldap/ssl/ca-cert.pem
TLS_CERT /etc/ldap/ssl/clients/lrc-ldapsearch.crt TLS_KEY /etc/ldap/ssl/clients/lrc-ldapsearch.key
cert and key are invalid in a .conf file. Read the ldap.conf(5) manpage more carefully.
TLS_REQCERT hard
As far as i can see and found info my client and servers TLS settings are configured properly. What i really don't get is that the client doesnt send his certs to the server.
On Mon, Apr 20, 2015 at 08:07:48PM +0200, E.therepa wrote:
ldap.conf # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ldap/ssl/ca-cert.pem TLS_CERT /etc/ldap/ssl/clients/lrc-ldapsearch.crt TLS_KEY /etc/ldap/ssl/clients/lrc-ldapsearch.key TLS_REQCERT hard
<snip>
As far as i can see and found info my client and servers TLS settings are configured properly. What i really don't get is that the client doesnt send his certs to the server.
We made some progress on this in IRC: as noted in ldap.conf(5), the TLS_KEY option is only valid in a user ldaprc, not the system-wide ldap.conf, so it was being ignored.
On 04/20/15 20:07 +0200, E.therepa wrote:
Dear Tech list,
I'd like to use CRL's to regulate client connections to my slapd server. So i've build working certs and keys with gnutls. The whole keysetup is tested and working properly, by invoking gnu-serv and gnu-cli i could succesfully create connections and drop clients in my revocation list.
In order to use this in slapd/ldap utils i use this settings,
slapd.conf, TLSCACertificateFile /etc/ldap/ssl/ca-cert.pem TLSCertificateFile /etc/ldap/ssl/clients/lrc-ldap.crt TLSCertificateKeyFile /etc/ldap/ssl/clients/lrc-ldap.key TLSCRLFile /etc/ldap/ssl/crl.pem TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSVerifyClient hard
ldap.conf # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ldap/ssl/ca-cert.pem TLS_CERT /etc/ldap/ssl/clients/lrc-ldapsearch.crt
This is a user only option. See ldap.conf(5).
TLS_KEY /etc/ldap/ssl/clients/lrc-ldapsearch.key TLS_REQCERT hard
Slapd debug, 55353d59 slapd starting 55353d5b conn=1000 fd=16 ACCEPT from IP=10.50.2.12:50764 (IP=0.0.0.0:636) TLS: can't accept: No certificate was found.. 55353d5b conn=1000 fd=16 closed (TLS negotiation failure)
ldapsearch debug, ldap_start_tls: Can't contact LDAP server (-1) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 0000: 30 05 02 01 02 42 00 0....B. ldap_write: want=7 error=Broken pipe ldap_free_connection: actually freed
As far as i can see and found info my client and servers TLS settings are configured properly. What i really don't get is that the client doesnt send his certs to the server.
Alright, it's clear. The section in Debian's ldap.conf has the following content, TLSCertificateKeyFile <filename> Specifies the file that contains the slapd server private key that matches the certificate stored in the TLSCertificateFile file. Currently, the private key must not be protected with a password, so it is of critical importance that it is protected carefully.
When using Mozilla NSS, TLSCertificateKeyFile specifies the name of a file that contains the password for the key for the certificate specified with TLSCertificateFile. The modutil command can be used to turn off password protection for the cert/key database. For example, if TLSCACertificatePath specifes /etc/openldap/certdb as the location of the cert/key database, use modutil to change the password to the empty string: modutil -dbdir /etc/openldap/certdb -changepw 'NSS Certificate DB' You must have the old password, if any. Ignore the WARNING about the running browser. Press 'Enter' for the new password.
Reading this info i would not expect it is not valid in ldap.conf since it is not pointed out here. Nevertheless i could have read further.
Howard Chu, If you allow me to ask you something about gnutls directly, do you still stand behind the statement you made here, http://www.openldap.org/lists/openldap-devel/200802/msg00072.html
i know it's out of date but you said 'the code is fundamentally broken'. I'm not knowledged about the internals of gnutls but i am very cusious if you changed your mind since then.
Best regards, Etherape
On Mon, Apr 20, 2015 at 02:46:28PM -0500, Dan White wrote:
On 04/20/15 20:07 +0200, E.therepa wrote:
Dear Tech list,
I'd like to use CRL's to regulate client connections to my slapd server. So i've build working certs and keys with gnutls. The whole keysetup is tested and working properly, by invoking gnu-serv and gnu-cli i could succesfully create connections and drop clients in my revocation list.
In order to use this in slapd/ldap utils i use this settings,
slapd.conf, TLSCACertificateFile /etc/ldap/ssl/ca-cert.pem TLSCertificateFile /etc/ldap/ssl/clients/lrc-ldap.crt TLSCertificateKeyFile /etc/ldap/ssl/clients/lrc-ldap.key TLSCRLFile /etc/ldap/ssl/crl.pem TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSVerifyClient hard
ldap.conf # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ldap/ssl/ca-cert.pem TLS_CERT /etc/ldap/ssl/clients/lrc-ldapsearch.crt
This is a user only option. See ldap.conf(5).
TLS_KEY /etc/ldap/ssl/clients/lrc-ldapsearch.key TLS_REQCERT hard
Slapd debug, 55353d59 slapd starting 55353d5b conn=1000 fd=16 ACCEPT from IP=10.50.2.12:50764 (IP=0.0.0.0:636) TLS: can't accept: No certificate was found.. 55353d5b conn=1000 fd=16 closed (TLS negotiation failure)
ldapsearch debug, ldap_start_tls: Can't contact LDAP server (-1) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 0000: 30 05 02 01 02 42 00 0....B. ldap_write: want=7 error=Broken pipe ldap_free_connection: actually freed
As far as i can see and found info my client and servers TLS settings are configured properly. What i really don't get is that the client doesnt send his certs to the server.
-- Dan White
--On Tuesday, April 21, 2015 2:18 AM +0200 Enterprise Spirit ldaptech+Etherape@kernelbug.org wrote:
Howard Chu, If you allow me to ask you something about gnutls directly, do you still stand behind the statement you made here, http://www.openldap.org/lists/openldap-devel/200802/msg00072.html
i know it's out of date but you said 'the code is fundamentally broken'. I'm not knowledged about the internals of gnutls but i am very cusious if you changed your mind since then.
It's funny you ask... There was a spirited debate with one of the GnuTLS author's a while back about this, as they blogged that Howard was incorrect. Howard pointed out on the blog (http://nmav.gnutls.org/2011/05/is-really-gnutls-considered-harmful.html) that he was in fact still correct, and gave examples. After which the GnuTLS author deleted the entire conversation off of his blog, and locked it down. That, to me, says worlds about how "safe" one can consider GnuTLS.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Tuesday, April 21, 2015 9:26 AM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Tuesday, April 21, 2015 2:18 AM +0200 Enterprise Spirit ldaptech+Etherape@kernelbug.org wrote:
Howard Chu, If you allow me to ask you something about gnutls directly, do you still stand behind the statement you made here, http://www.openldap.org/lists/openldap-devel/200802/msg00072.html
i know it's out of date but you said 'the code is fundamentally broken'. I'm not knowledged about the internals of gnutls but i am very cusious if you changed your mind since then.
It's funny you ask... There was a spirited debate with one of the GnuTLS author's a while back about this, as they blogged that Howard was incorrect. Howard pointed out on the blog (<http://nmav.gnutls.org/2011/05/is-really-gnutls-considered-harmful.html
) that he was in fact still correct, and gave examples. After which the
GnuTLS author deleted the entire conversation off of his blog, and locked it down. That, to me, says worlds about how "safe" one can consider GnuTLS.
Ah, apparently I misremembered the location, see: https://plus.google.com/+HowardChu/posts/RGBXrLTh7oG
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org