<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<style type="text/css">.mceResizeHandle {position: absolute;border: 1px solid black;background: #FFF;width: 5px;height: 5px;z-index: 10000}.mceResizeHandle:hover {background: #000}img[data-mce-selected] {outline: 1px solid black}img.mceClonedResizable, table.mceClonedResizable {position: absolute;outline: 1px dashed black;opacity: .5;z-index: 10000}
</style>
</head><body style="">
<div>
Replying through webmail because SMTP decided to stop working. Hope it's not too terrible when it gets into your mailboxes.
</div>
<div>
</div>
<div>
> Le 31 janvier 2015 à 19:36, "e@bestmx.net" <e@bestmx.net> a écrit :
<br />>
<br />>
<br />> On 01/31/2015 07:35 PM, Loïc Hoguin wrote:
<br />> > On 01/31/2015 07:31 PM, e@bestmx.net wrote:
<br />> >> On 01/31/2015 07:28 PM, Loïc Hoguin wrote:
<br />> >>> Don't look at me, we just have a wrapper on top of SSL, most SSL issues
<br />> >>> are out of my league. :-)
<br />> >>
<br />> >> this wrapper is supposed to know everything about arguments it passes,
<br />> >> may be there is one i am looking for is among them (hiding behind an
<br />> >> incomprehensible name, for example)
<br />> >
<br />> > I don't know if this is what you need as I'm not sure what your issue is
<br />> > exactly, but there is an option to define the verification fun
<br />> > (verify_fun) as others have already pointed out in this thread. Have you
<br />> > tried it yet?
<br />>
<br />> no, it sounds to me like a last resort solution.
<br />> if i am to define this function i then have very little need in the SSL
<br />> itself.
<br />> shouldn't it work by-default?
<br />
<br />
</div>
<div>
I think you are missing the point of SSL. I will try to dumb it down.
<br />
<br />SSL gives you both secrecy through encryption and authentication of the endpoint you communicate with.
<br />
<br />The latter is only possible precisely because of the certificate chain. It is used to verify that the server's certificate has been signed by a trusted entity or by an intermediary of the trusted entity. Therefore we can assume that the server is who they say they are.
<br />
<br />If you self sign a certificate then you lose this authentication aspect. Sure you still have secrecy through encryption, but anyone between you and the server can decide to decrypt and read what you send. This is called a man in the middle attack.
<br />
<br />By default SSL gives you secure connections, that means both encryption and authentication. A browser or client that tries to connect to a server that uses a self signed certificate will get an error until further steps are taken by the user to confirm they really want to connect to it.
<br />
<br />It works as intended by default.
<br />
<br />Now I am not sure what you do, what certificate you have, what kind of client you use, what options, so it is very hard to help.
<br />
<br />If it is the client that rejects your server's self signed certificate though, there's nothing you can do except getting a certificate from a trusted CA, or use an option in the client to disable the certificate verification.
</div>
<div>
</div>
<div>
--
</div>
<div>
Loïc Hoguin
</div>
<div>
http://ninenines.eu
</div>
</body></html>