If I'm interpreting your question right, I think you're already covered for this as long as: - Your client apps do server cert verification. - Your internal CA isn't compromised. - Your cert/key DB files on your FDS servers haven't been compromised. You shouldn't need to sign a new certificate for every client, you just need a copy of the CA certificate on each client. Susan wrote:

Susan wrote: Yes. You go to the RHCS web interface, click "Get CA Cert Chain", and you can download or copy/paste the CA cert for use with client apps (or importing into your web browser or email program or etc.). This assumes you are using RHCS as your CA. We used this extensively at Netscape. I don't know. The only way to do this is to have a real FQDN as the cn of your server cert subject DN. When the server presents its cert during the SSL handshake, the client can verify that the CA (whose cert you have in the client cert db) signed the server's cert, and that the hostname in subject DN in the server cert corresponds to the hostname that the server is on (reverse DNS lookup of the IP address of the server). Do you mean client cert auth? CA certs or client certs? For the CA cert problem, AFAIK, there is no way around it - you have to configure your clients to trust your CA one way or another. You can mitigate this somewhat by going through the process of getting a real CA cert from one of the trusted root CAs listed in your web browser or email client. RHCS also implements CRL generation and publishing, and also supports OCSP. One of our engineers is developing a mod_revocator Apache module which will automatically get CRLs for Apache certificate status checking (for servers and clients).

There is no standard mechanism for this. You have to manually copy CA certs to the location and in the format that each of your secure LDAP client apps expects. RedHat Linux in the past has come with a bundle of well-known CA certs in /usr/share/ssl/cert.pem. I haven't used FC4, but I'm guessing it has this too? You would still need to configure LDAP client apps to know about this file. Using PADL's pam_ldap/nss_ldap as an example, you would need to add: tls_cacertfile /usr/share/ssl/cert.pem ...to /etc/ldap.conf. Susan wrote: > --- Richard Megginson <rmeggins(a)redhat.com&gt; wrote: > > >> Susan wrote: >> >>> Hi, everyone. I think this subject has been briefly raised before but I've more questions. >>> >>> Can RHCS be used to hand out CA certs to Unix clients (linux/solaris)? >>> >>> >> Yes. You go to the RHCS web interface, click "Get CA Cert Chain", and >> you can download or copy/paste the CA cert for use with client apps (or >> importing into your web browser or email program or etc.). This assumes >> you are using RHCS as your CA. >> > > well, I'm speaking strictly of ldap clients. Browsers I don't care about. > > > >>> Has anybody done this? >>> >>> >> We used this extensively at Netscape. >> > > to automatically hand out CA certs to ldap clients upon request? > > >>> Right now no certs are >>> deployed on the clients, we're using them only for SSL traffic encryption. >>> >>> >> Do you mean client cert auth? >> > > well, no. We don't care whether the clients misrepresent themselves. We care if the FDS > misrepresents itself. > > >> CA certs or client certs? For the CA cert problem, AFAIK, there is no >> way around it - you have to configure your clients to trust your CA one >> way or another. You can mitigate this somewhat by going through the >> process of getting a real CA cert from one of the trusted root CAs >> listed in your web browser or email client. >> > > > __________________________________________________ > 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(a)redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > >

Susan wrote: Handing out CA certs to clients is simply a matter of copying the file to the client, and maybe entering it into the certificate database e.g. like the Netscape Communicator or FDS certdb. OpenSSL is a free tool with all of the capabilities which are required to run a CA. I use it for all of my CA operations. That is not a problem, it's a fact. Contrary to popular belief, self-signed CA certs are not bad when used company internal. In fact, there are many benefits compared to having all of your certs issued from a commercial CA. Commercial server certs are for when you run public internet services and don't want your customers to see certificate questions. Why would they see certificate questions? Because their applications don't come bundled with your root CA cert... When you control the network, you can deploy applications with your root CA cert already inserted, or you can simply deploy it to workstations with Tivoli or cfengine, etc. Your internal customers still don't see certificate questions. No problem. Just issue the FDS server certs from your own CA, e.g. OpenSSL. Import your own root CA cert into FDS as well. Import your own root CA cert to your clients, e.g. linux, solaris. The clients will verify the FDS cert against their copy of the root CA cert. Your clients don't need certificates, they only need a copy of your root CA cert - the same file for every client. You do not generally need to use "client authentication"; you really have to know what you are doing with PKI to know why you would want to use it. Clients generally do not need their own certs unless they are people and are doing S/MIME email. It appears that you have fundamental misunderstandings of what a PKI is and does, and I suggest that you study the subject instead of using the learn-as-you-go ad-hoc network architecture method. http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm http://www.opengroup.org/messaging/G260/pki_tutorial.htm Finally, as soon as I get time, I will update the SSL Howto. I already have all of the scripts and methods for fully automated setup up FDS with a third-party CA, namely OpenSSL. Lack of time is the only reason why I haven't yet written it up on the wiki. BR, -- mike

--- Mike Jackson <mj(a)sci.fi&gt; wrote: right, I think I was confused on that point. I meant to say that I don't want to deploy the CA cert to dozens of clients. So, forget the CRL, then... Because we have about 60 servers total. Now, /etc/openldap/cacerts/ is writable by root only and I'd have to do some serious expect/perl scripting to ssh into every machine, accept the key, su - root, scp the CA cert, log out. I really don't want to do this if I don't have to. So, are you saying I can use openSSL + linux openldap client to do this automagically? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com