[erlang-questions] reltool/rebar vs. ssl certificates

Felix Gallo felixgallo@REDACTED
Wed Apr 10 05:34:47 CEST 2013


Hi Tristan --

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.

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.

F.


On Tue, Apr 9, 2013 at 8:25 PM, Tristan Sloughter <
tristan.sloughter@REDACTED> wrote:

> Are you sure both times, the release and running manually yourself, it is
> using the same version of erts?
>
> 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.
>
> Tristan
>
>
> On Tue, Apr 9, 2013 at 3:16 PM, Felix Gallo <felixgallo@REDACTED> wrote:
>
>> 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.
>>
>> In particular, my OTP application, which uses httpc, ssl and public_key,
>> when run from the reltool- and rebar-generated application start script,
>> emits:
>>
>> =ERROR REPORT==== 9-Apr-2013::20:20:59 ===
>> SSL: certify: ssl_handshake.erl:263:Fatal error: certificate unknown
>>
>> =ERROR REPORT==== 9-Apr-2013::20:20:59 ===
>> Error in process <0.77.0> on node 'message_queue_worker@REDACTED' with
>> exit value: {{badmatch,{error,{failed_connect,[{to_address,{"
>> go.urbanairship.com",443}},{inet,[inet],{tls_alert,"certificate
>> unknown"}}]}}},
>>
>> but when run via erl it works fine.
>>
>> 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.
>>
>> Unfortunately the documentation is a little sparse in this area and it
>> doesn't appear that my situation is super common.
>>
>> Thanks in advance for any clues / tips.
>>
>> F.
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130409/a99957cb/attachment.htm>


More information about the erlang-questions mailing list