[Bug 256902] libfetch breaks usage of certctl managed store when security/ca_root_nss is installed

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256902

            Bug ID: 256902
           Summary: libfetch breaks usage of certctl managed store when
                    security/ca_root_nss is installed
           Product: Base System
           Version: 12.2-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: michael.osipov@siemens.com

I have already discussed this some time ago with kevans@ who wanted to talk
with bapt@ about this, but we never have got around to report an actual issue.

We heavily rely on certctl(8) developed by allanjude@ and kevans@ to add all
root and intermediate CAs for Siemens in /usr/local/share/certs:
> # certctl list | grep -i -e "QuoVadis Enterprise"  -e Siemens
> 0e436b80.0      Siemens Issuing CA Class OneAD 04
> 0e91b229.0      Siemens Issuing CA Class OneAD 14
> 17c10339.0      Siemens Issuing CA Class OneAD 05
> 1c683ff3.0      Siemens Issuing CA Class OneAD 13
> 1c7620aa.0      Siemens Issuing CA Internet Code Signing 2016
> 1d069c00.0      Siemens Issuing CA Class OneAD 10
> 2b9d74f0.0      Siemens Issuing CA EE Network Smartcard Auth 2016
> 31e09dd6.0      Siemens Issuing CA Class OneAD 11
> 3210d285.0      Siemens Issuing CA Class OneAD 03
> 4ca5f54b.0      QuoVadis Enterprise Trust CA 2 G3
> 55683be0.0      Siemens Issuing CA EE Auth 2020
> 681ad634.0      Siemens Issuing CA Internet Server 2016
> 780389f9.0      QuoVadis Enterprise Trust CA 1 G3
> 7b1c186e.0      Siemens Issuing CA Class OneAD 06
> 81841955.0      Siemens Issuing CA EE Network Smartcard Auth 2020
> 8aac0ad6.0      Siemens Issuing CA EE Enc 2020
> 8af2d467.0      Siemens OneAD Root CA
> 8dc03e53.0      Siemens Internet CA V1.0
> 9245e478.0      Siemens Issuing CA Class OneAD 02
> 930b5fed.0      Siemens Issuing CA Multi Purpose 2016
> 970040fc.0      Siemens Issuing CA Class OneAD 09
> 9ec27e42.0      Siemens Issuing CA Intranet Server 2016
> a331fcb4.0      Siemens Issuing CA EE Auth 2016
> a382b08f.0      Siemens Trust Center Root-CA V2.0
> aec1ff25.0      Siemens Issuing CA Class OneAD 08
> b428065f.0      Siemens Issuing CA EE Enc 2016
> b5d79467.0      QuoVadis Enterprise Trust CA 3 G3
> bc2924b7.0      Siemens Issuing CA Class OneAD 01
> bd411d1f.0      Siemens Issuing CA Class OneAD 00
> be133774.0      Siemens Issuing CA Medium Strength Authentication 2020
> c2cf79c6.0      Siemens Issuing CA Class OneAD 12
> d4555404.0      Siemens Issuing CA Intranet Server 2017
> d7532a42.0      Siemens Issuing CA Internet Server 2017
> d9d79a66.0      Siemens Root CA V3.0 2016
> ddc2d14f.0      Siemens Issuing CA MSA Impersonalized Entities 2016
> e6a60b73.0      Siemens Issuing CA Intranet Code Signing 2016
> f103366b.0      Siemens Issuing CA Class OneAD 07
> f38f510d.0      Siemens Issuing CA Medium Strength Authentication 2016

So all applications linked to OpenSSL will use this store out of the box w/o
any further configuration.

Now, when I use fetch/pkg (libfetch) to get files hosted on corporate servers
certificate verification fails when some port/package (transitive dependency)
requires the security/ca_root_nss pestilence for some reason.

The reason is that libfetch has not been modified when certctl(8) introduced.
The fauly code is
(https://github.com/freebsd/freebsd-src/blob/373ffc62c158e52cde86a5b934ab4a51307f9f2e/lib/libfetch/common.c#L1082-L1105):

> 	if (getenv("SSL_NO_VERIFY_PEER") == NULL) {
> 		ca_cert_file = getenv("SSL_CA_CERT_FILE");
> 		if (ca_cert_file == NULL &&
> 		    access(LOCAL_CERT_FILE, R_OK) == 0)
> 			ca_cert_file = LOCAL_CERT_FILE;

This is installed by the security/ca_root_nss port thus

> 		if (ca_cert_file == NULL &&
> 		    access(BASE_CERT_FILE, R_OK) == 0)
> 			ca_cert_file = BASE_CERT_FILE;
> 		ca_cert_path = getenv("SSL_CA_CERT_PATH");
> 		if (verbose) {
> 			fetch_info("Peer verification enabled");
> 			if (ca_cert_file != NULL)
> 				fetch_info("Using CA cert file: %s",
> 				    ca_cert_file);
> 			if (ca_cert_path != NULL)
> 				fetch_info("Using CA cert path: %s",
> 				    ca_cert_path);
> 			if (ca_cert_file == NULL && ca_cert_path == NULL)
> 				fetch_info("Using OpenSSL default "
> 				    "CA cert file and path");
> 		}
> 		SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER,
> 		    fetch_ssl_cb_verify_crt);
> 		if (ca_cert_file != NULL || ca_cert_path != NULL)
> 			SSL_CTX_load_verify_locations(ctx, ca_cert_file,
> 			    ca_cert_path);
> 		else
> 			SSL_CTX_set_default_verify_paths(ctx);
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This never gets activated. I currently addded a workaround to login.conf
SSL_CA_CERT_PATH=/etc/ssl/certs, but it still has problems:
https://github.com/BastilleBSD/bastille/issues/410

A user's/admin's expectation is that the default system store is used unless
otherwise configured. I did neither install BASE_CERT_FILE nor LOCAL_CERT_FILE,
it has been imposed by others.

So fetch provides --ca-cert and --ca-path which shall override the default
store IF they are provided by the user OR SSL_CA_CERT_PATH/SSL_CA_CERT_FILE are
set.

kevans@ and we also concluded that security/ca_root_nss has very little use
sinse there is /etc/ssl/certs now and it could be reduced/removed at some point
in time.

There ports
> # grep -rl --include='*/Makefile' ca_root_nss . | wc -l
>     115

need to be revisited why they require security/ca_root_nss.

-- 
You are receiving this mail because:
You are the assignee for the bug.