Here's the output from ldapsearch (I sanitized the domains). Note that for
the cacert I used "ROOT CA" for the CN of the certificate. I guess the
next step is to try to set this to the hostname of ldap01?
####################################################
####################################################
####################################################
root@ldap02 ~]# cat /etc/openldap/ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example, dc=com
#URI
ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
#URI ldap://127.0.0.1/
#BASE dc=example,dc=com
#TLS_CACERTDIR /etc/openldap/cacerts
TLS_CACERTDIR /tmp/ldap/certs
#TLS_REQCERT never
####################################################
####################################################
####################################################
[root@ldap02 ldap]# ldapsearch -x -h
ldap01.<mydomain>.com -D "cn=Directory
Manager" -W -b "dc=mydomain,dc=com" -d 1 -ZZ ""
ldap_create
ldap_url_parse_ext(ldap://ldap01.mydomain.com)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap01.mydomain.com:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.163.121.194:389
ldap_connect_timeout: fd: 3 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush: 31 bytes to sd 3
ldap_result ld 0x14890770 msgid 1
wait4msg ld 0x14890770 msgid 1 (infinite timeout)
wait4msg continue ld 0x14890770 msgid 1 all 1
** ld 0x14890770 Connections:
* host:
ldap01.mydomain.com port: 389 (default)
refcnt: 2 status: Connected
last used: Fri Sep 28 09:16:51 2012
** ld 0x14890770 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
** ld 0x14890770 Response Queue:
Empty
ldap_chkResponseList ld 0x14890770 msgid 1 all 1
ldap_chkResponseList returns ld 0x14890770 NULL
ldap_int_select
read1msg: ld 0x14890770 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 95 contents:
read1msg: ld 0x14890770 msgid 1 message type extended-result
ber_scanf fmt ({eaa) ber:
read1msg: ld 0x14890770 0 new referrals
read1msg: mark request completed, ld 0x14890770 msgid 1
request done: ld 0x14890770 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_extended_result
ber_scanf fmt ({eaa) ber:
ber_scanf fmt (a) ber:
ldap_parse_result
ber_scanf fmt ({iaa) ber:
ber_scanf fmt (x) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 1, err: 19, subject:
/C=US/ST=California/L=Burbank/O=mydomain/OU=ADS/CN=ROOT CA, issuer:
/C=US/ST=California/L=Burbank/O=mydomain/OU=ADS/CN=ROOT CA
TLS certificate verification: Error, self signed certificate in certificate
chain
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS: can't connect.
ldap_perror
ldap_start_tls: Connect error (-11)
additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
On Fri, Sep 28, 2012 at 8:46 AM, Grzegorz Dwornicki <gd1100(a)gmail.com>wrote:
I was thinking about server cert but I usually put fqdn in every
certificate I made.
This is intersting problem. Can you provide output of ldapsearch with
debug plus contents of /etc/openldap/ldap.conf?
Greg.
28 wrz 2012 17:20, "Kyle Flavin" <kyle.flavin(a)gmail.com> napisał(a):
I tried both tls_cacert and tls_cacertdir, same result. I think it's
> still encrypting when I set tls_reqcert to never, because ldapsearch with
> -d 1 indicates it's still doing the Start TLS negotiation, and dsniff
> doesn't seem to pick up the password when I add the "-ZZ" (it grabs the
pw
> when I leave that off). Maybe dnsiff just doesn't "speak" Start TLS
> though, and I need to look at it with wireshark to make sure the password
> isn't in cleartext...
>
> Hmm, I don't think I set the CN of the cacert to the hostname. Does it
> matter if I generate multiple certs for the same host using the same
> hostname for the CN? I'm using self signed certs. The server.cert which I
> generated for the directory server uses the hostname for its CN so I didn't
> want duplicates. I just set CN of the cacert to "ROOT CA" I think. Also,
> apparently I need to generate yet another cert for the admin server. I
> wanted to just reuse my server.cert from the directory server in both
> places, but 389 isn't letting me do that (it says the cert was generated by
> another host). This would mean I'd need yet a third certificate with a CN
> set to the hostname of this same server. Again, not sure if this is a
> problem...
>
>
>
> On Thu, Sep 27, 2012 at 11:56 PM, Grzegorz Dwornicki <gd1100(a)gmail.com>wrote:
>
>> maybe tls_reqcert never forces non ssl or it forces no ssl checks. As
>> You know for example hostname must be present and valid DNS domain in CN
>> field of certficace or session will fail.
>>
>> Have you tried using tls_cacert insted of cacertdir? I am writing this
>> without manuals soo I am not sure: tls_cacert or tls_cacertfile
>>
>> I have learned when you have just one ca, then tls_cacertdir sometimes
>> did not work as I thought it would. It did not work at all for me.
>>
>> Greg.
>> 28 wrz 2012 07:28, "Kyle Flavin" <kyle.flavin(a)gmail.com>
napisał(a):
>>
>> Yeah -- So what I did is drop cacert.asc under /tmp/ldap/certs for
>>> testing purposes. I then added a line "TLS_CACERTDIR
/tmp/ldap/certs" to
>>> /etc/openldap/ldap.conf. The logs on the directory server (and from adding
>>> a -d 1 option to ldapsearch) indicated that the client was rejecting the
>>> certificate. So I used certutil with cacert.asc to create the cert8.db and
>>> key3.db files under /tmp/ldap/certs (I now have cacert.asc, cert8.db,
>>> key3.db, and secmod.db under that directory). Same result. Then I went
>>> back to /etc/openldap/ldap.conf and set "TLS_REQCERT never", and
commented
>>> out the cacertdir directive. With that configuration, ldapsearch works
>>> with the -ZZ options. So for some reason, it isn't liking my CA cert,
and
>>> I'm not sure why.
>>>
>>>
>>> On Thu, Sep 27, 2012 at 9:46 PM, Grzegorz Dwornicki
<gd1100(a)gmail.com>wrote:
>>>
>>>> Did you install ca.cert on system and setup /etc/openldap/ldap.conf ?
>>>>
>>>> Greg.
>>>> 28 wrz 2012 05:11, "Kyle Flavin" <kyle.flavin(a)gmail.com>
napisał(a):
>>>>
>>>>> Hi, I've been struggling to setup 389 Directory server with
Start
>>>>> TLS.
>>>>>
>>>>> I have a multi-master replication working with four server. From an
>>>>> external client running openldap's ldapsearch, I'm trying to
do the
>>>>> following:
>>>>>
>>>>> ldapsearch -ZZ -x -h "myserver" -b
"dc=example,dc=com" -D
>>>>> "cn=Directory Manager" -W ""
>>>>>
>>>>> I get an unsupported protocol error on servers that do not have
>>>>> certificates installed.
>>>>>
>>>>> In an attempt to resolve this, I tried to install a self-signed
>>>>> cert. I created a ca.cert and a server.crt, and imported them into
the
>>>>> Directory Server. I then imported the ca.cert to the admin server.
When I
>>>>> attempted to import the same server.crt to the admin server, I got an
error
>>>>> message stating the certificate was for another host. Since the
admin
>>>>> server and directory server reside on the same host, if I generate a
new
>>>>> request, it will have an identical host name (I'm not sure if
that's
>>>>> relevant to my issue). After all of that, I now receive a
"Connect Error
>>>>> SSL3_GET_SERVER_CERTIFICATE:certificate verify failed". I'm
guessing I
>>>>> need to import the root cert onto the client somehow, but I'm not
sure how
>>>>> to go about doing that.
>>>>>
>>>>> This has become pretty time consuming, so I was hoping that someone
>>>>> more knowledgeable could confirm that I'm at least travelling
down the
>>>>> right path. I've been following this Red Hat document:
>>>>>
>>>>>
>>>>>
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9...
>>>>>
>>>>> Thanks,
>>>>> Kyle
>>>>>
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users(a)lists.fedoraproject.org
>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>
>>>> --
>>>> 389 users mailing list
>>>> 389-users(a)lists.fedoraproject.org
>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>
>>>
>>> --
>>> 389 users mailing list
>>> 389-users(a)lists.fedoraproject.org
>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>
>> --
>> 389 users mailing list
>> 389-users(a)lists.fedoraproject.org
>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>
>
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users