[389-users] Start TLS and 389 Directory

Fri Sep 28 15:46:02 UTC 2012

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120928/e3f8d463/attachment.html>