View Issue Details

IDProjectCategoryView StatusLast Update
0005686unrealircdpublic2020-09-27 17:59
Reporterwestor Assigned Tosyzop  
Status closedResolutionunable to duplicate 
Product Version5.0.5 
Summary0005686: REHASH after moving ssl options results in SSL connect failures

I have under set { ssl { } } set the certificates either too under listen { } block , i read on docs that if i have already set under set { ssl { } } the certificates then does not need too to set them in listen { } block too, but when i remove them from the listen block then the client cannot connect on the ssl port because of ssl certificate verification fail.

NOTE: As syzop said due a short lookup, it seems that /REHASH doesn't work in that case (probably).

unrealircd.conf ::

listen {
        ip *;
        port 6697;
        options { tls; }
        tls-options {
                certificate "/etc/letsencrypt/live/DOMAIN/fullchain.pem";
                key "/etc/letsencrypt/live/DOMAIN/privkey.pem";
set {
    ssl {
        protocols "all";
        certificate "/etc/letsencrypt/live/DOMAIN/fullchain.pem";
        key "/etc/letsencrypt/live/DOMAIN/privkey.pem";
        trusted-ca-file "curl-ca-bundle.crt";
        sts-policy {
            port 6697;
            duration 180d;
TagsNo tags attached.
3rd party modules



2020-05-27 19:13

reporter   ~0021593

I can verify after testing that on /REHASH didn't worked but it did on /RESTART


2020-07-14 15:45

administrator   ~0021660

Last edited: 2020-07-14 15:47

View 3 revisions

Hm, I'm not sure. I've looked again the code and now I can see it properly frees the listen-specific SSL/TLS context, the options, etc. So it looks all correct.

Perhaps this was a different issue, related to REHASH -tls? The one that has been fixed a few weeks ago in git (after your bug report):

commit ca6630a2fb622ce59b8b59a20ea6f5fdb69c337b
Author: Bram Matthys <>
Date: Fri Jun 26 15:11:01 2020 +0200

    Fix "called a function you should not call" server linking error that
    happens if all of the following are true:
    1) You use link::outgoing::tls-options (or ssl-options)
    2) You do a REHASH -tls (or REHASH -ssl)
    3) You do NOT do a regular REHASH
    4) You try to link to the server in such a link block (outgoing!)
    In other words: the problem may happen if you try to link after
    a Let's Encrypt cert renewal, unless there has been a regular
    REHASH between that and the outgoing linking attempt.
    Reported by k4be and Le_Coyoto in

Or maybe it even was something else?

I am too lazy to setup a public test installation with let's encrypt etc though :D


2020-07-14 18:29

administrator   ~0021661

I ditched my lazyness and tried to reproduce with:
listen with tls-options::certificate and tls-options::key while also having set::tls::certificate and set::tls::key.
TLS connected fine with no warnings/errors.
I then removed all the tls-options and REHASHed
TLS still connected fine with no warnings/errors.

So I cannot reproduce (anymore). But then again, I am on latest git.

Issue History

Date Modified Username Field Change
2020-05-27 19:10 westor New Issue
2020-05-27 19:13 westor Note Added: 0021593
2020-05-28 00:47 syzop Priority high => normal
2020-06-26 07:26 syzop Summary set { ssl { } } doesn't working if no tls-options exists under listen block => REHASH after moving ssl options results in SSL connect failures
2020-07-14 15:45 syzop Note Added: 0021660
2020-07-14 15:46 syzop Note Edited: 0021660 View Revisions
2020-07-14 15:47 syzop Note Edited: 0021660 View Revisions
2020-07-14 18:29 syzop Note Added: 0021661
2020-07-14 19:34 syzop Assigned To => syzop
2020-07-14 19:34 syzop Status new => feedback
2020-09-27 17:59 syzop Status feedback => closed
2020-09-27 17:59 syzop Resolution open => unable to duplicate