Re: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate )

[Alex Robuchon <alexandre.robuchon@xxxxxxxxx>]

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.

This confuses me a little bit because I thought the callback function set with SSL_set_verify would have the "trusted first" valid chain. Are you sure you are not speaking as if eventmachine was using the SSL_CTX_set_cert_verify_callback ?

 

From what I see from the source code ( master )

The tls_post_process_server_certificate function calls ssl/ssl_cert.c#ssl_verify_cert_chain 

if (s->ctx->app_verify_callback != NULL)
i = s->ctx->app_verify_callback(ctx, s->ctx->app_verify_arg);
else
i = X509_verify_cert(ctx);
return i   

Since eventmachine do not set the app_verify_callback so the default X509_verify_cert is used from crypto/x509/x509_vfy.c (L261)

The function X509_verify_cert calls verify_chain(ctx) line 295 which in turns calls:

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

- internal_verify which now has the new chain and will call verify_callback ( the callback function passed to SSL_set_verify ) for every certificate in this new chain in reverse order.

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 )

But the evenmachine callback ignores "preverify_ok" and goes through the
motions of doing some sort of verification of each certificate.

yes indeed 

But given all the evidence before me, I'd want to delete that code and
never see it again.

I hear you :). 

On Sun, Oct 3, 2021 at 6:48 PM Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote:

> On 3 Oct 2021, at 12:33 pm, Alex Robuchon <alexandre.robuchon@xxxxxxxxx> wrote:
>
> So I suppose openssl skip the part that is supposed to build the chain when no store is configured.

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.

But the evenmachine callback ignores "preverify_ok" and goes through the
motions of doing some sort of verification of each certificate.

Ultimately, it will attempt to "verify" the leaf certificate, and if it
can somehow do a fair job of that (by building its own chain, checking
all the signatures, doing the name checks (for a name that does not
appear to be passed to the verification function), then in theory
the checks at depths above 0 are just silly opportunities to fail and
the EE cert check would be enough.

But given all the evidence before me, I'd want to delete that code and
never see it again.

--
        Viktor.