Hi Dave, Thank you very much.
You just answered all my questions. That helped a lot!! Regards, David William On Tue, Sep 25, 2012 at 9:15 PM, Dave Thompson <dthomp...@prinpay.com>wrote: > >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 >
