[erlang-questions] Intermediate certificate as CA

[Ingela Andin]

Hi!

All intermediate CA:s should be placed in the cacertfile option together
with trusted ROOT certs, this way of configuring has been inherited from
OpenSSL.

Regards Ingela Erlang/OTP team - Ericsson AB

2018-03-17 16:43 GMT+01:00 Fred Dushin <fred@REDACTED>:

> So, I have a question about how to configure an Erlang endpoint to
> actually _send_ a complete certificate chain (or the chain minus the root
> cert, as I just consider that an optimization).
>
> Specifically, the docs state that a (client or server) certificate is
> specified via:
>
> {cert, public_key:der_encoded()} |
> {certfile, path()}
>
>
> where public_key:der_encoded() is a binary().
>
> Looking at the source code, certfile may indeed contain a catenation of
> PEM certificates.  However, it appears that only the first is used as
> OwnCert, and the rest are discarded (at least when specified via a file),
> e.g.,
>
> https://github.com/erlang/otp/blob/OTP-20.3.1/lib/ssl/src/
> ssl_config.erl#L78
> https://github.com/erlang/otp/blob/OTP-20.3.1/lib/ssl/src/
> ssl_config.erl#L86
>
> The spec in the docs say that the cert parameter over-rides the certfile,
> but the type spec for cert is a binary, not a list of binaries.  (I don't
> know if the OTP build enforces dialyzer specs)
>
> With a CA hierarchy like:
>
> CA
> +- ICA1
>     +- ICA2
>         +- peer1
>         +- peer2
>         ...
>
>
> I would like the server to send the client (as part of the handshake) the
> following certificate chain:
>
> peer1, ICA2, ICA1 [, CA]
>
>
> But in my experiments, I can only get the server to send peer1.
>
> (I am specifically interested in server behavior, but also generally
> interested in client behavior, as well.)
>
> Note that the only guarantee I have about my peer is that CA is a trusted
> CA; the SSL peer may have no knowledge of ICA2 or ICA1.
>
> Thoughts?
>
> -Fred
>
>
> On Feb 23, 2018, at 8:53 AM, Ingela Andin <ingela.andin@REDACTED> wrote:
>
> That breaks the TLS protocol. The peer in either direction should send the
> whole certificate chain with the exception of the ROOT certificate that is
> optional as the peer has to own it to be able to verify it.
>
>
>
> _______________________________________________
> 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/20180318/5a310640/attachment.htm>