Hello, > > 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? I do not see ease method. >From source code looks that when server receives CertificateVerify function ssl3_get_cert_verify() is called. When this function returns error - fatal alert is send to client and handshake is terminated. And from logical point of view this is ok. In ssl3_get_cert_verify() there is no "callback" to change return code.
When server sends CertificateRequest to client, client may ignore this or respond with full client authentication. Client authentication requires from client to send to server Certificate packet (with client certificate) and CertificateVerify packet (with some hashed data encrypted with client private key - to check that client has corresponding private key). Server decrypt received CertificateVerify packet with client certificate and check this hashed data against his own. If they are equal - client authentication is verified. If client sends "incompatible" certificate to server and than uses other private key to encrypt CertificateVerify packet this will fail. But this looks like client fault. Some other application use different way in authentication clients. When client connects, there is no need to authentication and client can do all actions that no required authentication (and for many clients this is enough). But when client wants to do action that requires authentication, server initiates SSL re-handshake with requesting client certificate (and CertificateVerify information). And sorry for my mistake in previous post: In TLS1 length of ClientVerify data is also 16+20 bytes. Length of Finished packet data is 12 bytes. Too many numbers :-) 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]
