Allow a grace period/remember last server when trusting a certificate #755

New Issue

2026-10-05T04:42:51+02:00

adam commented

2026-10-05 04:42:51 +02:00

Scenario: I have my server set to irc.whatever.network that has N servers in it's round robin. I also have this setup to connect via SSL. One issue though, the certificate is not trusted. No big deal, I'll follow the prompt that ZNC gives me which says I can trust this certificate by doing /znc AddTrustedServerFingerprint <fingerprint>. All good, now I can just wait for ZNC to reconnect to... Wait, the round robin took me to a new server. Hmm OK, I'll just approve this one too... Hmm maybe not. It keeps sending me to a new server every time, hopefully I'll land on a server I've already trusted?

From a network administrator point of view, it's not good practice to encourage users to connect to a single server as that server is not always guaranteed to always be alive, unlike the RR. And while some networks provide the certificate, it becomes a hassle for the end user to have to manually go to the network's home page, get the fingerprints, add them all in to ZNC, then proceed to connect as the fingerprints may/will change in the future. In this case, however, it feels like a game of chance whether or not we end up on a server we've already trusted.

Possible resolutions:

Allow a grace period before accepting the handshake for the user to add the trusted certificate. This probably won't work as it may not be enough time for manual input, then finishing the handshake, then finishing registering with the IRCd.
Cache the last IP that the IRCd gave us. Set a timeout for the user to run /znc AddTrustedServerFingerprint then allow /znc reconnect. If we fail to meet the timeout, continue on to the next server. Probably the most likely candidate.

Maybe there is already a solution to the problem, though I haven't come across one.

Thanks!

Scenario: I have my server set to `irc.whatever.network` that has `N` servers in it's round robin. I also have this setup to connect via SSL. One issue though, the certificate is not trusted. No big deal, I'll follow the prompt that ZNC gives me which says I can trust this certificate by doing `/znc AddTrustedServerFingerprint <fingerprint>`. All good, now I can just wait for ZNC to reconnect to... Wait, the round robin took me to a new server. Hmm OK, I'll just approve this one too... Hmm maybe not. It keeps sending me to a new server every time, hopefully I'll land on a server I've already trusted? From a network administrator point of view, it's not good practice to encourage users to connect to a single server as that server is not always guaranteed to always be alive, unlike the RR. And while some networks provide the certificate, it becomes a hassle for the end user to have to manually go to the network's home page, get the fingerprints, add them all in to ZNC, then proceed to connect as the fingerprints may/will change in the future. In this case, however, it feels like a game of chance whether or not we end up on a server we've already trusted. Possible resolutions: 1) Allow a grace period before accepting the handshake for the user to add the trusted certificate. This probably won't work as it may not be enough time for manual input, then finishing the handshake, then finishing registering with the IRCd. 2) Cache the last IP that the IRCd gave us. Set a timeout for the user to run `/znc AddTrustedServerFingerprint` then allow `/znc reconnect`. If we fail to meet the timeout, continue on to the next server. Probably the most likely candidate. Maybe there is already a solution to the problem, though I haven't come across one. Thanks!

adam commented

2026-10-05 04:42:52 +02:00

Allow a grace period before accepting the handshake for the user to add the trusted certificate. This probably won't work as it may not be enough time for manual input, then finishing the handshake, then finishing registering with the IRCd.

https://github.com/znc/znc/issues/67 would possibly be equivalent?

https://github.com/znc/znc/issues/909 hoping the network has a CA if they don't have valid certificates for all servers.

> 1. Allow a grace period before accepting the handshake for the user to add the trusted certificate. This probably won't work as it may not be enough time for manual input, then finishing the handshake, then finishing registering with the IRCd. https://github.com/znc/znc/issues/67 would possibly be equivalent? 3. https://github.com/znc/znc/issues/909 hoping the network has a CA if they don't have valid certificates for all servers.

adam commented

2026-10-05 04:42:53 +02:00

67 doesn't really solve the problem. It just delays the time between reconnects. It wouldn't remember the last server, which is the real problem.

The CA idea would work, but that assumes the network is using sane SSL certificates.

67 doesn't really solve the problem. It just delays the time between reconnects. It wouldn't remember the last server, which is the real problem. The CA idea would work, but that assumes the network is using sane SSL certificates.

adam referenced this issue

2026-10-05 04:58:41 +02:00

`clientnotify.cpp`: shouldnt notify for same ip & identifier but different network #1016

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#755