<div dir="auto">> <span style="font-family:sans-serif;font-size:12.8px">You don't have to explain the code to me. :-)</span><br><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px"><br></span></div><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px">^^. Ok. I was also trying to explain what I understood so you can correct me if I'm wrong.</span></div><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px"><br></span></div><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px">Everything is Cristal clear now.</span></div><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px"><br></span></div><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px">Thanks a million.</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 3 Oct 2021, 22:25 Viktor Dukhovni, <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Oct 03, 2021 at 09:33:29PM +0200, Alex Robuchon wrote:<br>
<br>
> > Not quite, a candidate chain is constructed from whatever certificates the<br>
> > peer (server in your case) provided, and then passed to the callback with<br>
> > "preverify_ok" set to false (for the top certificate), because the chain is<br>
> > not trusted.<br>
> <br>
> This confuses me a little bit because I thought the callback function set<br>
> with *SSL_set_verify* would have the "trusted first" valid chain.<br>
<br>
But there is no trust store configured, so trust first is a no-op.<br>
The constructed chain consists entirely of certificates from the<br>
peer, and last certificate in the chain (the ultimate issuing CA)<br>
is still not trusted, so preverify_ok = 0.<br>
<br>
<br>
> Are you sure you are not speaking as if eventmachine was using the<br>
> *SSL_CTX_set_cert_verify_callback* ?<br>
<br>
I rewrote the OpenSSL chain construction code for OpenSSL 1.1.0.  Yes, I<br>
am sure.<br>
<br>
> - *build_chain* that will apply the trusted first algorithm and replace the<br>
> certificate chain passed by the server with the valid one ( if found ).<br>
<br>
The code in eventmachine does not configure any trusted certificates for<br>
the SSL_CTX handles used to create the SSL connections.  So<br>
trusted-first is a no-op.<br>
<br>
> - *internal_verify *which now has the new chain and will call *verify_callback<br>
> *( the callback function passed to SSL_set_verify ) for every certificate<br>
> in this new chain in reverse order.<br>
<br>
You don't have to explain the code to me. :-)<br>
<br>
> > But given all the evidence before me, I'd want to delete that code and<br>
> > never see it again.<br>
> <br>
> I hear you :).<br>
<br>
That code is beyond repair, it needs to be thrown out, and replaced with<br>
ground up by the book TLS connection establishment.<br>
<br>
#1. No compiled in private keys<br>
<br>
#2. Configure the SSL_CTX with the desired list of trust anchors<br>
<br>
#3. Reuse the SSL_CTX for multiple connections that share the same<br>
    trust and other general settings<br>
<br>
#4. Prior to SSL_connect(), tell the SSL library what hostname you want<br>
    to verify via SSL_set1_host(3).  Let OpenSSL do all the heavy<br>
    lifting of certificate and name checks.<br>
<br>
#5. DO NOT attempt to override certificate chain verifiction in the<br>
    verify callback.  Use the verify callback only for logging or<br>
    similar diagnostic purposes.<br>
<br>
#6. Return "preverify_ok" unmodified, unless your application is doing<br>
    opportunistic unauthenticated TLS, or wants to complete the<br>
    handshake even on verification failure, and then gracefully tear<br>
    down the application-layer session with the peer (after checking the<br>
    verification status at connection completion).<br>
<br>
    If preverify_ok is false (0), OpenSSL chain verification failed,<br>
    your application is unlikely to do better.  Return 0, and the<br>
    TLS handshake will be aborted, you can log the error reason,<br>
    chain depth, ... in the verify callback.<br>
<br>
-- <br>
    Viktor.<br>
</blockquote></div>