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

[Ingela Andin]

Hi!

In R16 error handling was changed to avoid hiding information that we acctually
have so you proably would get another error in R15. It  however seems
strange that
that R15 would accept a cert that R16 does not.  The error below will
typically occurs when
there are problems with ASN-1 or decoding or perhaps interpreation of
ASN-1 decoded data.
Have you tried to apply the following commit to R16 from the maint branch?

006f45a738a6612958381b2fcbf48586c008d911

Regards Ingela Erlang/OTP tema - Ericsson AB


2013/4/10, Felix Gallo <felixgallo@REDACTED>:
> 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
>>>
>>>
>>
>