>From: owner-openssl-us...@openssl.org On Behalf Of David William >Sent: Tuesday, 25 September, 2012 07:07
>I am writing a soap request and I am using SSL_VERIFY_NONE flag mode >because that was the only way that I could actually do the request >to the server. >I tried the others mode flags (SSL_VERIFY_PEER, SSL_VERIFY_FAIL_IF_NO_PEER_CERT >and SSL_VERIFY_CLIENT_ONCE) but none of them worked. I got the following error: > OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 >state=SSLv3 read server certificate B: certificate verify failed _FAIL_IF_NO_PEER and _CLIENT_ONCE only have meaning on server, they are ignored on client. VERIFY_PEER is the only one the matters. >I am in development environment using a self signed certificate that I generated. To be clear: you mean self-signed in the technical sense (subjectDN=issuerDN and signingkey.pub=subjectkey)? Some people who operate their own personal CA label certs it issues as "self-signed" because "I myself did the signing", but that's not the same thing as self-signed in PKI and protocol terms. Then you need to have the selfsigned cert in the client's truststore. (Otherwise, for a CA-issued cert, you need the CA's root cert.) http://www.openssl.org/support/faq.html#USER5 If you are calling SSL_[CTX_]set_verify_mode, you should be able to call SSL_CTX_load_verify_locations or SSL_CTX_set_default_verify_paths to set or default respectively the truststore file and/or directory, in which you have put your cert. For a directory you must have link(s) or name(s) using the hash of the canonicalized subject of the cert; for Unix a c_rehash script is provided that does this for you, and on all OS commandline x509 -hash tells you what is needed. Using file is simpler as long as your certs are not too numerous or dynamic. If you are going through middleware, you depend on that middleware's capabilities, although if it lets you set verify mode it makes sense for it to let you set truststore also. If not, but it does *use* default_verify_paths, you can override the file/dir used by that by setting environment variables. >I have lots of questions about it because I am new to the subject but >my main concern right now is: since my soap request is working with >SSL_VERIFY_NONE and I need to release this funcionality soon, is that risky? Without server authentication, if an attacker can intercept the connection(s) from your client(s) -- perhaps by poisoning DNS or altering IP routing, or if physically close by crashing or overloading the true server (if up) and using its address, or by being part of the valid IP path -- your client(s) can't detect the difference and will give your presumably sensitive data to the attacker, who will presumably misuse it. >Am I doing wrong if I keep the verify mode to "none"? Is there any >lack of security? See above. >What are the requirements to use the others verify mode flags? Have the (server) roots you want to trust in client truststore, where a selfsigned cert is effectively its own root. >Can it be done with a self signed certificate? Yes, as long as you trust the person/entity doing the self-signing. If you have a large and/or varying population of peers -- as you do on the public Internet and Web -- it's somewhere from costly to impossible to decide on trusting every peer individually and you need a third-party to do it, and that's exactly what CA's do (though not always perfectly). If you have a small fixed population, it works to do it yourself. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
