[389-users] Start TLS and 389 Directory

Fri Sep 28 19:21:21 UTC 2012

CN can be same for all cert but other field must be diferent. Again I have
learned this from openssl :)

Goodluck :D
Greg.
28 wrz 2012 19:17, "Kyle Flavin" <kyle.flavin at gmail.com> napisał(a):

> So how should I handle the naming of the two server certs (for the
> directory server and the admin server)?  Their DN's can't all be the same
> correct?
>
> It sounds like I will need 3 certificates (for admin server, directory
> server, and CA cert) that will look like this:
> /C=US/ST=California/L=Burbank/O=mydomain/OU=ADS/CN=ldap01.mydomain.com
>
> How do you normally handle the naming of your certs?
>
> On Fri, Sep 28, 2012 at 10:01 AM, Grzegorz Dwornicki <gd1100 at gmail.com>wrote:
>
>> There is definetly something wrong with your CA. Error is fatal and named
>> unknown CA. I agree with you now: please try put FQDN in CN field. This
>> still maybe not the issue but when you create CA cert again then maybe
>> error will disapear. I usually use openssl to create certs instead of
>> certutil soo i don't know if you will need to create every cert using shell
>> script.
>>
>> Greg.
>> 28 wrz 2012 18:24, "Kyle Flavin" <kyle.flavin at gmail.com> napisał(a):
>>
>> 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.0/html/Administration_Guide/Managing_SSL.html#Starting_the_Server_with_SSL_Enabled-Enabling_SSL_in_the_DS_Admin_Server_and_Console
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Kyle
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 389 users mailing list
>>>>>>>>> 389-users at lists.fedoraproject.org
>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 389 users mailing list
>>>>>>>> 389-users at lists.fedoraproject.org
>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 389 users mailing list
>>>>>>> 389-users at lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users at lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users at lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>
>>>> --
>>>> 389 users mailing list
>>>> 389-users at lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>
>>>
>>> --
>>> 389 users mailing list
>>> 389-users at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>
>> --
>> 389 users mailing list
>> 389-users at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120928/e6a87370/attachment.html>