> > Date: Wed, 11 Jan 2006 10:36:19 -0800 (PST) From: Susan > <logastellus@yahoo.com> >>> > > I thought I needed the cacert line in /etc/openldap/ldap.conf to point the >>> > > ldap client to the CA cert we trust, otherwise we might not trust the >>> > > server certificate being signed by the CA. >>> > > >>> > > Thanks again, >>> > > Jo >>> > > >>> >> > That''s correct, you always need the CA cert on all of the servers and >> > clients. (Unless you''re using anonymous cipher suites, in which case you >> > don''t need any certs at all. But that''s pretty reckless.) >> > > I have server-side, self-generated, self-signed certs. None of those certs exist on any of the > clients, all my ldap traffic is ssl-encrypted over 636, no problem. Is that what you mean by > "anonymous cipher suites"? If so, why is that reckless? I don''t really care if the clients > misrepresent themselves, I just care that the server doesn''t. > > Perhaps I''m not understanding what you are saying....? >Stop for a moment and think that through. If you don''t configure the client with a set of CAs to trust, then the only way to make the TLS handshake work is to tell the client not to attempt to verify the server''s cert at all. That means any server can present any ol'' made up certificate, claiming to be any entity, and the client will just blindly trust it. In other words, you have absolutely zero assurance that the server hasn''t misrepresented itself. If someone sets up a malicious server on your network spoofing the real server, you will never know - you''ll have no way to know. Anonymous cipher suites are a separate topic; with those, no certificates are exchanged at all, so you only establish encryption, not server (or client) authentication. In OpenSSL they''re disabled by default. Enabling them is generally a bad idea, they amount to the same as the above. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
--- Howard Chu <hyc@symas.com> wrote:> Stop for a moment and think that through. If you don''t configure the > client with a set of CAs to trust, then the only way to make the TLS > handshake work is to tell the client not to attempt to verify the > server''s cert at all. That means any server can present any ol'' made up > certificate, claiming to be any entity, and the client will just blindly > trust it.oops, you''re right, I didn''t think that through. Of course. it just seems that managing CA certs on the clients would be a real pain. Besides, is there any way within this whole FDS framework to revoke Certs? If the ldap server is compromised, how do I tell the clients not to trust it (or the CA or both) anymore??? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Susan wrote:>--- Howard Chu <hyc@symas.com> wrote: > > > >>Stop for a moment and think that through. If you don''t configure the >>client with a set of CAs to trust, then the only way to make the TLS >>handshake work is to tell the client not to attempt to verify the >>server''s cert at all. That means any server can present any ol'' made up >>certificate, claiming to be any entity, and the client will just blindly >>trust it. >> >> > > >oops, you''re right, I didn''t think that through. Of course. > >it just seems that managing CA certs on the clients would be a real pain. > >Indeed it is, if you have to update thousands of clients with the CA cert. But then, if you have such a large deployment, you will probably find it beneficial to apply for a real CA cert from Verisign or some such, and use a real CA. <shameless_plug_for_RHCS> Red Hat Certificate System has support for web based cert issuance. It supports CRL generation and has an OCSP responder. It can generate certs and automatically publish them to an LDAP server (e.g. to generate the userCertificate attribute for users). </shameless_plug_for_RHCS>>Besides, is there any way within this whole FDS framework to revoke Certs? >This issue is outside of Fedora DS. It''s more of an issue with your PK infrastructure and your CA.>If the ldap server is >compromised, how do I tell the clients not to trust it (or the CA or both) anymore??? > >Revoke the cert on the CA, and have the CA generate a CRL. Then, push out this CRL to all of your clients. I''m not sure how to do this with openssl, but NSS provides a command line tool called crlutil that can be used to install a CRL into your cert database. Mozilla/Firefox/Thunderbird can do this automatically. For client programs such as email clients and web browsers, who just want to check the status of the server cert, they can use OCSP (if your CA supports it). I don''t know if there is widespread support for OCSP - mozilla/firefox/thunderbird supports it, but I don''t know about other client apps. OCSP is not good for server apps which need to validate client certs, especially if under any sort of load at all. For this, the server really needs the CRL. Our mod_nss author was also working on an Apache module which would automatically pull down CRLs from the CA using http(s) or ldap(s). We might be able to do something like that for Fedora DS. We proposed it as a feature a couple of years ago, but it was shot down because no customer asked for it.>__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > >-- >Fedora-directory-users mailing list >Fedora-directory-users@redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-users > >