Working around C.IM's certificate issue in Arch Linux (May 2025)

Note: the usefulness of this article may decrease with time as the issue gets fixed. Please keep in mind the post date as you read.

After my recent moving between instances, I made C.IM my new fediverse home. However, as soon as the move was complete, I found out that a key piece of my software stack had stopped working for me - the tut CLI client.

The error was clear: when trying to log in, tut would state that the certificate issued by C.IM was not recognized, and thus would refuse connection. No chance to retry, no verbose debugging mode, nothing.

This was a big issue for me. I don't like to spend too much time in the Fediverse, and the simplicity of a command-line client helps a lot with it. Furthermore, the web client, despite very featureful, just keeps eating RAM in the background over time. I need to have an alternative.

Despite it being an amazing, super complete and powerful, and my favorite client, I was quickly to blame tut first for the issue. After all, it's a client that has not received any updates since 2023. Perhaps something in the cert-trusting mechanism was not updated accordingly? An update seemed a dead end at this time, so I thought I'd have to use a different client?

But before I delved too deep in this search, something happened. I tried it in another machine running Fedora 42, and tut's login worked this time. This was pleasant, but left me baffled - how could tut work in one "cutting edge" distro, but not on another? But I did the same test again in plain ol' Debian 12 and tut again logged in without complaint. tut is fine, or it seems. The issue seemed to be narrowed down to Arch alone.

The issue can be reproduced in other ways

Now, the mainstream browsers all have their own way to handle the TLS stack that seems independent from what the OS offers, which explains why the web interface of C.IM worked fine with Firefox. But how about the many other system utilities from Linux that depended on the system-provided certificates to work? Turns out that, much like tut, they also failed to recognize C.IM's certificate!

$ curl https://c.im
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.

And by the way, depending on how early you're reading this article, if you're running a fully up to date Arch install, you can try it out yourself. Just run curl, wget or any other application capable of fetching data over TLS with https://c.im (HTTPS required) and see that the certificate can't be verified. This was true even for Dillo, which does a lot of re-use of the OS's components including wget for downloads.

This gave me certainty that the problem was dead center in the way Arch handles TLS. Something was broken among the the stack was being resolved, so I took it to the IRC channel to try my luck.

Bug hunting

Surely enough, other members of #archlinux got into the same issue - their machines couldn't handshake the website. Some of them started analyzing the issue, trying to look into what could've changed since previous releases, and they eventually narrowed down the issue to one of the packages handling TLS: ca-certificates-mozilla.

From what I understood from the discussion, it seems that the latest version (3.111-1) dropped the trust on the SSL.COM signing authority used by Cloudflare, rendering those websites untrusted by the OS's stack. This is not used by either major browser, however, so for most browsing this error has passed in a silent way. The other problem is that, since this package is essentially a repack from a certificate bundle issued by Mozilla, fixing it does not seem to be strictly the Arch Linux team's responsibility. In the words of an IRC member: "This is between Mozilla and Cloudflare to resolve."

Thus, I'm not sure how the fix can be issued. For now, I've filed a bug with the maintainers of the nss package to inform them of the issue, but it might just be ignored in the long run for an update from elsewhere.

Workaround, for now

So, how can I work around this, and keep tooting from the command-line again? What worked for me was downgrading the package to a previously working version, in my case, 3.110-1.

Luckily, I had the package still cached under /var/cache/pacman/pkg/, so I could install it locally with pacman -U ca-certificates-mozilla-3.110-1-x86_64.pkg.tar.zst. If you don't have this version available, don't worry: I also uploaded a copy of it here.

This will downgrade the package and you can attest that it will make the TLS work again. However, as soon as you update pacman again, the downgrade will be overwritten. So how do you "hold back" that package? Simple: edit /etc/pacman.conf and add the following line:

IgnorePkg   = ca-certificates-mozilla

Now pacman will not attempt to update the package with a systemwide update. If a newer version does come up, you could try to remove the ignore and see if it works again.

Conclusion

It's sad that we have to hold back the versions to fix this, but it works well enough for now (I haven't seen any other issues arising from it so far). I hope that this gets sorted out quickly and I can go back at using C.IM normally, like any other Fediverse instance!

This post is number #60 of my #100DaysToOffload project.

Last updated on 05/23/25