Issue:
I have to implement openssl in my project.project is implemented with gsoap.
in "r = SSL_connect(soap->ssl)) <= 0)"
SSL_connect call is unable to make a connection to the server.Both server
and client are in local host
I see server is ready to accept the connections, as I see below connection
established with netstat command:
TCP cspxppgudepu:15000 cspxppgudepu.com:0 LISTENING
TCP cspxppgudepu:15000 localhost:2864 ESTABLISHED
Above 15000 port is for server.
Below is client connection:
TCP cspxppgudepu:16000 cspxppgudepu.com:0 LISTENING
But SSL_connect is unable to connect.It is always failing with return code
-1.
With out SSL connection,simple TCP conection, both ends are able to connect
and communicate.
My network configuration settings are:
<NetworkConfig>
<Server Location="https://127.0.0.1:15000" />
<Client Location="https://127.0.0.1:16000" />
Thanks in advance.
Pradeep Reddy.
--
View this message in context: http://old.nabble.com/OPENSSL-SSL_Connect-blocking-tp29708086p29708086.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List opens...@openssl.org
Automated List Manager majo...@openssl.org
An update,
SSL_connect is failing with SSL_ERROR_WANT_READ.I understand that client is
waiting on server to write some data.But I dont understand what to change
code in server side.
--
View this message in context: http://old.nabble.com/OPENSSL-SSL_Connect-blocking-tp29708086p29710645.html
--
View this message in context: http://old.nabble.com/OPENSSL-SSL_Connect-blocking-tp29708086p29717770.html
But SSL_accept & SSL_Connect are failing with "*** SSL_ERROR_WANT_READ
*** SSL_ERROR_SYSCALL
Error 30 fault: SOAP-ENV:Server [no subcode]
"EOF was observed that violates the protocol. The client probably provided
inval
id authentication information."
Detail: SSL_accept() failed in soap_ssl_accept()" and "
*** error:00002733:lib(0):func(2):reason(1843)".
I dont understand what is preventing from server to read even after
connection is established.The crypto graphic parametrs are created with
openssl today.So I dont point any mistake in them.Please provide some
light.Thanks in advance.
--
View this message in context: http://old.nabble.com/OPENSSL-SSL_Connect-blocking-tp29708086p29722841.html
Please look into this issue, it is boiling me since couple of days.
Please let me know if I am missing anything.
Thanks,
Pradeep reddy.
pradeepreddy wrote:
>
> An Update:
> After adding SSL key & certificate things, new errors are thrown.
--
View this message in context: http://old.nabble.com/OPENSSL-SSL_Connect-blocking-tp29708086p29728285.html
> After some fight, I am able to make the connection.I have
> taken both server
> and client authentication as false
> SOAP_SSL_REQUIRE_CLIENT_AUTHENTICATION &
> SOAP_SSL_REQUIRE_SERVER_AUTHENTICATION to false.But
> SSL_Conect & SSL_accept
> are failing with errors "***
> error:00002733:lib(0):func(2):reason(1843)" &
I bet this end (at least) is on Windows. Winsock errors don't
fit in 12 bits so OpenSSL breaks them up inappropriately.
0x2733 = 10035 = WSAEWOULDBLOCK. This seems consistent with
some problem with nonblocking sockets, but OpenSSL shouldn't
be returning it as an ERR_ error, it should map it into
SSL_get_error WANT_READ or WANT_WRITE as appropriate.
Possibly your code (or gsoap) is incorrectly calling
ERR_error_string* on errno/[WSA]GetLastError() .
> "*** SSL_ERROR_SSL
> *** SSL_ERROR_SSL
> error:1408A0C1:lib(20):func(138):reason(193)
> Error 30 fault: SOAP-ENV:Server [no subcode]
> "Error observed by underlying BIO: No such file or directory"
You can use commandline openssl errstr to find out 1408A0C1 is
SSL3_GET_CLIENT_HELLO:no shared cipher. It's unclear what file
got the "No such file" error, but generally the only files a
server needs are its privatekey(s)+cert(s), DH/ECDH params
if explicit, and maybe random seeding. I don't know if
REQUIRE_SERVER_AUTH false in your software means it's not
demanded by the client, or not supported by the server.
All the ciphersuites enabled by default in OpenSSL do have
server authentication; to use the "anonymous" suites you
must explicitly enable them. If you run a server with no
privkey+cert(s), it can't negotiate any suite allowed by a
client using the default list, causing "no shared cipher".
> Detail: SSL_accept() failed in soap_ssl_accept()"
> respectively.I provided
> client.pem keyfile, though it is not required as
> authentication is set to
> false.Please let me know your thoughts.
>
> pradeepreddy wrote:
> >
> > Hi,
> >
> > An update,
> >
> > SSL_connect is failing with SSL_ERROR_WANT_READ.I
> understand that client
> > is waiting on server to write some data.But I dont
> understand what to
> > change code in server side.
> >
Nothing. WANT_READ, and WANT_WRITE, require *local*
handling of nonblocking sockets. If you (or gsoap)
does want nonblocking sockets, see the man pages
for SSL_read, SSL_write, and/or SSL_get_error.
Except if you're on Windows, you probably don't
have man pages. If you don't want nonblocking
sockets, you apparently did something wrong
and got them, so fix that.
<snip some earlier>
> >> I see server is ready to accept the connections, as I see below
> >> connection established with netstat command:
> >>
> >> TCP cspxppgudepu:15000 cspxppgudepu.com:0 LISTENING
> >> TCP cspxppgudepu:15000 localhost:2864 ESTABLISHED
> >>
> >> Above 15000 port is for server.
> >>
> >> Below is client connection:
> >> TCP cspxppgudepu:16000 cspxppgudepu.com:0 LISTENING
> >>
That's not a connection, only an apparently listening socket.
Generally a client shouldn't (also) be listening, but IME
at least some versions of Winsock spuriously show LISTENING
when you merely have the socket open (and maybe bound?).
This communication happened with CLIENT_AUTHENTICATION is set to "ture" &
SERVER_AUTHENTICATION is set to "false".
I observed SSL_Connect is failing with Error "SSL certificate host name
mismatch in tcp_connect()" with SERVER_AUTHENTICATION set to "true" case.
I verified that host name and common name mismatch is the culprit.
But can you please clear me basic fundamentals.In soap_ssl_client_context
call, do we provide server certificate or client certificate.Sorry, I think,
I can debug this with further study thru the code.
Below are commands I used to generate cacert.pem file;
openssl req -newkey rsa:1024 -sha1 -keyout rootkey.pem -out rootreq.pem
--------
openssl x509 -req -in rootreq.pem -sha1 -extensions v3_ca -signkey
rootkey.pem -out cacert.pem -days 1095.
As for testing purpose I used this same certificate file in both
soap_ssl_client_context() and soap_ssl_server_context() calls
Do I need to change any options in above commands to generate server side
certificate.
Thanks,
Pradeep reddy.
--
View this message in context: http://old.nabble.com/OPENSSL-SSL_Connect-blocking-tp29708086p29739388.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
______________________________________________________________________
I think I got the answer.Server certificate and client certificate are
exchanged in handshake.
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)"
But both client certificate and server certificate are generated from root
certificate "cacert.pem" below comands.
Command:openssl x509 -req -in clientreq.pem -sha1 -extensions usr_cert -CA
root.pem -CAkey root.pem -CAcreateserial -out clientcert.pem -days 1095
and
Command:openssl x509 -req -in serverreq.pem -sha1 -extensions usr_cert -CA
root.pem -CAkey root.pem -CAcreateserial -out servercert.pem -days 1095
Please provide if you have any fix.
Thanks,
Pradeep.
--
View this message in context: http://old.nabble.com/OPENSSL-SSL_Connect-blocking-tp29708086p29740400.html
> 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_.