> From: [EMAIL PROTECTED] On Behalf Of Michael Simms > Sent: Friday, 14 November, 2008 19:46
> Dave Thompson wrote: > >> From: [EMAIL PROTECTED] On Behalf Of Michael Simms > >> Sent: Thursday, 13 November, 2008 07:38 <snip: lists of calls> > > Are you trying to connect BOTH a client on 1 to a server on 2 AND > > a client on 2 to a server on 1 at the same time? That's unusual. > > I suggest you first get one direction at a time working. > > No, its just one directional. The application is a client-server and > sometimes the client needs to be known to the server and sometimes the > server needs to be known to the client. It is up to the user of the > library to determine which they need, and to provide valid keys for > whichever direction they need verified (or both). > This was not at all clear to me from your post. If you still have the problem, I suggest you show the chart, or other precise description, of what is being done in a SPECIFIC failure case, and its results. > > But I am deeply skeptical of you generating a new (RSA) keypair > > within a peer (server or client) program. If you don't use it, it's > > just wasted. If you do use it -- and you should need to wrap an RSA* > > in EVP_PKEY* before giving to SSL_CTX_use_PrivateKey -- you don't > > have a valid certificate for it, and it shouldn't be accepted. > > We arent verifying the self-generated keys ever. If you notice, the > verification only ever happens when the other side has a known > verifiable key. We do use EVP_PKEY but that wasnt really relavent for > the problem, the generated keys are just there for the fact that both > ends need a key of some kind, and they are for when that end doesnt > provide one to verify. > Why should both ends need keys? Not for unauthenticated SSL, if you allow ciphersuites like EDH. Are you using them for something else? > > Do you not understand the basic principle of certificates? > > The normal procedure is that the server has (and sends) a cert, > > previously obtained from a CA and signed by that CA's key, > > for the server's previously generated and stored key. > > The client has preloaded/configured at least the CA cert > > matching the CA key used to sign (issue) the server cert. > > The client thus can verify the server cert under the CA cert, > > and the server's session signature under the server cert. > > (In general, the client may have a whole set of CA certs, for > > all the CAs/CA keys that issued certs for all servers desired, > > and the server may also have and send a copy of intermediate-level > > CA certs if those are used and needed.) > > Yes, I get all that, although in this instance the certificates in > question will all be signed by ourown CA for this application. > It's fine* to have/use your own CA (or even your own hierarchy of CAs, although there's usually no point to that) but to the protocol the CA is still a different entity from the server(s) and client(s), and you must keep straight which things are done by which entities and when. (* well, assuming your CA's policies are acceptable for your usage. But that's an issue for an outside CA also, at least as much.) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
