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. > 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 :-) > Will ssldump help with kEDH? I do not know. > Does the client cert handshake take place > before the traffic becomes encrypted? Yes. Best regards, -- Marek Marcola <[EMAIL PROTECTED]> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
