On Mon, May 22, 2006 at 05:26:23PM +0200, Marek Marcola wrote:
> Hello,
> > Would this also happen when the client's private key does not match
> > the certificate?
> Yes, of course.
> If client sends to server "incompatible" certificate (public key)
> than RSA decryption will succeed (I mean RSA_public_decrypt())
> but result will have no sense.
> Good point :-)
> With OpenSSL this may be checked with SSL_CTX_check_private_key().
>
> > Why does the handshake fail at this point?
> To retrieve encrypted by RSA_private_encrypt() function
> data server must remove padding, and this is not possible in this
> situation. In SSL3 data send by client to server in CertificateVerify
> packet is 16+20 bytes long, in TLS 12 bytes long.
>
> Requesting by server client certificate is equal
> to request client authentication. So this must succeed.
In my case client authentication is optional, some clients use it,
some don't.
> > Client certificates are not mandatory in my application, so if OpenSSL
> > skipped past the error and acted as though no client credentials
> > were sent, I would prefer that. Is that possible?
>
> You may control requesting from client his certificate
> with SSL_CTX_set_verify()/SSL_set_verify() with flags
> SSL_VERIFY_PEER and SSL_VERIFY_FAIL_IF_NO_PEER_CERT.
> For example you may request from client certificate
> (SSL_VERIFY_PEER) but not drop connection if none
> is provided (~SSL_VERIFY_FAIL_IF_NO_PEER_CERT).
> So after establishing SSL connection you may from application
> layer decide what client can and what can't do.
> (But i did not check this myself :-)
I already do all this, but it seems that clients with bad credentials
(rather than no credentials) fail. Is it possible to ignore the bad
credentials?
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
