> > 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 <https://github.com/openssl/openssl/blob/19e277dd19f2897f6a7b7eb236abe46655e575bf/ssl/ssl_cert.c#L426> 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) <https://github.com/openssl/openssl/blob/19e277dd19f2897f6a7b7eb236abe46655e575bf/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-us...@dukhovni.org> wrote: > > On 3 Oct 2021, at 12:33 pm, Alex Robuchon <alexandre.robuc...@gmail.com> > 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. > >
