<div dir="ltr">HI!<br><div><div class="gmail_extra"><br><div class="gmail_quote">2014-08-11 16:16 GMT+02:00 Ben Murphy <span dir="ltr"><<a href="mailto:benmmurphy@gmail.com" target="_blank">benmmurphy@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(I originally sent this to erlang-bugs but it doesn't look like it<br>
made it there)<br>
<br>
We have a problem where an SSL server sends back a certificate chain<br>
that is invalid according to the TLS 1.2 specification and erlang<br>
rejects this chain with an unknown ca error. However, openssl and<br>
browsers will accept this chain because they are less strict about<br>
validation.<br>
<br>
The chain looks something like:<br>
<br>
0. Server Cert issued by Intermediate Cert<br>
1. Intermediate Cert issued by Root Cert<br>
2. Root Cert issued by Root Cert<br>
3. Unrelated certificate<br>
4. Unrelated certificate<br></blockquote><div><br><br></div>What server is sending such a chain? Could you give me a concrete example,maybe of list if you do not want to expose<br></div><div class="gmail_quote">it to the world. <br>
</div><div class="gmail_quote"><div><br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Which is invalid according to: <a href="http://www.ietf.org/rfc/rfc5246.txt" target="_blank">http://www.ietf.org/rfc/rfc5246.txt</a><br>
<br>
certificate_list<br>
This is a sequence (chain) of certificates. The sender's<br>
certificate MUST come first in the list. Each following<br>
certificate MUST directly certify the one preceding it. Because<br>
certificate validation requires that root keys be distributed<br>
independently, the self-signed certificate that specifies the root<br>
certificate authority MAY be omitted from the chain, under the<br>
assumption that the remote end must already possess it in order to<br>
validate it in any case<br>
<br>
Looking at the openssl code they start at the beginning of the chain<br>
then recursively find the issuer in order to build up a chain. While<br>
the erlang ssl code assumes the last certificate in the chain is the<br>
root CA (ssl_certificate:trusted_cert_and_path).<br>
<br></blockquote><div><br></div><div>It assumes that the last certificate is the ROOT or the certificate just before<br></div><div>the ROOT (as the ROOT cert may be left out as you said above) and if<br></div><div>the ROOT is left out it will try to find the ROOT in its database. If the ROOT is part<br>
</div><div>of the chain it will still be looked up to make sure we already have it. <br></div><div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Maybe this is more of a feature request than a bug. But I was<br>
wondering if it would be possible for erlang to either accept these<br>
dodgy chains, provide an option when connecting to accept these dodgy<br>
chains or allow users to supply a function to modify the certificate<br>
chain before validation takes place.<br></blockquote><div><br><br></div><div>You can use the verify_fun to accept any path validation errors you want,<br></div><div>at your own risk as you are lowering the security requirements by doing so. <br>
</div><div><br>[...]<br></div></div><br><br></div><div class="gmail_extra">Regards Ingela Erlang/OTP team - Ericsson AB<br></div></div></div>