Running update-ca-trust(8) in the container breaks OpenSSL by emptying its /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

[miabbott]

Describe the bug
Downloading custom CA certificates and running update-ca-trust in the toolbox container results in a container that is unable to access the certificate bundle

Steps how to reproduce the behaviour

1. podman pull registry.fedoraproject.org/fedora-toolbox:42
2. toolbox create
3. toolbox enter
4. download a CA certificate into /etc/pki/ca-trust/source/anchors
5. update-ca-trust
6. try to dnf install htop

Expected behaviour
CA certificates are successfully updated and dnf, curl operations afterwards are successfuil

Actual behaviour

core@localhost:~$ podman pull registry.fedoraproject.org/fedora-toolbox:42
Trying to pull registry.fedoraproject.org/fedora-toolbox:42...
Getting image source signatures
Copying blob 744b9d8a39de done   | 
Copying config 79317230b6 done   | 
Writing manifest to image destination
79317230b636a569ec983897c8ceee2612f62a0be9f845967f58822e6805db4a
core@localhost:~$ toolbox create
Created container: fedora-toolbox-42
Enter with: toolbox enter
core@localhost:~$ toolbox enter
⬢ [core@toolbx ~]$ cd /etc/pki/ca-trust/source/anchors
⬢ [core@toolbx anchors]$ sudo curl -O https://xxxxxxxx.redhat.com/certs/Current-IT-Root-CAs.pem
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3814  100  3814    0     0  20525      0 --:--:-- --:--:-- --:--:-- 20616
⬢ [core@toolbx anchors]$ sudo update-ca-trust
⬢ [core@toolbx anchors]$ sudo dnf install htop
Updating and loading repositories:
 Fedora 42 openh264 (From Cisco) - x86_64                                                                                                                                                                                                                                                                   ???% |   0.0   B/s |   0.0   B |  00m00s
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-42&arch=x86_64 - https
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-42&arch=x86_64 - https
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-42&arch=x86_64 - https
>>> Librepo error: Cannot prepare internal mirrorlist: Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem]                                            
 Fedora 42 - x86_64 - Updates                                                                                                                                                                                                                                                                               ???% |   0.0   B/s |   0.0   B |  00m00s
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 - https://mirro
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 - https://mirro
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 - https://mirro
>>> Librepo error: Cannot prepare internal mirrorlist: Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem]                                                
Failed to download metadata (metalink: "https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64") for repository "updates"
 Librepo error: Cannot prepare internal mirrorlist: Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem]
⬢ [core@toolbx anchors]$ curl -v https://getfedora.org
* Host getfedora.org:443 was resolved.
* IPv6: 2600:1f14:fad:5c02:7c8a:72d0:1c58:c189, 2620:52:3:1:dead:beef:cafe:fed6, 2620:52:3:1:dead:beef:cafe:fed7, 2604:1580:fe00:0:dead:beef:cafe:fed1, 2600:2701:4000:5211:dead:beef:fe:fed3, 2605:bc80:3010:600:dead:beef:cafe:fed9
* IPv4: 8.43.85.73, 152.19.134.142, 140.211.169.196, 152.19.134.198, 38.145.60.21, 38.145.60.20, 34.221.3.152, 8.43.85.67, 67.219.144.68
*   Trying [2600:1f14:fad:5c02:7c8a:72d0:1c58:c189]:443...
* Immediate connect fail for 2600:1f14:fad:5c02:7c8a:72d0:1c58:c189: Network is unreachable
*   Trying [2620:52:3:1:dead:beef:cafe:fed6]:443...
* Immediate connect fail for 2620:52:3:1:dead:beef:cafe:fed6: Network is unreachable
*   Trying [2620:52:3:1:dead:beef:cafe:fed7]:443...
* Immediate connect fail for 2620:52:3:1:dead:beef:cafe:fed7: Network is unreachable
*   Trying [2604:1580:fe00:0:dead:beef:cafe:fed1]:443...
* Immediate connect fail for 2604:1580:fe00:0:dead:beef:cafe:fed1: Network is unreachable
*   Trying [2600:2701:4000:5211:dead:beef:fe:fed3]:443...
* Immediate connect fail for 2600:2701:4000:5211:dead:beef:fe:fed3: Network is unreachable
*   Trying [2605:bc80:3010:600:dead:beef:cafe:fed9]:443...
* Immediate connect fail for 2605:bc80:3010:600:dead:beef:cafe:fed9: Network is unreachable
*   Trying 8.43.85.73:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
* error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
* closing connection #0
curl: (77) error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

Output of toolbox --version (v0.0.90+)

core@localhost:~$ toolbox --version
toolbox version 0.1.2

Toolbx package info (rpm -q toolbox)

core@localhost:~$ rpm -q toolbox
toolbox-0.1.2-1.fc42.x86_64

Output of podman version

core@localhost:~$ podman version
Client:        Podman Engine
Version:       5.5.1
API Version:   5.5.1
Go Version:    go1.24.3
Git Commit:    850db76dd78a0641eddb9ee19ee6f60d2c59bcfa
Built:         Wed Jun  4 20:00:00 2025
Build Origin:  Fedora Project
OS/Arch:       linux/amd64

Podman package info (rpm -q podman)

core@localhost:~$ rpm -q podman
podman-5.5.1-1.fc42.x86_64

Info about your OS

Reproduced this on a vanilla Fedora 42 Workstation install and my Fedora 42 Silverblue install

Additional context

This seems to have been introduced with v0.1.2 and I suspect it is related to #1644

By the description of that PR, I don't think what I am trying to do in the toolbox container should be necessary. But when I try to just access a resource that uses the custom CA cert in the host bundle, I am unable to:

core@localhost:~$ cd /etc/pki/ca-trust/source/anchors
core@localhost:/etc/pki/ca-trust/source/anchors$ sudo curl -O https://xxxxxxx.redhat.com/certs/Current-IT-Root-CAs.pem
[sudo] password for core: 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3814  100  3814    0     0  29328      0 --:--:-- --:--:-- --:--:-- 29565
core@localhost:/etc/pki/ca-trust/source/anchors$ sudo update-ca-trust
core@localhost:/etc/pki/ca-trust/source/anchors$ sudo dnf install htop
Updating and loading repositories:
 Fedora 42 - x86_64 - Updates                                                                                                                                                                                                                                                                               100% | 178.4 KiB/s |  30.9 KiB |  00m00s
 Fedora 42 - x86_64 - Updates                                                                                                                                                                                                                                                                               100% |   3.7 MiB/s |   2.0 MiB |  00m01s
Repositories loaded.
Package                                                                                                                Arch                    Version                                                                                                                Repository                                                                Size
Installing:
 htop                                                                                                                  x86_64                  3.4.1-1.fc42                                                                                                           updates                                                              456.4 KiB
Installing dependencies:
 hwloc-libs                                                                                                            x86_64                  2.12.0-1.fc42                                                                                                          fedora                                                                 2.9 MiB

Transaction Summary:
 Installing:         2 packages

Total size of inbound packages is 2 MiB. Need to download 2 MiB.
After this operation, 3 MiB extra will be used (install 3 MiB, remove 0 B).
Is this ok [y/N]: n
Operation aborted by the user.
core@localhost:/etc/pki/ca-trust/source/anchors$ podman pull registry.fedoraproject.org/fedora-toolbox:42
Trying to pull registry.fedoraproject.org/fedora-toolbox:42...
Getting image source signatures
Copying blob 744b9d8a39de skipped: already exists  
Copying config 79317230b6 done   | 
Writing manifest to image destination
79317230b636a569ec983897c8ceee2612f62a0be9f845967f58822e6805db4a
core@localhost:/etc/pki/ca-trust/source/anchors$ toolbox create
Created container: fedora-toolbox-42
Enter with: toolbox enter
core@localhost:/etc/pki/ca-trust/source/anchors$ cd
core@localhost:~$ toolbox enter
⬢ [core@toolbx ~]$ git clone https://xxxxxxx.redhat.com/rhel-lightspeed/enhanced-shell/cla-tests.git
Cloning into 'cla-tests'...
fatal: unable to access 'https://xxxxxx.redhat.com/rhel-lightspeed/enhanced-shell/cla-tests.git/': SSL certificate problem: self-signed certificate in certificate chain

[debarshiray]

Oops! From a very high level, reading through the original discussions for Flatpak, I suspect this has got to do with both DNF and Git using OpenSSL, but I won't be surprised if there's more to it. My general understanding from talking to people who actually understand how CA certificates and cryptographic libraries work is that GnuTLS should "just work", NSS is expected to work, and I didn't get a clear response about OpenSSL.

Just to be sure that we are on the same page, once you enter the Toolbx container, it has these files:

⬢ [rishi@toolbx ~]$ cat /etc/pkcs11/modules/p11-kit-trust.module 
# Written by Toolbx
# https://containertoolbx.org/

module: p11-kit-client.so

⬢ [rishi@toolbx ~]$ ls -l /usr/lib64/pkcs11/p11-kit-client.so 
-rwxr-xr-x. 1 root root 1207280 Jan 17 01:00 /usr/lib64/pkcs11/p11-kit-client.so

... and there's a p11-kit server process on the host that looks like this:

$ ps aux | grep p11-kit
rishi      18236  0.0  0.0   6368  1216 ?        Ss   12:06   0:00 server --name /run/user/1000/toolbox/pkcs11 --provider p11-kit-trust.so pkcs11:model=p11-kit-trust?write-protected=yes

You have to be careful with this second one, because Flatpak also starts a similar looking, but not identical, process.

If this is the case, then one way to work around this problem is to remove /etc/pkcs11/modules/p11-kit-trust.module and /usr/lib64/pkcs11/p11-kit-client.so from the container. Delete the former with rm(1), and the latter by removing the p11-kit-client (Rawhide) or p11-kit-server (F41 and F42) RPM. Stop the container with podman stop and try to enter it again and it should work as before.

[debarshiray]

As for the bug itself, I can reproduce this:

⬢ [core@toolbx ~]$ git clone https://xxxxxxx.redhat.com/rhel-lightspeed/enhanced-shell/cla-tests.git
Cloning into 'cla-tests'...
fatal: unable to access 'https://xxxxxx.redhat.com/rhel-lightspeed/enhanced-shell/cla-tests.git/': SSL certificate problem: self-signed certificate in certificate chain

However, I am puzzled by the DNF behaviour.

I have been testing the code by running these in the container:

⬢ [rishi@toolbx ~]$ sudo dnf install gnutls-utils
...
⬢ [rishi@toolbx ~]$ p11tool --list-all-certs 'pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust'
...
<shows the custom CA certificates I installed on the host>
...
⬢ [rishi@toolbx ~]$ p11tool --list-all-certs 'pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=Default%20Trust'
...
<shows the public CA certificates that were there by default>
...

The outputs should be identical to those on the host.

Running DNF as part of the above without touching the certificates inside the container (ie., without update-ca-trust(1), etc.) doesn't show the Curl and Librepo errors that you see.

However, if I install a *.repo file that needs the custom CA certificates, then it starts to complain:

⬢ [rishi@toolbx ~]$ sudo dnf install htop
Updating and loading repositories:
 RCM Tools for Fedora 42 (RPMs)                                                                                                                                             ???% |   0.0   B/s |   0.0   B |  00m03s
>>> Curl error (60): SSL peer certificate or SSH remote key was not OK for https://xxxxxx.redhat.com/rel-eng/RCMTOOLS/latest-RCMTOOLS-2-F-42/compose/Everything/x86_64/os/repodata/repomd.xml [SSL certifica
>>> Curl error (60): SSL peer certificate or SSH remote key was not OK for https://xxxxxx.redhat.com/rel-eng/RCMTOOLS/latest-RCMTOOLS-2-F-42/compose/Everything/x86_64/os/repodata/repomd.xml [SSL certifica
>>> Curl error (60): SSL peer certificate or SSH remote key was not OK for https://xxxxxx.redhat.com/rel-eng/RCMTOOLS/latest-RCMTOOLS-2-F-42/compose/Everything/x86_64/os/repodata/repomd.xml [SSL certifica
>>> Curl error (60): SSL peer certificate or SSH remote key was not OK for https://xxxxxx.redhat.com/rel-eng/RCMTOOLS/latest-RCMTOOLS-2-F-42/compose/Everything/x86_64/os/repodata/repomd.xml [SSL certifica
>>> Librepo error: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried                                                                                                          
Repositories loaded.
Package                                                                 Arch             Version                                                                  Repository                                    Size
Installing:
 htop                                                                   x86_64           3.4.1-1.fc42                                                             updates                                  456.4 KiB
Installing dependencies:
 hwloc-libs                                                             x86_64           2.12.0-1.fc42                                                            fedora                                     2.9 MiB

Transaction Summary:
 Installing:         2 packages

Total size of inbound packages is 2 MiB. Need to download 2 MiB.
After this operation, 3 MiB extra will be used (install 3 MiB, remove 0 B).
Is this ok [y/N]: N
Operation aborted by the user.

The errors are also different - Curl error (60) versus Curl error (77). I suppose calling update-ca-trust(1) inside the container with p11-kit-client.so and p11-kit server does something weird.

[debarshiray]

... one way to work around this problem is to remove /etc/pkcs11/modules/p11-kit-trust.module and /usr/lib64/pkcs11/p11-kit-client.so from the container. Delete the former with rm(1), and the latter by removing the p11-kit-client (Rawhide) or p11-kit-server (F41 and F42) RPM. Stop the container with podman stop and try to enter it again and it should work as before.

Another workaround is to use the quay.io/rhel-devel-tools/rhel-developer-toolbox:latest image.

[debarshiray]

@ueno tracked this down to this p11-kit commit.

With 'remote p11-kit' set up across the container and the host, running sudo update-ca-trust inside the container empties its /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem. That breaks OpenSSL, but GnuTLS continues to work over 'remote p11-kit':

⬢ [rishi@toolbx ~]$ gnutls-cli flathub.org
Processed 378 CA certificate(s).
...

[debarshiray]

I am closing this in favour of p11-glue/p11-kit#692

[miabbott]

Another workaround is to use the quay.io/rhel-devel-tools/rhel-developer-toolbox:latest image.

@debarshiray this didn't work for me:

$ toolbox create --image quay.io/rhel-devel-tools/rhel-developer-toolbox:latest
Created container: rhel-developer-toolbox-latest
Enter with: toolbox enter rhel-developer-toolbox-latest
$ toolbox enter rhel-developer-toolbox-latest
(container) $ cd /etc/pki/ca-trust/source/anchors
(container) $ sudo curl -O https://xxxxxxxx.redhat.com/certs/Current-IT-Root-CAs.pem
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3814  100  3814    0     0  30532      0 --:--:-- --:--:-- --:--:-- 30758
(container) $ sudo update-ca-trust extract
(container) $ sudo dnf install htop
Updating and loading repositories:
 Copr repo for toolset owned by rhcopr-project                                                                                                                                                                                                                                                              100% |   2.4 KiB/s | 283.0   B |  00m00s
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://coprbe.devel.redhat.com/results/rhcopr-project/toolset/fedora-42-x86_64/repodata/repomd.xml [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://coprbe.devel.redhat.com/results/rhcopr-project/toolset/fedora-42-x86_
>>> Librepo error: Cannot download repomd.xml: Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://coprbe.devel.redhat.com/results/rhcopr-project/toolset/fedora-42-x86_64/repodata/repomd.xml [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem]                                     
 Copr repo for osh-prod owned by @osh                                                                                                                                                                                                                                                                       100% |   3.0 KiB/s | 274.0   B |  00m00s
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://coprbe.devel.redhat.com/results/@osh/osh-prod/fedora-42-x86_64/repodata/repomd.xml [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://coprbe.devel.redhat.com/results/@osh/osh-prod/fedora-42-x86_64/repodata/repomd
>>> Librepo error: Cannot download repomd.xml: Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://coprbe.devel.redhat.com/results/@osh/osh-prod/fedora-42-x86_64/repodata/repomd.xml [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem]                                              
 RCM Tools for Fedora 42 (RPMs)                                                                                                                                                                                                                                                                             ???% |   0.0   B/s |   0.0   B |  00m00s
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://download.devel.redhat.com/rel-eng/RCMTOOLS/latest-RCMTOOLS-2-F-42/compose/Everything/x86_64/os/repodata/repomd.xml [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://download.devel.redhat.com/rel-eng/RCMTOOLS/lat
>>> Librepo error: Cannot download repomd.xml: Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://download.devel.redhat.com/rel-eng/RCMTOOLS/latest-RCMTOOLS-2-F-42/compose/Everything/x86_64/os/repodata/repomd.xml [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem]              
 Fedora 42 - x86_64 - Updates                                                                                                                                                                                                                                                                               ???% |   0.0   B/s |   0.0   B |  00m00s
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 - https://mirro
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 - https://mirro
>>> Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem] - https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 - https://mirro
>>> Librepo error: Cannot prepare internal mirrorlist: Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem]                                                
Failed to download metadata (metalink: "https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64") for repository "updates"
 Librepo error: Cannot prepare internal mirrorlist: Curl error (77): Problem with the SSL CA cert (path? access rights?) for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64 [error setting certificate file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem]
(container) $ ls -la /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem 
-r--r--r--. 1 root root 0 Jun 25 11:12 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

[debarshiray]

Another workaround is to use the quay.io/rhel-devel-tools/rhel-developer-toolbox:latest image.

@debarshiray this didn't work for me:

The quay.io/rhel-devel-tools/rhel-developer-toolbox:latest image already comes with the Red Hat CA certificates. There's no need to again download them and use update-ca-trust(8). :)

The bug here is that running update-ca-trust(8) with remote p11-kit empties the /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem file. See p11-glue/p11-kit#692

So, the workarounds are either to undo the remote p11-kit set-up or to not use update-ca-trust(8).

[miabbott]

The quay.io/rhel-devel-tools/rhel-developer-toolbox:latest image already comes with the Red Hat CA certificates. There's no need to again download them and use update-ca-trust(8). :)

ohhhhhhhhhh....that makes sense. thanks for pointing that out!