View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006592 | unreal | ircd | public | 2025-11-14 19:48 | 2025-11-14 21:44 |
| Reporter | bsstephan | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 6.2.1 | ||||
| Summary | 0006592: IRCD warning about the wrong TLS cert expiring, despite what is configured in use | ||||
| Description | Since upgrading my servers to 6.2.1, they have been warning at startup and on occasion that the configured cert has expired years ago, when it has not. The occasional warning, from my weechat server buffer: 11:48:17 -- [hostname]: tls.TLS_CERT_EXPIRING [warn] Warning: TLS certificate '/etc/unrealircd/fullchain.pem': certificate expired 492d2h54m19s ago Ditto if I unrealircdctl rehash: [warn] Warning: TLS certificate '/etc/unrealircd/fullchain.pem': certificate expired 492d3h9m19s ago When I connect to said server, the client connection is fine: 14:56:19 -- gnutls: receiving 2 certificates 14:56:19 -- - certificate[1] info: 14:56:19 -- - subject `CN=*.[domainname]', blah blah blah, activated `2025-11-11 18:10:19 UTC', expires `2026-02-09 18:10:18 UTC' 14:56:19 -- - certificate[2] info: ... And if I check the cert directly: bss@[hostname] ~ % sudo openssl x509 -enddate -noout -in /etc/unrealircd/fullchain.pem notAfter=Feb 9 18:10:18 2026 GMT But while checking, I realized I had the default certs as cruft in my config directory, and what do you know: bss@[hostname] ~ % sudo openssl x509 -enddate -noout -in /etc/unrealircd/tls/server.cert.pem notAfter=Jul 10 14:53:58 2024 GMT bss@[hostname] ~ % python Python 3.13.5 (main, Sep 21 2025, 23:32:29) [GCC 14.3.1 20250801] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> datetime.datetime.now() - datetime.timedelta(days=492) datetime.datetime(2024, 7, 10, 12, 15, 59, 263964) >>> bss@[hostname] ~ % sudo grep server.cert.pem /etc/unrealircd/unrealircd.conf bss@[hostname] ~ % Replacing server.cert.{pem,key} with symlinks to the files in /etc/unrealircd/ removed the error. It seems as if the expiry checker was picking up the "default" files somehow, which leads me to my next question --- at first I just nuked the server.cert.{pem,key} files in the directory, but then rehash complained that the default certificate was missing. Did I miss a step somewhere, or is there no way to point the config away from those files? | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Just a word in general. We usually recommend a dual cert approach, with a cert/key that stays the same for server linking (easy with spkifp, as used in the linking guide) and then for clients to use Let's Encrypt (a certificate issued by a trusted certificate authority). That is in this guide https://www.unrealircd.org/docs/Using_Let's_Encrypt_with_UnrealIRCd The default cert/key is used indeed, unless you set set::tls::certificate (and ::key) otherwise. You can also override on a listener / link block basis with tls-options, but if set::tls::certificate is not changed then it will use the default cert, yeah. Oh and definitely don't delete curl-ca-bundle.crt. That file contain a list of trusted certificate authorities, which is needed for like ./unrealircd module commands (the module manager) and remote includes. For times where the configuration file has not been read yet, so that one is not-so-optional :D. Anyway, to the core issue: did you mean the '/etc/unrealircd/fullchain.pem' that was printed for the expired cert... was actually not the correct certificate that was expired? It was displaying the wrong filename? |
|
|
What I suggest you to do is to not use a global set::tls::certificate nor a set::tls::key and instead specify the valid cert/key on a listen block, using listen::tls-options::certicate and set::tls-options::key ( https://www.unrealircd.org/docs/Listen_block#tls-options_block_(optional) ), so your listen block becomes something like:
listen {
ip 1.2.3.4;
port 6697;
options {
tls;
clientsonly;
}
tls-options {
certificate "/path/to/fullchain.pem";
key "/path/to/privkey.pem";
}
}
That way, you can use the self-signed certs for linking using SPKIFP ( https://www.unrealircd.org/docs/Tutorial:_Linking_servers#Step_3:_grab_the_SPKI_fingerprint_of_your_servers ) and the Let's Encrypt certificates for your users. Then, you should remove the symlink you created previously. If you're using Ubuntu/Debian, I've created a set of scripts that may be useful for you here: https://gist.github.com/TehPeGaSuS/f1a27540de16d44137526c3bf69cf26d Hope this answer helps Cheers |
|
|
Your config cleanups look helpful, thanks. I tried to use different certs for the front door for clients and the S2S links (w/SPKIFP) at some point and failed, but with this info I'll try again. > Anyway, to the core issue: did you mean the '/etc/unrealircd/fullchain.pem' that was printed for the expired cert... was actually not the correct certificate that was expired? It was displaying the wrong filename? I think that's the gist of it. Due to my misleading configuration, which I assume will be resolved by your suggestions on how to clean up my TLS settings and link blocks, I thought /etc/unrealircd/tls/server.cert.pem was doing nothing and /etc/unrealircd/fullchain.pem was the only actual cert that mattered (as it was in use both for clients and S2S), but nevertheless the server was checking the default cert and rightly telling me it was expired... but the WARN was displaying the filename for the cert that was fine. |
