Setup of the non_fips_libctx (after help from this list a week or two ago):
non_fips_libctx = OSSL_LIB_CTX_new(); defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); I also call OSSL_PROVIDER_available(non_fips_libctx, "default") ...to verify this worked. I only load the default provider in the non-FIPS non-default library context. In case you need this info, for the fips library context, I call: OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf") With the following relevant info in openssl-fips-cnf: .include /usr/local/ssl/fipsmodule.cnf [openssl_init] providers = provider_sect # List of providers to load [provider_sect] default = default_sect # The fips section name should match the section name inside the # included fipsmodule.cnf. fips = fips_sect base = base_sect # If no providers are activated explicitly, the default one is activated implicitly. # See man 7 OSSL_PROVIDER-default for more details. # # If you add a section explicitly activating any other provider(s), you most # probably need to explicitly activate the default provider, otherwise it # becomes unavailable in openssl. As a consequence applications depending on # OpenSSL may not work correctly which could lead to significant system # problems including inability to remotely access the system. [default_sect] # activate = 1 [base_sect] activate = 1 And in fipsmodule.cnf: [fips_sect] activate = 1 conditional-errors = 1 security-checks = 1 module-mac = E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9 Also verifying this worked with the following: OSSL_PROVIDER_available(fips_libctx, "base") OSSL_PROVIDER_available(fips_libctx, "fips") For setting up the trusted store, when the application starts, it calls: ssl_trusted_certs = X509_STORE_new() ...and then reads all of the certificates in /etc/ssl/certs/ calling X509_STORE_add_cert(trusted_store,cert); ..for each one. Then, I make the following calls to set up intermediate certs in the trust store to be treated as trust-anchors: param = X509_VERIFY_PARAM_new(); X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_PARTIAL_CHAIN); X509_STORE_set1_param(ssl_trusted_certs, param); X509_VERIFY_PARAM_free(param); Then I set the store for verifying peer certs to this "global" store I created above: status = SSL_CTX_set1_verify_cert_store(ctx,ssl_trusted_certs); For the sake of completeness, I also call: status = SSL_CTX_set1_chain_cert_store(ctx, ssl_trusted_certs); ...to ensure OpenSSL has access to the entire store for forming a certificate chain to present to the peer in a handshake. My application can act as a client and/or a server, and in this case, it's acting as both the client and the server, with the same SSL_CTX. Also, this code has always worked with OpenSSL 1.1.1, which is why I was suspicious of either my library context/provider setup, or 3.0. Let me know if you need more info. Thanks, Jason ________________________________ From: Tomas Mraz <to...@openssl.org> Sent: Friday, November 5, 2021 1:19 PM To: Jason Schultz <jetso...@hotmail.com>; openssl-users@openssl.org <openssl-users@openssl.org> Subject: Re: Establishing connection errors On Fri, 2021-11-05 at 13:04 +0000, Jason Schultz wrote: > I know I've been raising a lot of issues this week, because of > varying reasons, but I've hit another one that seems like either an > OpenSSL problem, or something new/different I need to do with OpenSSL > 3.0 in connection establishment. > > To recap, I'm using two non-default library contexts, one for FIPS, > one for non-FIPS. There is an open issue in github regarding the call > to SSL_CTX_build_cert_chain(), but since the purpose of that call is > to have the server not include the root certificate when sending the > chain, I have left that out of my code for now, in order to continue > testing. It shouldn't affect what I'm trying to do. > > As far as connection set up, based on whether or not the user wants > FIPS (not using FIPS for this test), I call: > > ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); > > ...to set up my SSL_CTX. My understanding is that all SSL objects, > etc., created based on that SSL_CTX will use the appropriate library > context/providers. So beyond the providers and library context setup > and using SSL_CTX_new_ex(), I haven't changed any code to establish > TLS connections. I've tried to establish connections using both RSA > and ECDSA certificates/keys, self-signed, or a server cert that's > part of a chain. I'm just establishing a connection to myself, not > between two systems, just to try to get something working. I'll post > all of the handshake messages at the end of this message, but here > are the error messages I get when the client side receives the server > certificate (in this case it's a self signed RSA certificate): How do you set up the non_fips_libctx and how do you set up any certificate trust store within the SSL_CTX? -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]