Hi Dave, Now I understood the certificate internals. In mycode, SSL_CTX_load_verify_locations and SSL_CTX_set_client_CA_list(soap->ctx, SSL_load_client_CA_file(soap->cafile)), these 2 calls are passed with servercert.pem and clientcert.pem files in soap->cafile parameter . And I grabbed soap->cafile and soap->capath from soap_ssl_server_context & soap_ssl_client_context calls, inturn these two calls reading from my own defined xml schema.
Instead we should pass their respective CA file, i.e., cacert.pem, this is what I understood, clear me if Iam wrong. If we pass cacert.pem file in these, which call in openssl library will load the servercert.pem and clientcert.pem files, because these are 2 files client and server has to pass eachother in handshake ? Please let me know. Thanks, Pradeep. Dave Thompson-5 wrote: > >> From: owner-openssl-...@openssl.org On Behalf Of pradeepreddy >> Sent: Friday, 17 September, 2010 12:45 > >> Hi Dave, Nevere mind, >> > [using gsoap; after fixing socket NBIO=nonblocking] > >> I think I got the answer.Server certificate and client certificate are >> exchanged in handshake. >> > Yes the certificate(s) are sent in the handshake, and verified. > It isn't always symmetric; if you use only server-auth, then > the server-cert is sent to the client but no client-cert is sent. > In your case you want client-auth, so both are sent. > >> Instead of giving the same root certificate cacert.pem I have given >> clientcert.pem and servercert.pem in soap_ssl_client_context() and >> soap_ssl_server_context() calls respectively. >> This time Handshake is failed with below error at client >> side:"error:14090086:lib(20):func(144):reason(134)" >> and server side "error:14094418:lib(20):func(148):reason(1048)" >> > 14090086->:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > Most likely (99%) this means the client=verifier didn't have access > the the issuing CAcert. (Verifying needs only the cert not the key.) > Does gsoap-client have an option or attribute or call or something > to specify a "CAfile" and/or "CApath" or similar, and if so did you > use it with the right value(s) which is (a copy of) the cacert.pem > file, or a directory containing that file with a hash-link? > > Theoretically it could also occur if the verifier does have > the CAcert but the entity cert has been damaged or tampered. > From what you say it seems that you are fully controlling both > ends of this connection at least for now so tamper is out, and > while you could conceivably have damaged the file(s), to break > the signature without ruining the encoding would take some skill > or incredibly bad luck, so let's ignore that. > > For verify errors, you can get some more info by setting a > verify callback routine that logs, but I don't know if that > is easy or even possible in the software you're using. > > 14094418->:SSL3_READ_BYTES:tlsv1 alert unknown ca > > This is a result of the previous error. Since the client couldn't > verify the server cert, it told the server to abort the handshake. > > Once you get past this error, since you want client-auth, you > will probably have the same issue at the server -- it needs the > CAcert file or path to verify the _client_ cert. In your case > that is the same CAcert because you used one CAcert+key to > generate both entity certs; in general it could be different. > >> But both client certificate and server certificate are >> generated from root >> certificate "cacert.pem" below comands. >> <snip x509 -req x2> > > More precisely, from the two requests (which include the entity > identities and keys) under the CAcert _plus CAKEY_. > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > > -- View this message in context: http://old.nabble.com/OPENSSL-SSL_Connect-blocking-tp29708086p29759267.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org