> 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
