How to fix the issue with CA certificates in Guix

This article was originally published in Japanese on Taiju's blog. I translated this post in part to force me to pay attention to Japanese vocabulary and grammar. It might contain some incorrect statements and some inaccuracies since I'm not that good at Japanese. Of course, all the mistakes are mine.
As with other articles on Taiju's blog, this post is released under CC-BY-SA 4.0.

Not limiting ourselves to Guix, are there people who never experienced this failure once: when using the git command or the curl command with the HTTPS protocol, you get an error related to the verification of certificates?

In most distributions, you can maybe install a package called ca-certificates, or run some sort of command offered by the distribution, that would renew the CA certificates, in order to solve the issue.

Going back to Guix, its particularities combine together with this error to make it more likely to form an intricate issue.

There is no ca-certificates package

In Guix, the package that corresponds to the one offered under the name ca-certificates in other distributions is provided under the name nss-certs.

Even searching for guix search ca-certificates doesn't return any result, which I think is one of the pitfalls.

If you are using the Guix System, nss-certs is included in the initial configuration template as well as in the documentation, so as long as you do not purposefully delete it, this issue should not happen. However, if you use Guix as a package manager on another distribution, you have to install it yourself.

There is no /etc/ssl/certs directory

Just like NixOS, Guix does not follow the FHS.

Even if you install nss-certs, the /etc/ssl/certs directory is not created, and the CA certificates are not installed in it.

Therefore, when software you use need the CA certificates, you have to teach them about where these are located in Guix.

For software with excellent portability, it is often possible to direct them with an environment variable, so in this case, it is enough to set a few.

Reference: https://guix.gnu.org/manual/devel/en/html_node/X_002e509-Certificates.html

Also, when software packaged in Guix does not originally support that, there is always the possibility to patch them to understand the environment variable. And, since packages (such as curl or git) automatically set environment variables, this problem is very unlikely to occur with Guix provided packages.

When you're unable to apply a patch to the software, there is always the heavyhanded possibility of creating a symbolic link from /etc/ssl/certs to the path where CA certificates are installed with nss-certs (such as $GUIX_PROFILE/etc/ssl/certs).

However, this method is a double-edged sword. In the situation where the problem were to occur, it does not occur anymore. However, it's no longer possible to guarantee the reproducibility of the system, with regards to this problem. This is not something I could recommend, even though I've been using this solution at my own risks.

The certificate error appears with Flatpak-installed software

Although most software do not have this issue, Guix sets the SSL_CERT_DIR and SSL_CERT_FILE environment variables. Software installed with Flatpak will respect this path (for instance through the OpenSSL library) and the certificate error occurs.

Concretely, Zoom installed with Flatpak experienced this problem. Although Zoom started, the issue was that it did not proceed beyond that. So for using Zoom, it was a fatal error.

To explain it approximately, starting a software with Flatpak is similar to starting it with the docker run command. Flatpak software are self-sufficient software and contain their own dependencies, such as libraries. They run in an isolated sandbox environment isolated from the host environment.

Consequently, software installed with Flatpak cannot access the host environment except for explicitely authorized resources. This is a desirable security feature, and since it is not possible to depend on a library or other content from the host environment, this is also a great way to ensure reproducibility.

The certificate error that occurs with Zoom come from the fact that the path pointed to by SSL_CERT_DIR and SSL_CERT_FILE are not accessible to Zoom. Being unable to load the CA certificates, the certificate verification fails.

In Flatpak, similarly to Docker's Volume, it is possible to individually set access rights to special paths of the host environment. By running the below command, you give Zoom a read-only access to the CA certificates from the host environment.

flatpak override --user --filesystem=$GUIX_PROFILE:ro --filesystem=/gnu/store:ro us.zoom.Zoom

There might still be more issues I am not yet aware of, but in general, with any of the solutions above, all problems related to CA certificates with Guix should be solved.

Next time, if I find a new type of issue and I can develop a workaround, I'll add the information here.

That's all!

ボーナス

Here is a small list of technical terms and expressions that I found in the blog post. Maybe you'll find it useful :)