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" <[email protected]> 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 <[email protected]>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" <[email protected]> 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 <[email protected]>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" <[email protected]> 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 <[email protected] >>>>> > 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" <[email protected]> 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 < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Did you install ca.cert on system and setup /etc/openldap/ldap.conf >>>>>>>> ? >>>>>>>> >>>>>>>> Greg. >>>>>>>> 28 wrz 2012 05:11, "Kyle Flavin" <[email protected]> >>>>>>>> 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 >>>>>>>>> [email protected] >>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 389 users mailing list >>>>>>>> [email protected] >>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 389 users mailing list >>>>>>> [email protected] >>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>>> >>>>>> >>>>>> -- >>>>>> 389 users mailing list >>>>>> [email protected] >>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>> >>>>> >>>>> >>>>> -- >>>>> 389 users mailing list >>>>> [email protected] >>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>> >>>> >>>> -- >>>> 389 users mailing list >>>> [email protected] >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> >>> >>> >>> -- >>> 389 users mailing list >>> [email protected] >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> >> >> -- >> 389 users mailing list >> [email protected] >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> > > > -- > 389 users mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/389-users >
-- 389 users mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/389-users
