Bug 256902 - libfetch breaks usage of certctl managed store when security/ca_root_nss is installed
Summary: libfetch breaks usage of certctl managed store when security/ca_root_nss is i...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.2-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-30 11:53 UTC by Michael Osipov
Modified: 2021-08-05 06:19 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Osipov 2021-06-30 11:53:25 UTC
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.
Comment 1 Michael Osipov 2021-06-30 11:56:19 UTC
fetch output:
> root@deblndw013x:/usr/ports
> # fetch -v https://deblndw011x.ad001.siemens.net/
> resolving server address: deblndw011x.ad001.siemens.net:443
> SSL options: 82004854
> Peer verification enabled
> Using CA cert file: /usr/local/etc/ssl/cert.pem
> Certificate verification failed for /C=DE/ST=Bayern/L=Muenchen/O=Siemens/serialNumber=ZZZZZZA1/OU=Siemens Trust Center/CN=Siemens Root CA V3.0 2016
> 34370727936:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
> fetch: https://deblndw011x.ad001.siemens.net/: Authentication error

> root@deblndw013x:/usr/ports
> # SSL_CA_CERT_PATH=/etc/ssl/certs  fetch -v https://deblndw011x.ad001.siemens.net/
> resolving server address: deblndw011x.ad001.siemens.net:443
> SSL options: 82004854
> Peer verification enabled
> Using CA cert file: /usr/local/etc/ssl/cert.pem
> Using CA cert path: /etc/ssl/certs
> Verify hostname
> TLSv1.3 connection established using TLS_AES_256_GCM_SHA384
> Certificate subject: /C=DE/O=Siemens/OU=LDA DW/CN=deblndw011x.ad001.siemens.net
> Certificate issuer: /C=DE/ST=Bayern/L=Muenchen/O=Siemens/serialNumber=ZZZZZZB7/OU=Siemens Trust Center/CN=Siemens Issuing CA Intranet Server 2017
> requesting https://deblndw011x.ad001.siemens.net/
> remote size / mtime: 45 / 1623218965
> fetch.out                                               45  B  811 kBps    00s