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(a)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(a)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(a)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(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
>>>
>>
>>
>> --
>> 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