Dave Thompson wrote: >> From: [EMAIL PROTECTED] On Behalf Of Michael Simms >> Sent: Thursday, 13 November, 2008 07:38 > >> I currently have a different problem that is stumping me. I think that >> maybe I have a gap in my knowledge that maybe someone can fill. >> I have a problem validating a connection. The sequence of events is as >> follows: >> >> System 1: System 2: >> >> Server loads CA Server loads keys >> SSL_CTX_load_verify_locations SSL_CTX_use_PrivateKey >> Server generates keypair SSL_CTX_use_certificate >> RSA_generate_key Client loads CA >> Client loads keys SSL_CTX_load_verify_locations >> SSL_CTX_use_PrivateKey Client generates keypair >> SSL_CTX_use_certificate RSA_generate_key >> Client connects/server accepts Client connects/server accepts >> SSL_accept SSL_accept >> SSL_connect SSL_connect >> (until successful) (until successful) >> >> Server verifies result Client verifies result >> SSL_get_verify_result SSL_get_verify_result >> >> X509_V_OK >> X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT >> > 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). > 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. >> In BOTH tests, the same keys and CA file were used, just on different >> sides, and so it cannot be a generation issue with the key. >> When the server has the CA, it validates the client. When the client >> has the CA, it fails for the reason shown. >> >> When both sides have the same certificate, keys, and CA, then again >> the client fails to verify. >> > Does the server actually validate, or merely accept? The default > is for the server not to request, and the client not to send, any > client cert (authentication), so there is nothing to verify. The server > has to request a client cert, as specified by SSL_CTX_set_verify(). > (And the client has to have a valid one to use and send.) I think that that is the start of my problem, I now get a different error about an unknown CA... so, that gives me something new to think on... error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca >> Am I missing something? >> >> Keys are attached for further information >> > Your servercert.pem has its Subject the same as its Issuer, > which is the same as the Subject and Issuer of your rootcert.pem. > (And no AuthorityKeyIdentifier extension.) This probably confuses > the lookup. The end-entity is supposed to be a different entity > than the CA, and thus have a different Distinguished Name. > (If you are doing the CA yourself, use the same Organization > but a different Organizational Unit and/or CommonName.) I will rectify that and see what happens. > (Also, in case you're not aware, those certs are only valid for > one month, till Nov. 29. That's probably acceptable for testing, > but rather unlikely to be sufficient for real use.) This is a unit test for an application, this is all I need for now. > 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. > 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. Thanks -- Michael Simms ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
