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@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@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@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@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@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@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@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@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@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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users