> For now, my purpose is not to establish and identity of a server with the > certificate. I plan to use a signed certificate, so that the client can be > sure > that the server indeed holds the private key associated with the > public key > provided by the server in its certificate.
You have a non-standard security model. The standard SSL security model has the CA sign the certificate to verify that the *name* in the certificate belongs to the key in the certificate. It is almost always a mistake to try to get commodity software to enforce a non-standard security model. That is, you can't expect programs like firefox and IE to connect to SSL servers using certificates generated with a non-standard security model and get any kind of sane behavior. It sounds like you don't need a certificate at all. You just need the server to be able to prove that it own a particular private key. Presumably this is for server persistence (so I can tell I'm talking to the same server I was last time). So I think the servers should be using self-signed certificates and the clients should be configured to accept self-signed certificates (since they don't care about being able to verifyt the common name). There is no point in having a CA at all, as I understand your problem. The only point in embedding the CA in the installer and configured the clients to trust the CA would be to all the clients to trust the common name in the certificate. But clearly the clients *can't* trust the common name in the certificate. So it seems like you're trying to solve a "problem" that's actually a design property of your security model. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
