Problems with torifying weechat (liberachat)

Hi all, :wave:

while still running Lubuntu I managed to torify weechat. It took a while but with some help I got it going.
Now that I´ve set up my new system Linux Lite 6.2 I want to do just the same but for some reason the steps I followed back then don´t seem to provide the desired effect any more. :slightly_frowning_face:

First of all the references:

The preliminary steps I took:

  • install tor
  • make sure tor service is running:
systemctl status tor@default
	● tor@default.service - Anonymizing overlay network for TCP
     	Loaded: loaded (/lib/systemd/system/tor@default.service; enabled-runtime; >
    	 Active: active (running) since Mon 2023-05-29 13:48:19 CEST; 18min ago


env SHELL=/usr/bin/bash firejail --private=/media/rosika/f14a27c2-0b49-4607-94ea-2e56bbf76fe1/DATEN-PARTITION/Dokumente/work2 torsocks w3m

Congratulations. This browser is configured to use Tor.
Your IP address appears to be: […]

  • in weechat:
/server add libera -autoconnect -ssl
/connect libera
  • mkdir ~/.weechat/certs

  • openssl req -x509 -new -newkey rsa:4096 -sha256 -days 1096 -nodes -out libera.pem -keyout libera.pem

  • mv libera.pem ~/.weechat/certs

  • in weechat:

    /set irc.server.libera.addresses
 	/set irc.server.libera.ssl on
 	/set irc.server.libera.ssl_verify on
 	/set irc.server.libera.ssl_cert %h/certs/libera.pem
 	/set irc.server.libera.sasl_mechanism external
 	/reconnect libera

At this point I ran into difficulties. Reconnecting to libera fails:

weechat says:

 │14:19:41  libera  -- | irc: verbinde zum Server (SSL)...  # connecting to server
         │14:19:41  libera =!= | gnutls: Kann das Zertifikat "/home/rosika/.config/weechat/certs/libera.pem" nicht lesen # cannot read certificate
         │14:19:41  libera  -- | gnutls: empfange 2 Zertifikate # receive 2 certs
         │14:19:41  libera  -- |  - Zertifikat[1]-Information:
         │14:19:41  libera  -- |    - subject `', issuer [...] 
                               | RSA key 4096 bits, signed using RSA-SHA256, activated `2023-05-19 23:48:55 UTC', expires `2023-08-17 23:48:54 UTC',
         │                     | pin-sha256= [...] 
         │14:19:41  libera  -- |  - Zertifikat[2]-Information:
         │14:19:41  libera  -- |    - subject [...]  activated `2020-09-04 00:00:00 UTC',
         │                     | expires `2025-09-15 16:00:00 UTC', pin-sha256= [...]
                               | gnutls: Peer-Zertifikat ist vertrauenswürdig # cert is trustworthy
         │14:19:41  libera  -- | irc: Verbindung zu (2001:1bc0:c1::1000) hergestellt # connection established
         │14:19:41  libera  -- | *** Checking Ident
         │14:19:41  libera  -- | *** Looking up your hostname...
         │14:19:41  libera  -- | *** Couldn't look up your hostname
         │14:19:41  libera  -- | *** No Ident response
         │14:19:41  libera  -- | irc: Clientfähigkeiten, Server unterstützt: account-notify away-notify chghost extended-join multi-prefix
         │                     | sasl=PLAIN,ECDSA-NIST256P-CHALLENGE,EXTERNAL tls account-tag cap-notify echo-message server-time
         │                     |
         │14:19:41  libera  -- | irc: Clientfähigkeit, Anfrage: account-notify away-notify chghost extended-join multi-prefix sasl cap-notify server-time
         │14:19:41  libera  -- | irc: Clientfähigkeit, aktiviert: account-notify away-notify chghost extended-join multi-prefix sasl cap-notify server-time
         │14:19:42  libera  -- | SASL authentication failed
         │14:19:42  libera  -- | irc: vom Server getrennt # disconnected from server
         │14:19:42  libera  -- | irc: Verbinde erneut zum Server in 10 Sekunden # new try

So basically it´s this:

gnutls: Kann das Zertifikat "/home/rosika/.config/weechat/certs/libera.pem" nicht lesen

I.e.: cannot read. the certificate. No idea why not… :thinking:
I even saw to it that reading is allowed:

chmod +r libera.pem
.rw-r--r-- 5,3k rosika rosika 28 Mai 15:57 libera.pem

I also added the following line to /etc/tor/torrc:

MapAddress libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion

in weechat:

/set irc.server.libera.addresses libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion/6697

That was the crucial part back then with Lubuntu.

Still it didn´t work:

weechat says:

 │14:28:51  libera  -- | irc: verbinde zum Server libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion/6697 (SSL)... # connecting to server
         │14:28:51  libera =!= | irc: Adresse "libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion" nicht gefunden # address not found
         │14:28:51  libera =!= | irc: Fehler: Name or service not known
         │14:28:51  libera  -- | irc: Verbinde erneut zum Server in 10 Sekunden # new try

Hmm, I´m at a loss what to do now. :thinking:

Does anyone have a clue :question:

Thanks a lot in advance and many greetings
Rosika :slightly_smiling_face:

1 Like

Hi Rosika,
Do you have tls installed?
Only a guess. Only 3 reasons something cant be read

  • the reader is defective
  • the file is defective
  • permissions
    You dealt with permissions

Hi Neville, :wave:

thanks for your reply.

Hmm, not quite sure what you mean by that… :thinking:

Well, actually weechat is a lightweight irc-client for the command line.

It works well using the standard configuration. So it can´t be the culprit.
Running it via the tor network, however, which needs some configuration, seems to fail.

Thanks a lot anyway, Neville.

Cheers from Rosika :slightly_smiling_face:

There are libraries needed to drive gnutls.
Try an apt-cache search tls and see what comes up
Then dpkg -l | grep tls and see what you have.

Thanks Neville,

dpkg -l | grep tls
ii  libcurl3-gnutls:amd64                             7.81.0-1ubuntu1.10                         amd64        easy-to-use client-side URL transfer library (GnuTLS flavour)
ii  libgnutls30:amd64                                 3.7.3-4ubuntu1.2                           amd64        GNU TLS library - main runtime library
ii  libgnutls30:i386                                  3.7.3-4ubuntu1.2                           i386         GNU TLS library - main runtime library
ii  libmbedtls14:amd64                                2.28.0-1build1                             amd64        lightweight crypto and SSL/TLS library - tls library
ii  libneon27-gnutls:amd64                            0.32.2-1                                   amd64        HTTP and WebDAV client library (GnuTLS enabled)
ii  libsrt1.4-gnutls:amd64                            1.4.4-4                                    amd64        Secure Reliable Transport UDP streaming library (GnuTLS flavour)

Hmm, I can´t really believe that Linux Lite wouldn´t have the right packages installed by default and Lubuntu would… :thinking: .

Agree, unless you changed something in Lite.
I wonder why the i386 package is there? There must be something that is still 32 bit.
Do you have multiarch?

No answers , just questions that might lead to answers.

Hi Neville, :wave:

no, I don´t think so. Actually I´m not aware of having done anything like that.

Hmm, your guess is as good as mine. :wink:

No, it´s a normal Linux Lite installation, i.e. 64 bit.

I´m beginning to wonder whether the problem has anything to do with the fact that I´m running weechat within the firejail sandbox.

As a matter of fact I can´t believe that´s the reason because the exact same scenario worked well on Lubuntu.
Still: I might try torifying weechat outside the sandbox for a change…

I also consulted ChatGPT to see what it might come up with. But I couldn´t learn anything new. So the steps I took should have led to a working torified weechat instance… :thinking:

On thing though:

As a last resort ChatGPT suggested using the implemetation of stunnel.

Instead of relying on WeeChat’s built-in SSL/TLS support, we can utilize a separate tool called stunnel to establish an SSL/TLS tunnel between WeeChat and the Tor network. Here’s how you can set it up:

Install stunnel:

sudo apt-get install stunnel

Configure stunnel: Open the stunnel configuration file using the following command:

sudo nano /etc/stunnel/stunnel.conf

Add the following lines at the end of the file to set up the SSL/TLS tunnel for WeeChat:

> client = yes
> accept =
> connect =

Save the changes and exit the editor (Ctrl+O, Enter, Ctrl+X).

Start the stunnel service:

sudo service stunnel4 start

Launch WeeChat: Open a terminal and run the following command to start WeeChat:


Add a new server: Once you’re in the WeeChat interface, use the following command to add a new server entry for Libera Chat:

/server add libera localhost/9000

Connect to Libera Chat: Use the following command to connect to the Libera Chat network:

/connect libera

By using stunnel as an intermediate SSL/TLS tunnel, we can bypass the certificate and hostname mismatch issues within WeeChat.
The tunnel established by stunnel will handle the encryption and decryption between WeeChat and the Libera Chat server via the Tor network.

Hmm… :thinking:

I have to admit I´ve never heard of stunnel before and I have to investigate a bit before I try those steps.
I don´t like blindly copying and pasting commands if I don´t understand them (or at least: not all of them) :neutral_face: .

Thanks a lot, Neville. :heart:

Many greetings from Rosika :slightly_smiling_face:

Your firejail, may have some slightly different settings to Lubuntu, and it is probably a newer version. But it is only wanting to read a file? Is reading a certificate some sort of security issue?

If you are 64 bit and no multiarch, why do you have an i386 package installed ?
I want to check what my Debian has. Will look tomorrow. I still have Debian in my small machine, plus I have a new Debian in qemu.


1 Like

That may very well be true, Neville.

I cannot imagine that. But I´m no expert in these matters. :blush:

Thanks a lot, Neville.
I could look it up in my Debian VM as well. Yet I´m unsure what to look for exactly and how to look it up.

I´ll try running weechat outside the sandbox first.

Thanks and cheers from Rosika :slightly_smiling_face:

Hi Rosika,
My Debian does not have any i386 tls routines

nevj@mary:~$ dpkg -l | grep tls
ii  libcurl3-gnutls:amd64                         7.74.0-1.3+deb11u7                     amd64        easy-to-use client-side URL transfer library (GnuTLS flavour)
ii  libcurl4-gnutls-dev:amd64                     7.74.0-1.3+deb11u7                     amd64        development files and documentation for libcurl (GnuTLS flavour)
ii  libgnutls30:amd64                             3.7.1-5+deb11u3                        amd64        GNU TLS library - main runtime library
ii  libmbedtls12:amd64                            2.16.9-0.1                             amd64        lightweight crypto and SSL/TLS library - tls library
ii  libneon27-gnutls:amd64                        0.31.2-1                               amd64        HTTP and WebDAV client library (GnuTLS enabled)
ii  libsrt1.4-gnutls:amd64                        1.4.2-1.3                              amd64        Secure Reliable Transport UDP streaming library (GnuTLS flavour)

It seems you have installed some package that is 32bit, and it has dragged in


So you have 2 versions of libgnutls30. How does a program know which one to use?
I dont know. Maybe update-alternatives controls it? Maybe one is in /usr/lib, and the other is in /usr/lib32 so the path may control it? Mine is in /usr/lib/x86_64-linux-gnu.

You could try removing libgnutls30:i386. It is easily put back
apt-get install libgnutls30:i386
will install the i386 version.
If you remove it, something else may break. Then you will know what dragged it in.

gnutls does this

GnuTLS features support for:
  - certificate path validation, as well as DANE and trust on first use.
  - the Online Certificate Status Protocol (OCSP).
  - public key methods, including RSA and Elliptic curves, as well as password
    and key authentication methods such as SRP and PSK protocols.
  - all the strong encryption algorithms, including AES and Camellia.
  - CPU-assisted cryptography with VIA padlock and AES-NI instruction sets.
  - HSMs and cryptographic tokens, via PKCS #11.

So that is the thing involved in reading the certificate file.


Gentoo seems to have several versions


and what do you get for this

nevj@mary  $ arch

You may need to install arch-test… it tells you what architectures are supported by your machine and kernel

nevj@mary:~$ arch-test
nevj@mary:~$ dpkg --print-architecture

It may be that you need multiarch support
apt-get install multiarch-support
to to help it manage 2 versions of libgnutls30 ?

1 Like

Hi Neville, :wave:

thanks so much, Neville for your detailed answer. :heart:

In the meantime I looked up the relevant tls packages on my Debian VM as well.
I also came up with the same results :

rosika2@debian ~> dpkg -l | grep tls
ii  libcurl3-gnutls:amd64                 7.64.0-4+deb10u6                        amd64        easy-to-use client-side URL transfer library (GnuTLS flavour)
ii  libgnutls-dane0:amd64                 3.6.7-4+deb10u10                        amd64        GNU TLS library - DANE security support
ii  libgnutls30:amd64                     3.6.7-4+deb10u10                        amd64        GNU TLS library - main runtime library
ii  libmbedtls12:amd64                    2.16.9-0~deb10u1                        amd64        lightweight crypto and SSL/TLS library - tls library
ii  libneon27-gnutls:amd64                0.30.2-3                                amd64        HTTP and WebDAV client library (GnuTLS enabled)

… all amd64.

That got me wondering:
On Linux Lite I looked up the installation date of the i386 tls routines:

 bash -c 'zgrep installed /var/log/dpkg.log.[2-9].gz | grep libgnutls30:i386'
/var/log/dpkg.log.2.gz:2023-03-06 13:25:03 status half-installed libgnutls30:i386 3.7.3-4ubuntu1.1
/var/log/dpkg.log.2.gz:2023-03-06 13:26:49 status installed libgnutls30:i386 3.7.3-4ubuntu1.2
/var/log/dpkg.log.3.gz:2023-02-24 16:08:19 status half-installed libgnutls30:i386 3.7.3-4ubuntu1.1
/var/log/dpkg.log.3.gz:2023-02-24 16:09:56 status installed libgnutls30:i386 3.7.3-4ubuntu1.1

So the latest installation of it was on 2023-03-06.

Now I looked what other packages were installed that day at the same time with

bash -c 'zgrep installed /var/log/dpkg.log.[2-9].gz | grep "2023-03-06 13:25"'

The output, however, was too extensive to deduce what might have pulled it in.
Amongst others there were imagemagick, curl, ubuntu-advantage-tools, clamav-base, evince and many more. :neutral_face:

That´s great. Thanks for supporting this info.
I wonder how you got that info?

On LL I get


… which was to be expected.


dpkg --print-architecture

O.K. That may very well be something to look into.
Thanks a lot, Neville.

Many greetings from Rosika :slightly_smiling_face:



In the meantime I could get rid of the following error:

│14:19:41  libera =!= | gnutls: Kann das Zertifikat "/home/rosika/.config/weechat/certs/libera.pem" nicht lesen # cannot read certificate

It turned out that libera.pem wasn´t put in the correct place. It resided in the home directory rather than in .config/weechat/certs. I put it right and now the certificate can be read. :slightly_smiling_face:

Still there´s the following error which seems to prevent connection:

│15:38:55 libera =!= | gnutls: der Hostname im Zertifikat "libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion" stimmt NICHT überein

I.e.: Hostname does not match

Right now this seems to be the crucial point. :thinking:

It comes with apt-cache show libgnutls30
From your results of dpkg --print-architecture
your package system only supports amd64 packages

Just to be sure, can you do
dpkg --print-foreign-architectures

If that does not list i386 you need to add it
dpkg --add -architecture i386

and dont forget
apt-get install multiarch-support
and maybe an update and upgrade to finish off.

Then you should be able to have 32 bit packages, properly installed in a place where running apps can find their libraries.

No guarantee this is your problem, but it looks suspiciously like it. You need to tidy up your 32 bit situation anyway.

I see you fixed the certificate issue, but still have issues. Sounds like it found the file now, but could not parse the contents?

I have to do the above to get my 32 bit printer drivers to work. Trying right now to get it to work in MX. In Debian it is OK.

Good luck

1 Like

Thanks a lot, Neville. :heart:

Ah, great. That one hasn´t occurred to me, I have to admit. :blush:

dpkg --print-foreign-architectures

Seems to be alright so far, I guess.

Hmm, I wonder.

gnutls seems to work is it should.
E.g. I get the messages:

│16:32:17 libera -- | gnutls: sende ein Zertifikat # send a certificate


gnutls: Peer-Zertifikat ist vertrauenswürdig # peer certificate is trustworthy

… no error there…

Well, in the meantime I found out there´s a weechat presence on GitHub.
I took the liberty of posting the query there as well.

I´m curious whether we´ll get a reply from there and if there´s a pratical solution available.

(problems torifying weechat · Issue #1948 · weechat/weechat · GitHub .)

In the meantime: thanks again for so much help, Neville. :heart:

Many greetings from Rosika :slightly_smiling_face:

Yes, your 32bit packages are installed OK.
That is not the problem. It should be using the correct 64 bit version.
Sorry, that was a diversion.

Lets see what your weechat post achieves


Hi Neville, :wave:

I just received an answer by user weechatter:

try : /set irc.server.libera.ssl_verify off

(latest beta: /set irc.server.libera.tls_verify off)

Its better to /join #weechat (or #weechat-de) on libera and to give weechat version

Alas switching the libera server to ssl_verify off didn´t change anything. :slightly_frowning_face:
I still get the error message:

gnutls: der Hostname im Zertifikat “libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion” stimmt NICHT überein

(hostname in certificate […] doesn´t match

No idea how to get rid of that.

Joining #weechat on libera is just the thing I wanted avoid as long as I haven´t resolved the problem with torification. :wink:

Thanks a lot and many greetings
Rosika :slightly_smiling_face:

Hi Rosika,
They are talking about SSL, and you are encountering TLS.
You have one or the other, not both.
Does not add up.
You need to tell something which of TLS or SSL to use.


Hmm… :thinking:

the only thing I seem to encounter at the moment is this hostname mismatch.

Although it says the hostname doesn´t match it doesn´t tell me what does it not match, or what does it not agree with?

Cheers from Rosika :slightly_smiling_face:

Maybe it cant read the hostname , perhaps because it is using TLS and it was coded in SSL.
I dont know . I dont understand how TLS and SSL are used?
This may be another of my red herrings.
You cant always believe error messages

I see. That might be a possibility. Thanks for the additional info, Neville.
Well, I guess I´ll have to invetsigate the matter further.

Many greetings from Rosika :slightly_smiling_face: