Wrong Assumptions with Irssi

— 506 words — 3 min

Today I connected back to my irc bouncer znc with the terminal irc client irssi. I had the configuration with my self-signed certificate and certificate pinning already figured out in the past, but that configuration file was on a different computer. And I’m currently travelling, so I didn’t have access to it and, more importantly, I did not save the configuration to my dotfiles or anywhere else where I could easily look it up. However, I remember that I had some issues getting it to work, but in the end I got there.

So I had to do it from scratch, but I thought it would be easy because I’ve already done it. So how hard could it be?

Well, turns out, it took me about an hour again because I had a wrong assumption about one configuration option in irssi.

A configuration block in irssi for a network called libera-znc may look like the following:

{
    address = "mybouncer.server.net";
    chatnet = "libera-znc";
    port = "1234";
    passowrd = "znc-user/znc-network-name:znc-user-password";
    use_tls = "yes";
    tls_verify = "no";
    tls_pinned_cert = "12:34:56:78:90:59:0F:28:0F:48:56:FF:51:F9:D4:8C:0B:94:BC:BF:2F:D1:0C:25:D4:E9:AA:BB:CC:DD:EE:FF";
    autoconnect = "yes";
}

Most options should be self-explanatory. So, what was my wrong assumption?

My znc server uses a self-signed certificate, so I can’t use the option tls_verify, because the certificate is self-signed and therefore cannot be verified by any CA out there, e.g. Let’s Encrypt. Hence, I removed the option tls_verify from the configuration thinking that this would equal to tls_verify = "no".

However, I want to make sure that I always connect to my server (and to prevent MITM attacks), so I generated the sha256 fingerprint of the certificate the znc service is using with OpenSSL:

openssl x509 -fingerprint -sha256 -noout -in znc.pem

After verifying a thousand times that my generated certificate fingerprint is actually correct, I took a step back and thought about it again. I tried to remember what the problem was and I did remember that it was something stupid and simple. After staring at the configuration for a while, I noticed in another network configuration the tls_verify = "yes"; option again. That’s when it hit me. I put tls_verify = "no"; back into my network configuration block and it just worked.

So, to remember this and to write it down somewhere, I created this short blog post.

I also looked through the irssi documentation and could not find the documented default value of the option tls_verify. However, when looking through the changelog, I found the following bullet point:

-tls_verify is now enabled by default (#1170, an#18, #1309, an#23, #1343, #1351) This may cause an ugly display of notls_verify in the output of /SERVER LIST, even on plain-text connection, on old configs. Kindly remove the “tls_verify = “no”;” entries from your config file manually.

Articles from blogs I follow around the net

tweet

Prepare your “no” and keep it handy: https://sive.rs/n0

via Derek Sivers May 14, 2026

Resetting Mutt's terminal after OAuth2 / GPG

A quick fix for how to get mutt's terminal reset after shelling out to GPG during the OAuth2 flow.

via Signs of Triviality March 31, 2026

Status update, February 2026

Hi all! Lars has contributed an implementation independent test suite for the scfg configuration file format. This is quite nice for implementors, they get a base test suite for free. I’ve added support for it for libscfg, the C implementation. I’ve spent some…

via emersion February 22, 2026

Generated by openring