<div dir="ltr">Hi Tristan --<div><br></div><div style>Interesting theory.  I located the 'erl' script in the generated build, and ran it directly, and it reports itself as Erlang R16B (erts-5.10.1), just like my system /usr/local/bin/erl does.</div>

<div style><br></div><div style>However, and this is a new data point, if I run the generated build's erl, and start my application manually under that erl, then I get the unknown certificate error message, whereas if I run /usr/local/bin/erl and start my application manually, I don't.  There must be some initialization or configuration option which is different.</div>

<div style><br></div><div style>F.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 9, 2013 at 8:25 PM, Tristan Sloughter <span dir="ltr"><<a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Are you sure both times, the release and running manually yourself, it is using the same version of erts?<div>

<br></div><div>This is an error message a number of us have seen when trying to use code that worked in R15 but now gives this error in R16.</div>
<div><br>Tristan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Tue, Apr 9, 2013 at 3:16 PM, Felix Gallo <span dir="ltr"><<a href="mailto:felixgallo@gmail.com" target="_blank">felixgallo@gmail.com</a>></span> wrote:<br>


</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">I am seeing a (probably intentional) difference between the way that the ssl module resolves certificates when run by hand from a command line emulator, and the way that it resolves certificates when run via a rebar-generated start script.  I would like to understand the underlying mechanism and how to change its behavior.<div>




<br></div><div>In particular, my OTP application, which uses httpc, ssl and public_key, when run from the reltool- and rebar-generated application start script, emits:</div><div><br></div><div><div>=ERROR REPORT==== 9-Apr-2013::20:20:59 ===</div>




<div>SSL: certify: ssl_handshake.erl:263:Fatal error: certificate unknown</div><div><br></div><div>=ERROR REPORT==== 9-Apr-2013::20:20:59 ===</div><div>Error in process <0.77.0> on node '<a href="mailto:message_queue_worker@127.0.0.1" target="_blank">message_queue_worker@127.0.0.1</a>' with exit value: {{badmatch,{error,{failed_connect,[{to_address,{"<a href="http://go.urbanairship.com" target="_blank">go.urbanairship.com</a>",443}},{inet,[inet],{tls_alert,"certificate unknown"}}]}}},</div>




</div><div><br></div><div>but when run via erl it works fine.</div><div><br></div><div>I suspect/think/am trying to deduce that the rebar-generated start script is attempting to sandbox/clean-start the environment so that minimal system dependencies are injected, which would be a good general practice for things like rebar/reltool.  However, this app will only ever be installed on unix systems with properly installed certs in the normative openssl directories so I'd like to bypass that, or work around it with proper inclusions.  </div>




<div><br></div><div>Unfortunately the documentation is a little sparse in this area and it doesn't appear that my situation is super common.</div><div><br></div><div>Thanks in advance for any clues / tips.</div><span><font color="#888888">

<div><br></div><div>F.</div></font></span></div>
<br></div></div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>