[Techtalk] debian slapd and gnutls
Linda de Boer
ldb at swmbo.ca
Fri Mar 27 13:31:24 UTC 2009
Maria McKinley wrote:
> I have been trying to get ldap to work with tls for a while, and have
> been having a hard time. When I have the certificate info in slapd.conf,
> slapd refuses to start, giving me the error:
>
> main: TLS init def ctx failed: -1
>
> With the certificate lines commented out, slapd starts with no problem,
> of course. I've done a bunch of poking about, and the problem seems to
> be related to the change in the way slapd is built in debian. With
> Lenny, debian slapd is built with libgnutls instead of openssl.
> Unfortunately, all of the instructions I can find for setting up
> certificates for debian slapd use openssl. How do I get certificates
> made with openssl to work with slapd now that it is build with
> libgnutls, or is there another way to make certificates now? And how do
> I verify that my certificates are built correctly using libgnutls? It
> seems to be set up correctly, but I'm not sure how to test the
> certificates themselves:
>
> test:/etc/ssl/certs# gnutls-cli -l :High
> Cipher suites:
> TLS_ANON_DH_ARCFOUR_MD5 0x00, 0x18 SSL3.0
> TLS_ANON_DH_3DES_EDE_CBC_SHA1 0x00, 0x1b SSL3.0
> TLS_ANON_DH_AES_128_CBC_SHA1 0x00, 0x34 SSL3.0
> TLS_ANON_DH_AES_256_CBC_SHA1 0x00, 0x3a SSL3.0
> TLS_ANON_DH_CAMELLIA_128_CBC_SHA1 0x00, 0x46 TLS1.0
> TLS_ANON_DH_CAMELLIA_256_CBC_SHA1 0x00, 0x89 TLS1.0
> TLS_PSK_SHA_ARCFOUR_SHA1 0x00, 0x8a TLS1.0
> TLS_PSK_SHA_3DES_EDE_CBC_SHA1 0x00, 0x8b TLS1.0
> TLS_PSK_SHA_AES_128_CBC_SHA1 0x00, 0x8c TLS1.0
> TLS_PSK_SHA_AES_256_CBC_SHA1 0x00, 0x8d TLS1.0
> TLS_DHE_PSK_SHA_ARCFOUR_SHA1 0x00, 0x8e TLS1.0
> TLS_DHE_PSK_SHA_3DES_EDE_CBC_SHA1 0x00, 0x8f TLS1.0
> TLS_DHE_PSK_SHA_AES_128_CBC_SHA1 0x00, 0x90 TLS1.0
> TLS_DHE_PSK_SHA_AES_256_CBC_SHA1 0x00, 0x91 TLS1.0
> TLS_SRP_SHA_3DES_EDE_CBC_SHA1 0xc0, 0x1a TLS1.0
> TLS_SRP_SHA_AES_128_CBC_SHA1 0xc0, 0x1d TLS1.0
> TLS_SRP_SHA_AES_256_CBC_SHA1 0xc0, 0x20 TLS1.0
> TLS_SRP_SHA_DSS_3DES_EDE_CBC_SHA1 0xc0, 0x1c TLS1.0
> TLS_SRP_SHA_RSA_3DES_EDE_CBC_SHA1 0xc0, 0x1b TLS1.0
> TLS_SRP_SHA_DSS_AES_128_CBC_SHA1 0xc0, 0x1f TLS1.0
> TLS_SRP_SHA_RSA_AES_128_CBC_SHA1 0xc0, 0x1e TLS1.0
> TLS_SRP_SHA_DSS_AES_256_CBC_SHA1 0xc0, 0x22 TLS1.0
> TLS_SRP_SHA_RSA_AES_256_CBC_SHA1 0xc0, 0x21 TLS1.0
> TLS_DHE_DSS_ARCFOUR_SHA1 0x00, 0x66 TLS1.0
> TLS_DHE_DSS_3DES_EDE_CBC_SHA1 0x00, 0x13 SSL3.0
> TLS_DHE_DSS_AES_128_CBC_SHA1 0x00, 0x32 SSL3.0
> TLS_DHE_DSS_AES_256_CBC_SHA1 0x00, 0x38 SSL3.0
> TLS_DHE_DSS_CAMELLIA_128_CBC_SHA1 0x00, 0x44 TLS1.0
> TLS_DHE_DSS_CAMELLIA_256_CBC_SHA1 0x00, 0x87 TLS1.0
> TLS_DHE_RSA_3DES_EDE_CBC_SHA1 0x00, 0x16 SSL3.0
> TLS_DHE_RSA_AES_128_CBC_SHA1 0x00, 0x33 SSL3.0
> TLS_DHE_RSA_AES_256_CBC_SHA1 0x00, 0x39 SSL3.0
> TLS_DHE_RSA_CAMELLIA_128_CBC_SHA1 0x00, 0x45 TLS1.0
> TLS_DHE_RSA_CAMELLIA_256_CBC_SHA1 0x00, 0x88 TLS1.0
> TLS_RSA_NULL_MD5 0x00, 0x01 SSL3.0
> TLS_RSA_EXPORT_ARCFOUR_40_MD5 0x00, 0x03 SSL3.0
> TLS_RSA_ARCFOUR_SHA1 0x00, 0x05 SSL3.0
> TLS_RSA_ARCFOUR_MD5 0x00, 0x04 SSL3.0
> TLS_RSA_3DES_EDE_CBC_SHA1 0x00, 0x0a SSL3.0
> TLS_RSA_AES_128_CBC_SHA1 0x00, 0x2f SSL3.0
> TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 SSL3.0
> TLS_RSA_CAMELLIA_128_CBC_SHA1 0x00, 0x41 TLS1.0
> TLS_RSA_CAMELLIA_256_CBC_SHA1 0x00, 0x84 TLS1.0
> Certificate types: X.509, OPENPGP
> Protocols: SSL3.0, TLS1.0, TLS1.1, TLS1.2
> Ciphers: AES-256-CBC, AES-128-CBC, 3DES-CBC, DES-CBC, ARCFOUR-128,
> ARCFOUR-40, RC2-40, CAMELLIA-256-CBC, CAMELLIA-128-CBC, NULL
> MACs: SHA1, MD5, SHA256, SHA384, SHA512, MD2, RIPEMD160, NULL
> Key exchange algorithms: ANON-DH, RSA, RSA-EXPORT, DHE-RSA, DHE-DSS,
> SRP-DSS, SRP-RSA, SRP, PSK, DHE-PSK
> Compression: DEFLATE, NULL
>
>
> Thank you,
> maria
> _______________________________________________
> Techtalk mailing list
> Techtalk at linuxchix.org
> http://mailman.linuxchix.org/mailman/listinfo/techtalk
>
G'day
The following is a "hitlist" I used to give one fellow working on
Samab/LDAP servers to help debug tls. Usually one of them gave us a good
hint as to what was going on. Hopefully this will help.
netstat -a |grep LISTEN
- if you see both port 389 (ldap) as well as port 636 (ldaps) it
is running.
openssl s_client -connect localhost:636 -showcerts
- basically tests the ssl connection and certs
getent passwd - should show you both the /etc/passwd and ldap users if
everything is running okay.
- To start the ldap logging, which uses the syslog facility. Add the
following line to /etc/syslog.conf. Put in a comment for future ref.
# LDAP logging entry
local4.* /var/log/ldap.log
slapd -f slapd.conf -d2047 -h "ldap:/// ldaps:///"
ldapsearch -H ldaps://localhost -b "cn=DavidB,dc=hudson,dc=com"
"(objectclass=*)"
# only if using ssl
openssl s_client -connect localhost:636 -state -CAfile
/etc/pki/tls/certs/openldap/ca-bundle.crt | les
s
ldapsearch -Z -v -x -h localhost -b
"dc=ldapsrv,dc=in,dc=localdomain,dc=local" -s sub "objectclass=*
"
# simple search
- use of the ldapsearch "-x" option is to use "simple bind" LDAP v2 does
not support SASL. You need to
use a simple bind with TLS or IPSEC in place for security.
#The following command will display everything in the LDAP directory
currently.
ldapsearch -v -x -h localhost -b
"dc=ldapsrv,dc=in,dc=localdomain,dc=local" -s sub "objectclass=*"
ldapsearch -v -x -h localhost -D
"cn=Manager,dc=ldapsrv,dc=in,dc=localdomain,dc=local" -s sub "obje
ctclass=*" -W
--
ldb
More information about the Techtalk
mailing list