<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>