Here are the current TLS settings in the indicated files (I took out some
comments to make reading easier):
# grep -i tls /etc/ldap.conf /etc/openldap/ldap.conf
/etc/openldap/slapd.conf
/etc/ldap.conf:ssl start_tls
/etc/ldap.conf:tls_checkpeer yes
/etc/ldap.conf:# At least one of these are required if tls_checkpeer is
"yes"
/etc/ldap.conf:#tls_cacertfile /etc/ssl/ca.cert
/etc/ldap.conf:#tls_cacertdir /etc/ssl/certs
/etc/ldap.conf:#tls_randfile /var/run/egd-pool
/etc/ldap.conf:#tls_ciphers TLSv1
/etc/ldap.conf:#tls_cert
/etc/ldap.conf:#tls_key
/etc/ldap.conf:tls_cacertdir /etc/openldap/cacerts
/etc/openldap/ldap.conf:TLS_REQCERT allow
/etc/openldap/ldap.conf:TLS_CACERTDIR /etc/openldap/cacerts
/etc/openldap/slapd.conf:# TLSCACertificateFile
/usr/share/ssl/certs/ca-bundle.crt
/etc/openldap/slapd.conf:TLSCipherSuite HIGH:MEDIUM
/etc/openldap/slapd.conf:TLSCertificateFile
/usr/share/ssl/certs/slapd.pem
/etc/openldap/slapd.conf:TLSCertificateKeyFile
/usr/share/ssl/certs/slapd.pem
/etc/openldap/slapd.conf:TLSCACertificateFile
/usr/share/ssl/certs/ca-bundle.crt
/etc/openldap/slapd.conf:#replica host=dome.sdc.cs.boeing.com:389
starttls=critical
Here are the pam and nss config files (many comments deleted):
[EMAIL PROTECTED] supportFolio]$ cat /etc/pam_smb.conf
Workgroup
None
[EMAIL PROTECTED] supportFolio]$ cat /etc/nsswitch.conf
passwd: files ldap
shadow: files ldap
group: files ldap
#hosts: db files ldap nis dns
hosts: files dns
# Example - obey only what ldap tells us...
#services: ldap [NOTFOUND=return] files
#networks: ldap [NOTFOUND=return] files
#protocols: ldap [NOTFOUND=return] files
#rpc: ldap [NOTFOUND=return] files
#ethers: ldap [NOTFOUND=return] files
bootparams: files
ethers: files
netmasks: files
networks: files
protocols: files ldap
rpc: files
services: files ldap
netgroup: files ldap
publickey: files
automount: files ldap
aliases: files
> --On Wednesday, August 22, 2007 8:33 PM -0400 Chuck Keagle
> <[EMAIL PROTECTED]> wrote:
>
>
> > The startTLS option to ldapsearch indicates TLS was working fine. The
> > only difference in the output between not using -ZZ and using -ZZ is the
> > search result. With -ZZ, search: 3. Without -ZZ, search: 2. However,
> > the ldap.log file shows the following error I would like to better
> > understand:
> >
> > Aug 22 17:23:40 denali slapd[30178]: connection_read(12): unable to get
> > TLS client DN error=49 id=3536
>
> That's an interesting error, which I've never seen before. Can you print
> out the text information of the cert the ldap server is using?
Any general user can see certificate /etc/openldap/cacerts/CA.pem.
I figured you weren't asking for the cert it is using.
I tried using openssl ca to get key ifno.
[EMAIL PROTECTED] ~]# openssl ca
Using configuration from /usr/share/ssl/openssl.cnf
Error opening CA private key ./demoCA/private/cakey.pem
7975:error:02001002:system library:fopen:No such file or
directory:bss_file.c:259:fopen('./demoCA/private/cakey.pem','r')
7975:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:261:
unable to load CA private key
demoCA does not exist anywhere under /usr/share.
Also tried:
openssl ocsp -issuer /etc/openldap/cacerts/CA.pem
openssl ocsp -CA /etc/openldap/cacerts
openssl ocsp -cert /etc/openldap/cacerts/CA.pem
openssl ocsp -CApath /etc/openldap/cacerts
but didn't get the syntax right for the command to complete without
spitting out the help message. Pretty new here.
I'm thinking there might be a misconfigration here but would like to
confirm it.
It looks like I'm telling ldap to use /etc/openldap/cacerts/CA.pem but
telling slapd to use /usr/share/ssl/certs/slapd.pem for certificates.
Then openssl uses a different certificate that may not exist. Should they
all use the same certificate or does each get it's own?
More sleuthing info would be very helpful here.
Thank you, Quanah for helping me gain knowledge and insight here.
>
> > It seems to be logged once per ldapsearch -ZZ -x but not during the
> > ldapsearch -x.
>
> Well, just plain -x doesn't touch TLS at all, so I'm not surprised that it
> doesn't show a TLS only error. ;)
>
> In any case, given that the errors you are seeing between using ldapsearch
> and ssh are different, it suggests that the process initiating binds to the
> LDAP Server when ssh is used is not correctly configured to use TLS. I'd
> note that this may be in the pam_ldap and nss_ldap configuration pieces,
> which I don't see in this email thread.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
---
You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
