Certificate substitution and snaps

[MichaelI]

Trying to use snaps on Ubuntu Xenial in an environment where HTTPS traffic is going through an outbound proxy that does certificate substitution. The ca-certificates file on Ubntu is updated, and apt install is working.

However, the snap command still gives this error:

sudo snap install hello-world
error: cannot install “hello-world”: Get
https://search.apps.ubuntu.com/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cprivate%2Cconfinement%2Cchannel_maps_list:
x509: certificate signed by unknown authority

How can I use snaps in such an environment?

[ogra]

snapd re-execs itself into the core snap as execution environment … the core snap is a readonly squashfs, while it has the default ca-certificates pre-installed, there is no actual way of dynamically adding additional certificates to it …

this kind of touches

Extending system certificates

It would be desirable to allow adding system-wide certificates to an Ubuntu Core system, one example is the way some organisations use Docker with self-signed certs. To enable this we would need to make /etc/ssl/certs/ca-certificates.crt writeable or make it a symlink to something writable (e.g. /etc/writeable). We also need a directory where new certs can be added (probably /var/lib/snapd/certs). Certs could be added on snap installation and removed on snap removal, either by themselves (some k…

[MichaelI]

Thank you for the explanation.

This is a severe limitation that impairs the use of software that is distributed only as snaps.
conjure-up would be a prominent open source example:
https://github.com/conjure-up/conjure-up/issues/977

Is there a workaround (even if it requires snap post-deployment manual configuration)?

Is it prioritized to alleviate this restriction upstream?

Thanks again!

[ogra]

i’d actually ask on the other thread, not sure where this is going …

[KurtB]

I work in a facility that does deep packet inspection of all https traffic. This network security tool set is becoming more and more prevalent in corporate and government institutions. All traffic is decoded/inspected/recoded at the perimeter. On our workstations, we add the signing cert into our ca-certificates chain.

Since snaps bypasses the local CA chain, I’d like to know if we can add our local signing cert into the snaps ca chain. (I’ll ask this in the other thread, too.)

Thanks,
Kurt

[GBrayUT]

Like many other users I work in a corporate environment where we have our own CA root and PKI for internal applications. I attempted to use snap to install kurly (a curl substitute) but quickly found it didn’t work on any of our internal applications due to “x509: certificate signed by unknown authority”. I understand the goal of snap is to isolate applications, but I have no interest in re configuring every app I install to use a different set of trusted root CAs.

I was able to temporarily mount the existing root CA store on my Ubuntu system into the core package using:

sudo mount --bind --bind -o nodev,ro /etc/ssl/certs /snap/core/current/etc/ssl/certs/

This allows the kurly snap (and any others I install) to work until I restart the system.

As a stop gap until snap finds a way to manage root CA for all applications you can create a systemd mount file to run on startup:

$ cat <<-EOF | sudo tee /etc/systemd/system/snap-core-current-etc-ssl-certs.mount
[Unit]
Description=Mount unit to fix etc ssl certs in core package
After=snapd.service

[Mount]
What=/etc/ssl/certs
Where=/snap/core/current/etc/ssl/certs
Type=none
Options=bind,nodev,ro

[Install]
WantedBy=multi-user.target
EOF
$ systemctl enable snap-core-current-etc-ssl-certs.mount

[jdmarble]

A related bug x509: certificate signed by unknown authority was closed as “won’t fix” with the comment: “Don’t try to man-in-the-middle snapd.” I’d say that it is not prioritized to alleviate this restriction upstream.

[ivoks]

I would just like to echo comments made by others. Proper certificate management within snaps is a must. Applications deployed as snaps must be able to trust user/admin/system provided CAs. Many enterprises have their own CAs; use case - OpenStack behind TLS (which is a typical environment these days), signed with company-wide CA. One can’t use k8s on that OpenStack because there is no way to push trusted CA into k8’s snaps.