Joel, you seem to be a bit confused about PKI matters, and among others what's considered private and what's considered public.
Let me start with the private vs. public part: private keys are designed to be kept private by the owner. Certificates (which contain the public key) are designed to be public and to be given out to anyone who needs it or is interested. Also, a small detail: CA certificates aren't used to sign with, the private keys are. You use CA certificates to validate a signature in any certificate issued by that CA (this puts it simply, since there are other data that are checked between certificates, but the signature check is still the most important thing). Now, the way things work with a X.509/PKIX flavor of PKI, you validate a certificate (any kind of certificate, be it a user certificate, a server certificate or whatever kind of certificate we're able to invent) by checking it against an issuing cerificate (a CA certificate), among others by checking that the signature in the current certificate can be verified using the public key in the issuing certificate. This is done all the way to the top (the root certificate). To be able to do a proper certificate validation, you therefore need all the certificates in the chain, from the certificate you want to validate to the root certificate that starts (or ends, depending on your point of view) the chain. This holds true for anyone who needs to validate your server certificate as well as any certificate your server needs to validate. So, to directly answer your questions: rees> What I'm trying to ask, if I can get it right this time, is rees> whether a root CA will be passing its own self-signed rees> certificate out. Yes, in one form or another. rees> I think I've figured it out, by the way. In the case of the web rees> server, the self-signed certificate is not intended for rees> certifying the web site, but for certifying the certificate(s) rees> of (a) web site(s), which is why two are necessary. That's correct. Those aren't two CA certificates, though. The root certificate is the CA certificate, while the server certificate is a EE (End Entity) certificate. You confused the matter for yourself earlier by talking about "two CA certificates". rees> But in the case of a CA, the certificate is for signing rees> certificates for other CAs and won't be given out otherwise. But rees> it would be given out with the signed certificates for the rees> subordinate CAs. This is confusing. Either you're publishing a certificate or you aren't. It doesn't matter if it's bundled with subordinate certificates or not. And either way, if you want others to be able to validate a certificate issued by the subordinate CAs, you need to publish the root CA certificate as well. rees> But if the root CA machine is also signing server certificates rees> (which it should not, but that's another story), it should have rees> a separate certificate for signing certificates for servers. rees> Should also have a separate piece of the directory tree to do it rees> in. You are confusing the matter. It seems like you're saying the CA should split in two, one that signs subordinate CAs and one that signs your server certificate. Now, the question is, when you split that CA in two, are you actually creating an entirely different CA that uses the same key, or are you in fact creating another subordinate CA (using the same key?)? You might want to draw a tree that shows how the root CA, subordinate CAs and other entities are related to each other. A picture does say more than a thousand words, and I've already spent a few hundred of them :-). Cheers, Richard ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
