My Firefox and Brave snaps don’t recognize the root certificate I installed on my KDE Neon 22.04
I placed them on both /etc/pki/ca-trust/source/anchors/ & /etc/ssl/certs/ and ran update-ca-certificates. Any ideas what I’m missing?
I don’t use Brave, but doesn’t FireFox provide a method to add new CAs? (Settings → Security → Certificates → View Certificates → Import)
tried that.
Didn’t add it right, it seems.
I’m trying to add the certificate to my OVIRT
I am not super surprised that a snap does not use certs from the system out of the box. I was googling if there is an interface/portal for such. Only found that the same issue exists in chromium. It seems the snaps use the certs provided by the base snap.
The most relevant comment over there:
The chromium snap's generated apparmor profile does include <abstractions/ssl_certs>, which allows read access to /etc/ssl/certs/ and /usr/local/share/ca-certificates/, among other paths¹.
So the problem is not confinement per se, but the fact that the core snap shadows these directories.
I wonder if using the system-files interface² would be a valid use case to expose these certificates in a read-only fashion.
¹ see /etc/apparmor.d/abstractions/ssl_certs for reference
² https://snapcraft.io/docs/system-files-interface
Maybe open an bug against firefox/brave?
edit: also related using-the-system-certificate-authorities
edit2: further down the rabbit hole there is a workaround
that “workaround” (actually an extremely gross hack) you link to is for UbuntuCore systems (where the read-only core snap is actually your root filesystem, so /etc/ssl is not writable at all), not for normal desktops …
by default all snaps (on non UbuntuCore systems) have full access to /etc/ssl/certs … but you need to make sure your cert is not linked to somewhere outside that dir (that would indeed be blocked by confinement) … see the recent discussion at:
https://forum.snapcraft.io/t/using-system-certificates-in-snap-that-relies-on-python-urllib/38032/9
1 Like
Thanks for the clarification. I also confirmed that the firefox snap has access to the host’s /etc/ssl/certs/ca-certificates.crt which is the output of `update-ca-certificates. (tested on a desktop ubuntu 22.04 in a LXD managed VM).
Can we have this done for browsers in the snap store, like Firefox and Brave?
It doesn’t seem to be pulling it.
Even Vivaldi (apt) doesn’t see it.
Fixed that with
sudo mv /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so.old && sudo ln -sf /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
Strangely, Edge (Flatpak) sees the CRT files I stored in /usr/local/share/ca-certificates/, which are symlinked to /etc/ssl/certs. Placing the PEM files in /etc/ssl/certs don’t work, so I think it just looks for the ones in /usr.
I know it’s Flatpak, but I feel like I should point out what I found out.
Think both Snaps and Flatpaks need to work together for some level of consistency IMHO
bumping since I’ve been migrating some computers from 20.04 to 24.04
What do you expect this bumping to achieve ? (certs can be used from /etc/ssl as pointed out (and even confirmed) above)
Didn’t work for me.
I checked the output of /etc/ssl/certs/ca-certificates.crt, and I confirmed both root and intermediate certs are there.
Here’s the Ansible config I push on Ubuntu computers in our environment:
- name: Make sure p11-kit is installeed
ansible.builtin.apt:
name:
- p11-kit
- p11-kit-modules
- name: Backup libnssckbi.so
ansible.builtin.copy:
src: /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
dest: /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so.old
remote_src: true
ignore_errors: true
- name: Delete original libnssckbi.so
ansible.builtin.file:
name: /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
state: absent
- name: Symlink p11-kit-trust.so to libnssckbi.so
ansible.builtin.file:
src: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so
dest: /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
state: link
ignore_errors: true
- name: Create Intermediate certificate
ansible.builtin.copy:
dest: /usr/local/share/ca-certificates/<hidden>_intermediate_ca-chain.crt
content: |
-----BEGIN CERTIFICATE-----
<hidden>
-----END CERTIFICATE-----
mode: '0644'
- name: Create root certificate
ansible.builtin.copy:
dest: /usr/local/share/ca-certificates/<hidden>_root_ca-chain.crt
content: |
-----BEGIN CERTIFICATE-----
<hidden>
-----END CERTIFICATE-----
mode: '0644'
- name: Update certificate store
ansible.builtin.command: /usr/sbin/update-ca-certificates --fresh
register: ubuntu_cert
changed_when: ubuntu_cert.rc != 0
Here, you showed that they’re supposed to reflect, but that doesn’t seem to be the case for me
Well it works for everyone else, I have no clue about ansible, but I don’t see /etc/ssl anywhere in your snippet and certs in /usr/local are not supported as you can read above
Either way, this thread is several years old and was resolved before you re-vived it with a different issue… You seem to do that all the time, please file new topics instead of reviving old unrelated stuff that is only remotely related to your specific issue
The authoritative answer from the snapd team from 2022 is here:
Is there something in Snapd I need to enable to make sure that it automatically mounts /etc/ssl when launching the Snap? Mine doesn’t seem to be the case
Dunno if this matters, but the user accounts are from Active Directory
ogra@styx:~$ sudo touch /etc/ssl/foobar
[sudo] Passwort für ogra:
ogra@styx:~$ snap run --shell firefox
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
ogra@styx:/home/ogra$ ls -l /etc/ssl
total 40
drwxr-xr-x 2 root root 20480 Oct 16 19:01 certs
-rw-r--r-- 1 root root 0 Jan 8 14:46 foobar
-rw-r--r-- 1 root root 12434 Sep 11 16:09 openssl.cnf
drwx--x--- 2 root ssl-cert 4096 Oct 16 19:01 private
ogra@styx:/home/ogra$
exit
ogra@styx:~$
It is automatically mounted into the snap namespace by default since 2022 …
not for me
According to this:
What I was doing SHOULD still be working. So the root cause appears to be that my /etc isn’t binding.
Yes that is odd, is your snapd up to date (though it would have to be pretty heavily outdated to not have this feature)… ?
jgamao@FTO-Y4M1:~$ snap --version
snap 2.67
snapd 2.67
series 16
neon 24.04
kernel 6.11.0-108013-tuxedo
jgamao@FTO-Y4M1:~$ snap debug --confinement
error: unknown flag `confinement'
jgamao@FTO-Y4M1:~$ snap debug confinement
strict
jgamao@FTO-Y4M1:~$
Looks fine (despite your snapd coming from the candidate channel i guess, AFAIK 2.67 isnt out yet)…
So i guess there is something going on with the AD accounts or your kernel is missing something (snap debug sandbox-features might have been more interesting regarding kernel support here)
$ snap debug sandbox-features
apparmor: kernel:caps kernel:dbus kernel:domain kernel:domain:attach_conditions kernel:file kernel:io_uring kernel:ipc kernel:mount kernel:namespaces kernel:network kernel:network_v8 kernel:policy kernel:policy:notify kernel:policy:notify:user:file kernel:policy:permstable32:allow kernel:policy:permstable32:audit kernel:policy:permstable32:complain kernel:policy:permstable32:cond kernel:policy:permstable32:deny kernel:policy:permstable32:hide kernel:policy:permstable32:kill kernel:policy:permstable32:label kernel:policy:permstable32:prompt kernel:policy:permstable32:quiet kernel:policy:permstable32:subtree kernel:policy:permstable32:tag kernel:policy:permstable32:xindex kernel:policy:unconfined_restrictions kernel:policy:versions kernel:ptrace kernel:query kernel:query:label kernel:rlimit kernel:signal parser:allow-all parser:cap-audit-read parser:cap-bpf parser:include-if-exists parser:io-uring parser:mqueue parser:prompt parser:qipcrtr-socket parser:snapd-internal parser:unconfined parser:unsafe parser:userns parser:xdp policy:default support-level:full
confinement-options: classic devmode strict
dbus: mediated-bus-access
kmod: mediated-modprobe
mount: layouts mount-namespace per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles stale-base-invalidation
seccomp: bpf-actlog bpf-argument-filtering kernel:allow kernel:errno kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap kernel:user_notif
udev: device-cgroup-v2 device-filtering tagging
Well, that looks okayish too … so it likely boils down to the AD accounts, not sure how they could influence the namespace mounting though, you should open a new post in the snapd category specifically for this issue (IIRC there is more than /etc/ssl that gets mounted from the host so you might have other unnoticed issues too if that whole feature doesn’t work)
Worth noting that this isn’t Ubuntu. It’s a modified build from Tuxedo.