View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005686 | unreal | ircd | public | 2020-05-27 19:10 | 2020-09-27 17:59 |
Reporter | westor | Assigned To | syzop | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | unable to duplicate | ||
Product Version | 5.0.5 | ||||
Summary | 0005686: REHASH after moving ssl options results in SSL connect failures | ||||
Description | Hello, 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; } } } | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
|
I can verify after testing that on /REHASH didn't worked but it did on /RESTART |
|
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 <[email protected]> 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 https://bugs.unrealircd.org/view.php?id=5607 Or maybe it even was something else? I am too lazy to setup a public test installation with let's encrypt etc though :D |
|
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. |
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 | |
2020-07-14 15:47 | syzop | Note Edited: 0021660 | |
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 |