Thanks for your reply Mr.Thompson!
I'll review my workflow and adjust it following your points.
On Thu, Sep 29, 2011 at 12:12 AM, Dave Thompson <dthomp...@prinpay.com>wrote:
> > From: owner-openssl-us...@openssl.org On Behalf Of Mauricio Klein
> > Sent: Monday, 26 September, 2011 17:15
>
> > I'm using a SOAP toolkit called gSoap and this toolkit provide
> > an interface to create SSL context.
>
> > Using tha samples released in the toolkit, i have generated the
> > certificates using the following command (under Linux):
> <snip: req -newkey and x509 -req for root-aka-cacert,client,server>
>
> To be exact you created private keys (or keypairs or just keys) AND
> corresponding certificates. These are different and both are needed.
>
> > After this, i followed all the steps to create the SSL context,
> > and the code (client and server) compiled with no warnings or errors.
>
> > But, when the client make a request, the following error is
> returned:
> > --------------------------------------------
> > SSL_ERROR_SSL
> > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
> verify failed
> > --------------------------------------------
> >
> > Am i doing something wrong while generating the certificates?
>
> No, at least not visible in your message. Conceivably the openssl.cnf
> could specify some extension that makes your cert(s) unusable for SSL, but
> I would be surprised if any decent tool writer gives you such settings.
> Just in case, in your CA area try
> openssl verify -CAfile cacert.pem -purpose sslserver servercert.pem
> openssl verify -CAfile cacert.pem -purpose sslclient clientcert.pem
>
> After you cat'ed the root key+cert into one file (root.pem),
> the x509 -req for a child cert doesn't need both -CA and -CAkey,
> -CA is enough. But the redundancy does no harm.
>
> Oh, and known factoring for RSA is still far short of 1024 bits, but
> some authorities are no longer comfortable with its safety margin.
> You might consider going up to 1536 or 2048, if the data communicated
> by your application is valuable or sensitive. But for getting
> the protocol (and authentication) to work that doesn't matter.
>
> Assuming you have (or put) commandline openssl on a client machine, try
> openssl s_client -connect server:port -CAfile yourcacert.pem
> and when it waits for input do EOF (usually control-D on Unix).
> If the next-to-last output line "Verify return code" is other than zero,
> the preceding few screens of output should contain more detailed error
> information than you seem to be getting through gSOAP. Alternatively
> gSOAP might log more detail someplace or have option(s) for more detail.
>
> My first guess, because the easiest to get wrong or forget, is that
> the client needs to have the root cert, namely your cacert.pem file,
> in its truststore (and for client auth so does the server, but you
> haven't gotten to that stage yet). The OpenSSL API has an "SSL context"
> structure (SSL_CTX) but I don't know if that's what you are using
> or if gSoap has its own context (probably similar in general outline
> but quite possibly different in specifics).
>
> If you are using SSL_CTX and the toolkit DOESN'T set up its own
> (custom) store handling/lookup, you need to either:
>
> - before using to start a connection (or multiple connections) call
> SSL_CTX_load_verify_locations with the name of a file containing all
> desired CAcerts (in your case, only one) and/or a directory containing
> one file for each desired CAcert (again for you one) named by its hash.
> In a simple case like yours the single file is easier.
>
> - or find the default store used by OpenSSL, and similarly put there
> a combined file 'cert.pem' or a directory 'certs' of separate file(s).
> This default depends on your platform(s) and optionally on decision made
> by whoever created the build(s) of OpenSSL you are using. Assuming your
> commandline openssl is the same build as the libraries your application
> is linked to (should always be the intent but sometimes mistakes happen)
> 'openssl version -d' will tell you.
>
> If you are using a gSoap context you may need to do something similar,
> or something equivalent but implemented differently, I have no idea.
> If gSoap has its own store handling you need to figure that out;
> one would hope it's clearly documented.
>
> Note: since you cat'ed cacert.pem into {client,server}.pem,
> you *could* use either of those as a CAfile. But some results
> could become confusing. Exact cacert.pem is better.
>
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
--
Best regards,
Maurício Souza Klein.
