<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Not quite, a candidate chain is constructed from whatever certificates the peer (server in your case) provided, and then passed to the callback with "preverify_ok" set to false (for the top certificate), because the chain is not trusted.<br></blockquote><div><br></div>This confuses me a little bit because I thought the callback function set with <b>SSL_set_verify</b> would have the "trusted first" valid chain. Are you sure you are not speaking as if eventmachine was using the <b>SSL_CTX_set_cert_verify_callback</b> ?<div> </div><div>From what I see from the source code ( master )<br><br>The <b>tls_post_process_server_certificate</b> function calls <a href="https://github.com/openssl/openssl/blob/19e277dd19f2897f6a7b7eb236abe46655e575bf/ssl/ssl_cert.c#L426">ssl/ssl_cert.c#ssl_verify_cert_chain</a> </div><div><font size="1">if (s->ctx->app_verify_callback != NULL)<br>        i = s->ctx->app_verify_callback(ctx, s->ctx->app_verify_arg);<br>    else<br>        i = X509_verify_cert(ctx);<br>return i   </font><br></div><div><br></div><div>Since eventmachine do not set the<font size="1"> </font><b>app_verify_callback</b> so the default <b>X509_verify_cert</b> is used from <a href="https://github.com/openssl/openssl/blob/19e277dd19f2897f6a7b7eb236abe46655e575bf/crypto/x509/x509_vfy.c#L261">crypto/x509/x509_vfy.c (L261)</a></div><div><br></div><div>The function <b>X509_verify_cert</b> calls <b>verify_chain(ctx)</b> line 295 which in turns calls:</div><div>- <b>build_chain</b> that will apply the trusted first algorithm and replace the certificate chain passed by the server with the valid one ( if found ). At the point the ctx has the new chain</div><div>- <b>internal_verify </b>which now has the new chain and will call <b>verify_callback </b>( the callback function passed to SSL_set_verify ) for every certificate in this new chain in reverse order.</div><div><br></div><div>During the build_chain process I notice the ctx->get_issuer ( which actually points to X509_STORE_CTX_get1_issuer which I suppose return 0 because eventmachine do not properly set the store )</div><div><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">But the evenmachine callback ignores "preverify_ok" and goes through the<br>motions of doing some sort of verification of each certificate.<br></blockquote><div><br></div><div>yes indeed </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">But given all the evidence before me, I'd want to delete that code and<br>never see it again.<br></blockquote><div><br></div><div>I hear you :). </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 3, 2021 at 6:48 PM Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</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">> On 3 Oct 2021, at 12:33 pm, Alex Robuchon <<a href="mailto:alexandre.robuchon@gmail.com" target="_blank">alexandre.robuchon@gmail.com</a>> wrote:<br>
> <br>
> So I suppose openssl skip the part that is supposed to build the chain when no store is configured.<br>
<br>
Not quite, a candidate chain is constructed from whatever certificates<br>
the peer (server in your case) provided, and then passed to the callback<br>
with "preverify_ok" set to false (for the top certificate), because the<br>
chain is not trusted.<br>
<br>
But the evenmachine callback ignores "preverify_ok" and goes through the<br>
motions of doing some sort of verification of each certificate.<br>
<br>
Ultimately, it will attempt to "verify" the leaf certificate, and if it<br>
can somehow do a fair job of that (by building its own chain, checking<br>
all the signatures, doing the name checks (for a name that does not<br>
appear to be passed to the verification function), then in theory<br>
the checks at depths above 0 are just silly opportunities to fail and<br>
the EE cert check would be enough.<br>
<br>
But given all the evidence before me, I'd want to delete that code and<br>
never see it again.<br>
<br>
-- <br>
        Viktor.<br>
<br>
</blockquote></div>