Steven Jones wrote: > Hi, > > Ahhhh, I made good notes as I went along and I think can see my error, > > ============ > 7. Generate the server certificate: > ../shared/bin/certutil -S -n "Server-Cert" -s \ > "cn=vuw.ac.nz" -c "CA certificate" -t "u,u,u" -m 1001 -v \ > 120 -d . -z noise.txt -f pwdfile.txt > ============ > > cn should have been "vuwunicvfdsm001.vuw.ac.nz" and not "vuw.ac.nz"..... > > RHAS4 cannot check too closely as it seems to be working, for Debian and > RHAS5 not.... > > So, if I have multiple LDAP [master] servers each LDAP server's key > needs installing on the client? No, only the CA cert. An SSL client only needs the CA cert. > Slaves as well? > Each server will need its own server cert and key, and the CA cert. > I though of a DNS issue but that looks OK. > > Thanks, > > Steven Jones > Senior Linux/Unix/San/Vmware System Administrator > APG -Technology Integration Team > Victoria University of Wellington > Phone: +64 4 463 6272 > > -----Original Message----- > From: fedora-directory-users-bounces at redhat.com > [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Richard > Megginson > Sent: Wednesday, 19 September 2007 2:40 a.m. > To: General discussion list for the Fedora Directory server project. > Subject: Re: getting sh on RHAS5 to work with > FDS. > > Steven Jones wrote: > >> An "improved" ldap.conf (with no ssl/TLS) for RHAS5 >> >> =============== >> >> # http://www.padl.com >> >> base dc=vuw,dc=ac,dc=nz >> >> pam_password md5 >> >> BASE dc=vuw,dc=ac,dc=nz >> >> TLS_REQCERT never >> >> uri ldap://ldap.vuw.ac.nz/ >> >> ssl no >> >> tls_cacertdir /etc/openldap/cacerts >> >> =============== >> >> Trying TLS with, >> >> =============== >> >> #ssl setup >> >> # http://www.padl.com >> >> base dc=vuw,dc=ac,dc=nz >> >> pam_password md5 >> >> BASE dc=vuw,dc=ac,dc=nz >> >> TLS_REQCERT allow >> >> #TLS_REQCERT never >> >> host ldap.vuw.ac.nz >> >> ssl start_tls >> >> uri ldap://ldap.vuw.ac.nz/ >> >> tls_cacertdir /etc/openldap/cacerts >> >> =============== >> >> Produces this error, >> >> [root at vuwunicoadmin01 etc]# ldapsearch -x -ZZ '(uid=jonesst1)' >> >> ldap_start_tls: Connect error (-11) >> >> additional info: TLS: hostname does not match CN in peer certificate >> >> Which is an interesting error..... >> >> > Yes, very. > http://directory.fedoraproject.org/wiki/Howto:SSL#Basic_Steps > <quote> > > NOTE - *Do not use cn=server-cert for your server certificate*. In step > 7 of the linked instructions, it says to use certutil .... -s > cn=server-cert - this will cause clients to fail to validate the cert. > Instead, you must use the fully qualified domain name of your server > host as the value of the cn attribute in the subject DN. For example, if > > your directory server hostname is foo.example.com, use > > ../shared/bin/certutil -S -n "Server-Cert" -s cn=foo.example.com -c "CA > certificate" \ > -t "u,u,u" -m 1001 -v 120 -d . -z noise.txt -f pwdfile.txt > > to generate your server cert. This is the minimum. You may wish to > provide your clients with more details about your server. For more > information, see RFC 1485 <http://www.ietf.org/rfc/rfc1485.txt>. You > could choose to specify the subject DN like this: > > ../shared/bin/certutil ... -s > "cn=foo.example.com,ou=engineering,o=example corp,c=us" ... > > </quote> > > Note that this also means that if you use cn=foo.example.com, clients > must be able to resolve the server's IP address to "foo.example.com". If > > you don't care/can't do this, then use TLS_REQCERT never in your > /etc/openldap/ldap.conf to make ldapsearch stop complaining. I highly > recommend you do not do this though. > >> regards >> >> Steven >> >> >> > ------------------------------------------------------------------------ > >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20070919/ea332f1b/attachment.bin