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

Reply via email to