On Fri, Nov 14, 2008 at 4:46 PM, Michael Simms <[EMAIL PROTECTED]> wrote: > Dave Thompson wrote: >> IF you want authentication of the client, which is optional, >> conversely the client has a cert from/by a CA (possibly the same, >> possibly a different CA) for its pregenerated key; the server >> is configured with at least the CA cert matching that CA key; >> server (is set and) requests a client cert; client sends its >> cert (and signature) which server verifies under CA cert. >> (For a general client like a web-browser dealing with various >> servers, which may accept different CAs, the selection of the >> cert and matching key to use is often interactive. If you are >> dealing only with a single known server you can pre-set it.) > > In this instance the client verifying is more important than the > server, as this is the client verifying to the server that they are > who they claim to be, the server is always known-good.
A key without a certificate is completely meaningless in the grand scheme of things (such a key is never used for verification, and the SSL/TLS protocols handle generating the secure generation of keying material necessary for the symmetric cipher). The RSA key generation process, in the scheme of SSL/TLS, should be done once for each certificate you need. This unit test you're describing is not designed properly, and in most circumstances will fail when the code it's testing is designed and written properly. The reason is because there's a prerequisite to the test that is not being met. If I were in your shoes, I would create a developmental CA, copy the private key for it to each test system, install that CA certificate to each test harness's 'load_verify_locations' locations, create serial numbers that each test system can assign such that no serial number will ever be issued twice, and ensure that part of your test preflight includes the generation (or at least installation) of server or client keys/certs, as appropriate. Your test postflight (in the event that it passes properly) should include the removal of those keys/certs. (The idea being that a test is supposed to match the production configuration as closely as possible, and since all systems involved will have certs from the same CA, the tests must use certs from the same CA.) Also important to realize: under most circumstances, the server must present its own certificate and authenticate to the client before the client will be willing to authenticate to the server. So, it doesn't matter if the server is always known-good, the threat model is that the server may fail authentication and so the client doesn't reveal any information at all. (This is why the server must have a valid certificate.) Good luck! -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
