|
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 <tomas@xxxxxxxxxxx>
Sent: Friday, November 5, 2021 1:19 PM To: Jason Schultz <jetson23@xxxxxxxxxxx>; openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx> 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.] |
