<div dir="ltr"><div><br></div><div>We will be fixing it , but it is not considered top priority. If you feel it is a top priority to you PR are always welcome.</div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den mån 24 feb. 2020 kl 16:01 skrev Michael Viveros <<a href="mailto:michaelviveros@gmail.com">michaelviveros@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Any update?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 5:18 PM Michael Viveros <<a href="mailto:michaelviveros@gmail.com" target="_blank">michaelviveros@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">OTP-22.2 fixed certificate chains with out-of-order certificates but certificate chains with duplicate certificates still don't work. Duplicate seems like a subset of out-of-order and I've seen quite a few endpoints with duplicate certificates so could we fix this as well?<div><br></div><div>Here's an example using the host <a href="http://inputs.alooma.com" target="_blank">inputs.alooma.com</a>:</div><div><br></div><div>$ openssl s_client -connect <a href="http://inputs.alooma.com:443" target="_blank">inputs.alooma.com:443</a><br>...<br>Certificate chain<br> 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.<a href="http://alooma.com" target="_blank">alooma.com</a><br>   i:/C=US/O=Google Trust Services/CN=GTS CA 1O1<br> 1 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.<a href="http://alooma.com" target="_blank">alooma.com</a><br>   i:/C=US/O=Google Trust Services/CN=GTS CA 1O1<br> 2 s:/C=US/O=Google Trust Services/CN=GTS CA 1O1<br>   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign</div><div><br>$ erl<br>Erlang/OTP 22 [erts-10.6] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]<br><br>Eshell V10.6  (abort with ^G)<br>1> c(ssl).<br>Recompiling /Users/mviveros/.asdf/installs/erlang/22.2/lib/ssl-9.5/src/ssl.erl<br>{ok,ssl}<br>2> ssl:start().<br>ok<br>3> ssl:connect("<a href="http://inputs.alooma.com" target="_blank">inputs.alooma.com</a>", 443, [{cacertfile, "/etc/ssl/cert.pem"}, {reuse_sessions, false}, {server_name_indication, "<a href="http://inputs.alooma.com" target="_blank">inputs.alooma.com</a>"}, {verify, verify_peer}, {depth, 99}]).<br>=NOTICE REPORT==== 19-Feb-2020::17:16:43.559370 ===<br>TLS client: In state certify at ssl_handshake.erl:1768 generated CLIENT ALERT: Fatal - Handshake Failure<br> - {bad_cert,invalid_key_usage}<br>{error,{tls_alert,{handshake_failure,"TLS client: In state certify at ssl_handshake.erl:1768 generated CLIENT ALERT: Fatal - Handshake Failure\n {bad_cert,invalid_key_usage}"}}}<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 21, 2019 at 5:00 PM Michael Viveros <<a href="mailto:michaelviveros@gmail.com" target="_blank">michaelviveros@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Heard back from Ingela and she confirmed it will be part of OTP-22.2 and OTP-23.0 as opposed to being a patch to OTP-21 (since it's not a vulnerability or critical bug).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 20, 2019 at 9:22 PM Michael Viveros <<a href="mailto:michaelviveros@gmail.com" target="_blank">michaelviveros@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Any update about next steps, Ingela?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 12, 2019 at 5:47 PM Michael Viveros <<a href="mailto:michaelviveros@gmail.com" target="_blank">michaelviveros@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Just confirmed your fix worked!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 11, 2019 at 6:16 PM Michael Viveros <<a href="mailto:michaelviveros@gmail.com" target="_blank">michaelviveros@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Great news, thanks Ingela! I tried confirming the fix on my end but I'm an Erlang noob so it's taking me awhile, will try again tomorrow.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 11, 2019 at 5:17 AM Ingela Andin <<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hi!</div><div><br></div><div>I have a patch that solves the problem.  I have pushed it to my gitrepo <a href="https://github.com/IngelaAndin/otp/tree/ingela/ssl/unorded-chain" target="_blank">https://github.com/IngelaAndin/otp/tree/ingela/ssl/unorded-chain</a></div>  <div>I had to set the options {depth, 2} and <span>{customize_hostname_check,  [{match_fun, CustomFun}]</span></div><div><span>where CustomFun = public_key:pkix_verify_hostname_match_fun(https)  as the peer certificate is a wildcard cert.</span></div><div><span><br></span></div><div><span><br></span></div><div><span>Regard Ingela Erlang/OTP team<br></span></div><div><span><br></span></div><div><span><br></span></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den fre 8 nov. 2019 kl 21:46 skrev Curtis J Schofield <curtis@ram9.cc>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">   <div>Oh this is wonderful news!! Glad you were able to identify the code not reached !! </div><div><br></div><div>Deeply appreciate your support and expertise!</div><div><br></div><div>Best,</div><div>Curtis <u></u><u></u></div><div><br></div><div id="gmail-m_-7512885605015009420gmail-m_-6213124279714380938gmail-m_1142038452762535935gmail-m_-6913802066438686393gmail-m_-2561057427935395941gmail-m_-1436707897894659288gmail-m_-1252846040026057082gmail-m_-2066110737253625160protonmail_mobile_signature_block"><div>Sent from ProtonMail Mobile</div></div> <div><br></div><div><br></div>On Fri, Nov 8, 2019 at 12:15 PM, Ingela Andin <<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>> wrote:<blockquote type="cite">  <div dir="ltr"><div>Hi!</div><div><br></div><div>I think I am on to the problem, we have only  whitebox tested the unorded chain functionality (we intend to create a blackbox but that is a bigger job as we need to find some introp software that can create such chains or create a simulation modle),</div><div>so I am positive  I found that we do not reach the code for sorting the chain.  I will try to fix it next week. It is easier now that I at least I got a server that I can manually blackbox  test with :)</div><div><br></div><div> Regards Ingela Erlang/OTP Team - Ericsson AB<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tors 7 nov. 2019 kl 20:53 skrev Ingela Andin <<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tors 7 nov. 2019 kl 19:35 skrev Michael Viveros <<a href="mailto:michaelviveros@gmail.com" target="_blank">michaelviveros@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Ingela,<div><br></div><div>Curtis' example server from his first message, <a href="http://hooks.glip.com" target="_blank">hooks.glip.com</a>, presents its certificates out-of-order. The correct order is Peer -> Intermediate CA 1 - > Intermediate CA 2 -> Root CA but they get presented as Peer -> Root CA -> Intermediate CA 2 -> Intermediate CA 1 and this returns the "Unknown CA" error. You can confirm this by running `openssl s_client -connect hooks.glip.com:443`.</div></div><br></div></blockquote><div><br></div><div>Yes I agree that this is an out of order chain, in contrast to the <a href="http://social.fluffel.io" target="_blank">social.fluffel.io</a>.   I will look into it at work tomorrow. <br></div><div><br></div><div>Regards Ingela Erlang/OTP Team - Ericsson AB<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 7, 2019 at 1:23 PM Curtis J Schofield <curtis@ram9.cc> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">   <div>Hi Ingela</div><div><br></div><div>Thank you for your attention- perhaps Micheal can explain this better.. <u></u><u></u></div><div><br></div><div id="gmail-m_-7512885605015009420gmail-m_-6213124279714380938gmail-m_1142038452762535935gmail-m_-6913802066438686393gmail-m_-2561057427935395941gmail-m_-1436707897894659288gmail-m_-1252846040026057082gmail-m_-2066110737253625160gmail-m_-5019363608254918132gmail-m_-8466579641998479497gmail-m_-5220970652841391182protonmail_mobile_signature_block"><div>Sent from ProtonMail Mobile</div></div> <div><br></div><div><br></div>On Thu, Nov 7, 2019 at 6:55 AM, Ingela Andin <<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>> wrote:<blockquote type="cite">  <div dir="ltr"><div>Hi!</div><div><br></div><div>I
 tried this out and it is not out of order, it sends the peer cert
followed by the intermediate cert repeated, that is the chain looks like
 [Peer, CA1, CA1].</div><div>Looking at TLS-1.3 RFC it looks like extra certs should ignored too, so I suppose we need to add that.</div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den lör 2 nov. 2019 kl 15:24 skrev Mark Reynolds <<a href="mailto:beastie@mm.st" target="_blank">beastie@mm.st</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div>Hey,<br></div><div><br></div><div>I confirm that out of order certs does not seems to be fixed, and it fails with 'Unknown CA' error:<br></div><div><br></div><div><br></div><div>iex(2)> :hackney.get("<a href="https://social.fluffel.io" target="_blank">https://social.fluffel.io</a>")<br></div><div>{:error,<br></div><div>{:tls_alert, {:unknown_ca, 'received CLIENT ALERT: Fatal - Unknown CA'}}}<br></div><div><br></div><div><br></div><div>the only issue with this server TLS certificates is the chain order (CA is Letsencrypt): <a href="https://www.ssllabs.com/ssltest/analyze.html?d=social.fluffel.io" target="_blank">https://www.ssllabs.com/ssltest/analyze.html?d=social.fluffel.io</a><br></div><div><br></div><div><br></div><div>On Sat, Nov 2, 2019, at 01:12, Curtis J Schofield wrote:<br></div><blockquote type="cite" id="gmail-m_-7512885605015009420gmail-m_-6213124279714380938gmail-m_1142038452762535935gmail-m_-6913802066438686393gmail-m_-2561057427935395941gmail-m_-1436707897894659288gmail-m_-1252846040026057082gmail-m_-2066110737253625160gmail-m_-5019363608254918132gmail-m_-8466579641998479497gmail-m_-5220970652841391182gmail-m_-8288014390111105985qt"><div>Hi!<br></div><div><br></div><div>Just curious if there is an update on out of order certs.<br></div><div><br></div><div>The example has id0, id1, id2, id3  certs with id1 being the natural<br></div><div>root of id2 who is the root of id3, who is the root of id0.<br></div><div><br></div><div>We can correct the out of order problem by including id1,id2,id3 certs<br></div><div>in our chain.<br></div><div><br></div><div>It would be nice to hear from the erlang maintainers around what kind of<br></div><div>"out of order" erlang can handle nicely and if there is planned support for<br></div><div>our case!<br></div><div><br></div><div>Thank you again,<br></div><div><br></div><div>Curtis.<br></div><div><br></div><div><br></div><div><div><div>Sent through <a href="https://protonmail.com" target="_blank">ProtonMail</a> Encrypted Email Channel.<br></div></div><div><br></div></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div>On Saturday, October 19, 2019 4:34 PM, Curtis J Schofield <curtis@ram9.cc> wrote:<br></div><div><br></div><blockquote type="cite"><div>Hi! Thank you.<br></div><div><br></div><div><br></div><div>I included the root cert in the example. The root cert is id1 in cert chain - this is evident in the other file. <br></div><div><br></div><div>It seems because the root cert is out of order - the cert chain is invalid - IIRC this may be true for tls1.2 - however the negotiation is at TLS1.2<br></div><div><br></div><div><br></div><div>Thank you for your consideration!<br></div><div><br></div><div><br></div><div id="gmail-m_-7512885605015009420gmail-m_-6213124279714380938gmail-m_1142038452762535935gmail-m_-6913802066438686393gmail-m_-2561057427935395941gmail-m_-1436707897894659288gmail-m_-1252846040026057082gmail-m_-2066110737253625160gmail-m_-5019363608254918132gmail-m_-8466579641998479497gmail-m_-5220970652841391182gmail-m_-8288014390111105985qt-protonmail_mobile_signature_block"><div>Sent from ProtonMail Mobile<br></div></div><div><br></div><div><br></div><div>On Sat, Oct 19, 2019 at 10:51 AM, Ingela Andin <<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>> wrote:<br></div><blockquote type="cite"><div dir="ltr"><div><br></div><div>Hi!<br></div><div><br></div><div>"Unknown CA"  means that you did not have the ROOT certificate of the chian in your   "trusted store" (cacerts option).<br></div><div>If you do not own the ROOT certificate you can not trust the chain.<br></div><div><br></div><div>Regards Ingela Erlang/OTP Team - Ericsson AB<br></div><div><br></div><div><div dir="ltr">Den fre 18 okt. 2019 kl 21:52 skrev Curtis J Schofield <curtis@ram9.cc>:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Dear Erlang Questions:<br></div><div><br></div><div><br></div><div>SSL 9.0.2 mentions a patch to fix out of order cert chains<br></div><div><br></div><div>In SSL 9.2 we have a root CA and an out of order cert chain<br></div><div>for host <a rel="noreferrer" href="http://hooks.glip.com" target="_blank">hooks.glip.com</a>.<br></div><div><br></div><div>When we try to verify peer with the out of order cert<br></div><div>chain we get 'Unknown CA'.<br></div><div><br></div><div>Is this expected behaviour for Erlang SSL 9.2 with verify_peer ?<br></div><div><br></div><div>The <a rel="noreferrer" href="http://erlang.org/doc/apps/ssl/notes.html#ssl-9.0.2" target="_blank">http://erlang.org/doc/apps/ssl/notes.html#ssl-9.0.2</a> notes<br></div><div>mention that other care may need to be taken to ensure compatibility.<br></div><div><br></div><div>Reproduce error:<br></div><div><br></div><div><a rel="noreferrer" href="https://github.com/robotarmy/out-of-order-ssl" target="_blank">https://github.com/robotarmy/out-of-order-ssl</a><br></div><div><br></div><div>Thank you,<br></div><div>Curtis and Team DevEco<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>Sent through ProtonMail Encrypted Email Channel.<br></div><div><br></div><div><br></div><div>_______________________________________________<br></div><div>erlang-questions mailing list<br></div><div><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br></div><div><a rel="noreferrer" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br></div></blockquote></div></div></blockquote><div><br></div><div><br></div></blockquote><div><br></div></blockquote><div><br></div></div></blockquote></div>
</blockquote><div><br></div><div><br></div></blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote><div><br></div><div><br></div></blockquote></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>