<div dir="ltr">Hi!<br><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards Ingela Erlang/OTP team - Ericsson AB </div><div class="gmail_extra"><br><div class="gmail_quote">2018-03-17 16:43 GMT+01:00 Fred Dushin <span dir="ltr"><<a href="mailto:fred@dushin.net" target="_blank">fred@dushin.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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).</div><div><br></div><div>Specifically, the docs state that a (client or server) certificate is specified via:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="Menlo">{cert, public_key:der_encoded()} |</font></div><div><font face="Menlo">{certfile, path()}</font></div></blockquote><div><br></div><div>where <span style="color:rgb(26,26,26);font-family:mono,Courier,monospace;font-size:16px;background-color:rgb(243,243,243)">public_key:der_encoded()</span><wbr> is a <span style="color:rgb(26,26,26);font-family:mono,Courier,monospace;font-size:16px;background-color:rgb(243,243,243)">binary()</span>.</div><div><br></div><div>Looking at the source code, <font face="Monaco">certfile</font> may indeed contain a catenation of PEM certificates.  However, it appears that only the first is used as <font face="Menlo">OwnCert</font>, and the rest are discarded (at least when specified via a file), e.g.,</div><div><br></div><div><a href="https://github.com/erlang/otp/blob/OTP-20.3.1/lib/ssl/src/ssl_config.erl#L78" target="_blank">https://github.com/erlang/otp/<wbr>blob/OTP-20.3.1/lib/ssl/src/<wbr>ssl_config.erl#L78</a></div><div><a href="https://github.com/erlang/otp/blob/OTP-20.3.1/lib/ssl/src/ssl_config.erl#L86" target="_blank">https://github.com/erlang/otp/<wbr>blob/OTP-20.3.1/lib/ssl/src/<wbr>ssl_config.erl#L86</a></div><div><br></div><div>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)</div><div><br></div><div>With a CA hierarchy like:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="Menlo">CA</font></div><div><font face="Menlo">+- ICA1</font></div><div><font face="Menlo">    +- ICA2</font></div><div><font face="Menlo">        +- peer1</font></div><div><div><font face="Menlo">        +- peer2</font></div></div><div><font face="Menlo">        ...</font></div></blockquote><div><br></div><div>I would like the server to send the client (as part of the handshake) the following certificate chain:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="Menlo">peer1, ICA2, ICA1 [, CA]</font></div></blockquote><div><br></div><div>But in my experiments, I can only get the server to send peer1.</div><div><br></div><div>(I am specifically interested in server behavior, but also generally interested in client behavior, as well.)</div><div><br></div><div>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.</div><div><br></div><div>Thoughts?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Fred</div></font></span><span class=""><div><br></div><br><div><blockquote type="cite"><div>On Feb 23, 2018, at 8:53 AM, Ingela Andin <<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>> wrote:</div><br class="m_3752250862393187636Apple-interchange-newline"><div><div style="font-family:Verdana;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div><div><br></div></div></div></div></div></blockquote></div><br></span></div><br>______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div>