> 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
