<div dir="ltr">Hi!<br><div><div class="gmail_extra"><br><div class="gmail_quote">2018-03-19 1:35 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">Interesting. That entails I trust an intermediate in my certificate chain for connections from peers, which on the face of it doesn't seem correct, as it widens the collection of trusted peers unnecessarily. Couldn't there be cases where you only want to trust peers from a certain CA (e.g., an issuing authority that is strictly below your own issuer), but not your own issuer? <div><br></div></div></blockquote><div><br></div><div>The peer must send its chain that will identify the root. And it is checked that you own the root. If you decide to trust an intermediate sent by the peer that is still a certificate sent by the peer and you are responsible to make the decision that you trust it as a root. Now if we have to start guessing the chain it might be problem. Also initially it was not obvious to me either that this was the way OpenSSL APIs worked. <br><br></div><div>It is however documented in erlang Server side options says:<br></div><div><br><dt><strong><span class="gmail-code">{cacertfile, path()}</span></strong></dt>
<dd><p>Path to a file containing PEM-encoded CA
certificates. The CA certificates are used to build the server
certificate chain and for client authentication. The CAs are
also used in the list of acceptable client CAs passed to the
client when a certificate is requested. Can be omitted if there
is no need to verify the client and if there are no
intermediate CAs for the server certificate.</p></dd>client side says:<br></div><div><br><dt><strong><span class="gmail-code">{cacertfile, path()}</span></strong></dt>
<dd>
<p>Path to a file containing PEM-encoded CA certificates. The CA
certificates are used during server authentication and when building the
client certificate chain.</p>
</dd><br><br></div><div> </div><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></div><div>E.g., something like<br><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"> +- server</font></div><div><font face="Menlo"> +- ICA2</font></div><div><font face="Menlo"> +- client</font></div></blockquote><div><br></div><div>but where you only want to accept connections from ICA2.</div><div><br></div><div>(I don't have this particular problem, but it does come to mind.)</div><div><br></div><div>Semantically it's a little strange, too, but that can always be fixed with documentation.<div><div><br></div><div>Is this because the implementation depends on OpenSSL, or just the design? </div></div></div></div></div></blockquote><div><br></div><div>The implementation does not depend opn OpenSSL in any other way that that it uses cryptolib from OpenSSL via the crypto application. But the API is "insanely" backwards compatible with <br></div><div>older version (pre R14) that used the OpenSSL as it implementation.<br><br></div><div> <br><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<br></div><div><br><br></div><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><div><div><div>If the latter, I would suspect that changing the behavior to specify own certificate chains outside of the trust store would introduce nontrivial upgrade issues for existing users, unwitting, or otherwise.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><div><span class="HOEnZb"><font color="#888888">-Fred</font></span><span class=""><br><div><br><div><blockquote type="cite"><div>On Mar 18, 2018, at 5:58 PM, Ingela Andin <<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>> wrote:</div><br class="m_5163450498192576006Apple-interchange-newline"><div><div class="gmail_extra" 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">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><br class="m_5163450498192576006Apple-interchange-newline"></div></blockquote></div><br></div></span></div></div></div></div></div></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></div>