> From: owner-openssl-us...@openssl.org On Behalf Of AnneB > Sent: Monday, 06 April, 2009 05:32
> I have used (at client side, before SSL_connect) > SSL_set_verify SSL_VERIFY_PEER mode and I have put NULL > instead of verify callback in order to use the default > callback. But with SSL_get_error I get SSL_ERROR_SSL. I use a > self-signed certificate. Could be this the problem? > Yes. A self-signed certificate by itself is not trustworthy, because anyone especially an attacker can create a fake one. The simple solution openssl does 'builtin' is to use CA-signed certs (can be your own private CA) and a 'local trusted store' -- a file or directory containing the (root) CA cert(s) you trust. (And which it is presumed an attacker can't/didn't change.) If that is OK for you, just use SSL_CTX_load_verify_locations and don't bother with a verify_callback. By the way, whenever you get SSL_ERROR_SSL, you can and should call ERR_get_error to get a more specific 'detail' error code (sometimes more than once, until it returns 0). You can call ERR_error_string to get an explanation for (each) such errorcode (assuming you have called appropriate load_err_strings entries). > I have also defined my own verify_callback starting from the > example presented in openssl SSL_set_verify documentation. > Where is not very clear for me it's how to verify a > certificate in order to know that can be trusted? In > verify_callback example the certificate is retrieved from > server and some depth check is done (in my case depth is 0 That wording is loose and misleading. The callback doesn't itself communicate with the (or any) server. It retrieves, from the local X509_STORE_CTX data structure, data about the certificate(s) already received by openssl library code, or obtained from the local store if provided and applicable. > because I use a self-signed certificate). What else should > contain? A test if the keys go together is also necessary > here? Another example of verify_callback will be really helpful. > That's the question for you. One purpose of writing a callback is to make trust decisions according to your own criteria -- what are your own criteria? Another purpose is to capture some information _about_ the verification, e.g. for logging. But if you are only capturing, you don't need to change the trust decision(s) already made by openssl, and don't. Do you simply want to trust all self-signed certificates, or all certificates of any kind? If so, just return 1 from the callback. That would mean you are using SSL but not getting all the security SSL is intended to provide. It would be more honest (if the server supports it) to configure and use the unauthenticated (ADH) ciphers with no certs at all. If not, what do you want to check -- that can be done using certificate data, and is other/different than the default? I don't know what you mean by 'keys go together'. openssl if you have a chain (more than one cert) already checks each child cert's signature verifies under its parent's publickey. At least for RSA keys, there should be no other relationship between publickeys of different parties -- they should appear to be random large (composite) numbers. For DSA I guess you could require that multiple (all?) parties have keys under the same parameters, but why? If each is separately valid, why is that not enough? And you should never have any other party's privatekey. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org