<div dir="ltr">Hi!<br><div><div class="gmail_extra"><div class="gmail_quote"><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>
      Is it possible to use public_key:pkix_crls_validate with CRLs not
      using the Distribution Point extension?<br>
      <br></div></div></blockquote><div> <br></div>You can create a DP for the input.  Outlned  from the RFC: <br></div><div class="gmail_quote"><br><div>The CRLs that should be considerd in CRL processing are:<br></div><div><pre class=""> "For each distribution point (DP) in the certificate's CRL<br> distribution points extension, for each corresponding CRL in the
   local CRL cache"</pre>run algorithm in public_key and <br></div><div><br></div><div><pre class=""> "if the revocation status has not been determined, repeat the process
   above with any available CRLs not specified in a distribution point
   but issued by the certificate issuer.  For the processing of such a
   CRL, assume a DP with both the reasons and the cRLIssuer fields
   omitted and a distribution point name of the certificate issuer.
   That is, the sequence of names in fullName is generated from the
   certificate issuer field as well as the certificate issuerAltName
   extension."<br></pre><pre class="">Regards Ingela Erlang/OTP team - Ericsson AB<br></pre><pre class=""><br></pre></div><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>
      All the best,<br>
      André<div><div class="h5"><br>
      <br>
      On 10/13/2014 11:48 AM, Ingela Andin wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      <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="14931c2307d78808_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>
    </blockquote>
    <br>
  </div></div></div>

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