Thanks for your fast answer.
Well I've just generated certificates with the machine names. And the problem
is the same. Or maybe I'm still wrong with my certificates.
The name in the certificate will not be automatically verified for you.
Your application has to verify that the name specified in the certificate
somehow matches who your peer claims to be. So if client verifies a
certificate of a server it should make sure that the name in certificate
matches the hostname that it used to connect to this server. With client
it's usually app specific -- somewhere as part of your protocol your
client is probably supplying username or something like that -- this
username should be verified to be mentioned in the certificate. If your
server doesn't do any authentication of the client you don't need the
client certificate at all.
I've read the man pages for SSL_accept and the only clue I first found was
the non-blocking socket. And mine was already non-blocking.
What do you mean then?
I tried to continue despite the WANT_READ error and when I call BIO_gets, it
does not read anything : it returns -1 (and SSL_ERROR_SSL if I use
SSL_get_error which I'm not sure)
When the socket is non-blocking you have to pretty mcuh always assume that
any call can fail with WANT_READ or WANT_WRITE and you will have to just
repeat the call again. Usually it is a good idea to do appropriate (read
or write) select() before repeating the call.
Look at the easy-tls demo (part of OpenSSL) for examples on how to use
non-blocking sockets.
Use ERR_get_error() to log real errors you get from SSL, e.g.:
while ((serr = ERR_get_error()) != 0)
{
ERR_error_string_n(serr, buf, sizeof(buf)/sizeof(buf[0]));
printf(buf);
}
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
