<div dir="ltr"><div class="gmail_extra"><div>Hi!<br><br>The remaining issues I think comes down to that the server in your example does not have access to all the CA-certificates so it can not build its on chain<br></div><div>properly. CA certificates are both used to build the own chain and verify the others chain. This will mean that the server will only send its own cert to the client and not<br>the intermediate CA. TLS specifies that only the ROOT CA may be left out of the chain. However PKIX standard does allow for the user to specify an intermediate certificate to be the trusted anchor. So in the latest erlang ssl application there is a new option partial_chain to handle this. In older version however some partial chains where 
"accidentally" accepted by default (if all intermediate CAs where 
specified in cacerts). <br><br><div>From the documentation:<br></div><div><dl><dt><b>{partial_chain, fun(Chain::[DerCert]) -> {trusted_ca, DerCert} | unknown_ca </b></dt><dd>
        Claim an intermediat CA in the chain as trusted. TLS will then perform the public_key:pkix_path_validation/3
        with the selected CA as trusted anchor and the rest of the chain.
      </dd></dl><p>Also your CRL-check does not really check everything specified by the RFC. For now you need to call <a name="14908e47ce70bf81_pkix_crls_validate-3"><span>public_key:pkix_crls_validate/3  in your verify_fun,  if you want a proper check. This is a little cumbersome and we are working on creating a better integration of it in ssl.<br></span></a></p></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<br></div><br></div><br><div class="gmail_quote">2014-10-08 10:55 GMT+02:00 Andre Graf <span dir="ltr"><<a href="mailto:andre.graf@erl.io" target="_blank">andre.graf@erl.io</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">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div><div>
    <div>On 10/08/2014 10:47 AM, Ingela Andin
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Hi!<br>
        <div>
          <div class="gmail_extra"><br>
            <div class="gmail_quote">2014-10-08 0:22 GMT+02:00 Andre
              Graf <span dir="ltr"><<a href="mailto:andre.graf@erl.io" target="_blank">andre.graf@erl.io</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">Hi there,<br>
                <br>
                today I wrote a EUnit test suite that should check the
                SSL connection<br>
                setup to an Erlang SSL server. Although the test cases
                are pretty simple<br>
                and standard I stumbled upon various inconsistencies
                when testing<br>
                against different OTP versions (R15B02,
                R16B03-1,OTP-17.3.1). I thought<br>
                I share my findings.<br>
                <br>
                The different test cases are:<br>
                <br>
                1. Connect No Client Auth (SUCCESS)<br>
                2. Connect No Client Auth (FAIL: wrong CA)<br>
                3. Connect Client Auth (SUCCESS)<br>
                4. Connect Client Auth (FAIL: no Client Cert provided)<br>
                5. Connect Client Auth (FAIL: Client Cert expired)<br>
                6. Connect Client Auth (FAIL: CRL check, Client Cert
                revoked)<br>
                7. Connect Client Auth (SUCCESS, CRL check)<br>
                <br>
                Inconsistencies in expected return of 'ssl:connect/2' in
                test case 2:<br>
                - R15B02: {error,"unknown ca"}}<br>
                - R16B03-1: {error,{tls_alert,"unknown ca"}}<br>
                - OTP-17.3.1: {error,{tls_alert,"unknown ca"}}<br>
                <br>
              </blockquote>
              <div><br>
              </div>
              <div>This is part of the documented potential
                incompatibility that we choose to do to to improve the
                quality of the error messages.<br>
              </div>
              <div><br>
                 </div>
              <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                Inconsistencies in expected return of 'ssl:connect/2' in
                test case 3:<br>
                - R15B02: {ok, Sock}<br>
                - R16B03-1: {ok, Sock}<br>
                - OTP-17.3.1: {error,closed}<br>
                <br>
              </blockquote>
              <div><br>
              </div>
              <div>Will try your test case when I get time. Seems
                strange.<br>
              </div>
              <div><br>
                 </div>
              <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                Inconsistencies in expected return of 'ssl:connect/2' in
                test case 4:<br>
                - R15B02: {error,esslconnect}<br>
                - R16B03-1: {error,{tls_alert,"handshake failure"}}<br>
                - OTP-17.3.1: {error,{tls_alert,"handshake failure"}}<br>
                <br>
              </blockquote>
              <div> <br>
                This is also part of the documented potential
                incompatibility that we choose to do to to improve the
                quality of the error messages.<br>
                <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">
                Inconsistencies in expected return of 'ssl:connect/2' in
                test case 5:<br>
                - R15B02: {error,"certificate expired"}<br>
                - R16B03-1: {error,{tls_alert,"certificate expired"}}<br>
                - OTP-17.3.1: {error,{tls_alert,"unknown ca"}}<br>
                <br>
              </blockquote>
              <div> Will try your test case when I get time. Seems
                strange.<br>
                <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">
                Inconsistencies in expected return of 'ssl:connect/2' in
                test case 6:<br>
                - R15B02: SSL handshake process crashes<br>
                - R16B03-1: {error,{tls_alert,"certificate revoked"}}<br>
                - OTP-17.3.1: {error,closed}<br>
                <br>
              </blockquote>
              <div> <br>
              </div>
              <div>Alas you can never depend on getting the correct
                error message an not {error,closed} as<br>
              </div>
              <div>tcp does note have a delivery guarantee on
                application level, only on transport level. <br>
              </div>
              <div>So ssl sends its alert and then closes the socket,
                and with bad timing the application may<br>
              </div>
              <div>receive the socket close before it receives the error
                message data.<br>
              </div>
              <div><br>
              </div>
              <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                Inconsistencies in expected return of 'ssl:connect/2' in
                test case 7:<br>
                - R15B02: {ok, Socket}<br>
                - R16B03-1: {ok, Socket}<br>
                - OTP-17.3.1: {error,{tls_alert,"unknown ca"}}<br>
                <br>
              </blockquote>
              <div> <br>
                Will try your test case when I get time. Seems strange.<br>
                <br>
                 <br>
              </div>
              <div>Regards Ingela Erlang/OTP team - Ericsson AB<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">
                No inconsistencies in test case 1. :)<br>
                <br>
                The code is available on <a href="https://github.com/dergraf/erlang_ssl_tester" target="_blank">https://github.com/dergraf/erlang_ssl_tester</a>.<br>
                <br>
                Cheers,<br>
                André<br>
                _______________________________________________<br>
                erlang-questions mailing list<br>
                <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
                <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
              </blockquote>
            </div>
            <br>
          </div>
        </div>
      </div>
    </blockquote></div></div>
    Hello Ingela,<br>
    <br>
    Thanks for your reply. Please let me know if you need any help with
    the test case. The tests should pass on R16B03-1, just run 'rebar
    eunit'. <br>
    <br>
    Cheers,<br>
    André<br>
  </div>

</blockquote></div><br></div></div>