#1216 "prosodyctl reload" doesn't clear cache or revalidate connections on cert change
Reporter
shh
Owner
Nobody
Created
Updated
Stars
★ (1)
Tags
Priority-Medium
Type-Defect
Status-Invalid
shh
on
Hello,
I'm using prosody 0.10.2-1~stretch1 with latest Conversations 2.2.9 clients and a cert signed domain by letsencrypt.
Some weeks ago, I created new letsencrypt certs and used "prosodyctl reload" afterwards.
This worked for clients to be able to reconnect to prosody and continue chatting.
However, the cache was faulty, because when I wanted to send an old GIF again, the cache seemed to hit and tried to reuse the old, but now obsolete cert/connection resulting in TLS connection errors because of the cert timeout.
"prosodyctl restart" helped to solve this issue. I think this cleans the cache uses the new cert from now on.
I think "prosodyctl reload" should also clean the cache from old objects from obsolete TLS connections.
Perhaps prosody should compare prev and next certs: if they're the same clear cache, otherwise keep it (or something like that).
Zash
on
Hello, thanks for the report.
Are you trying to say that HTTPS certificates are not reloaded?
This is known, currently only certificates for XMPP/STARTTLS are reloaded on `prosodyctl reload`.
As a work-around, mod_http can be reloaded (must be a global reload) using either the telnet console or ad-hoc commands.
Changes
tags Status-NeedInfo
shh
on
Hello Zash!
> Are you trying to say that HTTPS certificates are not reloaded?
No, I'm not.
If I replace certificates and don't tell prosody anything, the certs expire and clients aren't able to connect and post anything afterwards.
Current settings are:
c2s_require_encryption = true
s2s_require_encryption = true
s2s_secure_auth = true
Thus I used "prosody reload" after a cert change in order to reload https certificates.
This works as far as clients were able to reconnect to the server and post stuff again.
The cache, however, doesn't seem to be cleared on "reload": If clients post cached items, the old cert or connection parameter was used (since posting limit was 512KiB and the file was 496KiB, it *could* be that mod_http was used).
It seems that connection parameters in conjunction with the old certificate still seem to be upheld after "reload" - what shouldn't be.
Zash
on
I have no idea what "cache" is referred to.
shh
on
Interesting, Zash, because you already answered and didn't mention that (so you probably didn't even read my first report, I somehow solved myself?).
But phrasing "cache" isn't important for fixing, because as you can read: It is somehow just necessary to restart prosody to *completely* update certificates - besides it should currently not be necessary due to the documentation of "prosody reload".
Lunar
on
ssh: If you create a new certificate 'prosodyctl reload' isn't going to have mod_http use that new certificate. You may also need to reload mod_tls as well for it to start using the new certificate.
Hello, I'm using prosody 0.10.2-1~stretch1 with latest Conversations 2.2.9 clients and a cert signed domain by letsencrypt. Some weeks ago, I created new letsencrypt certs and used "prosodyctl reload" afterwards. This worked for clients to be able to reconnect to prosody and continue chatting. However, the cache was faulty, because when I wanted to send an old GIF again, the cache seemed to hit and tried to reuse the old, but now obsolete cert/connection resulting in TLS connection errors because of the cert timeout. "prosodyctl restart" helped to solve this issue. I think this cleans the cache uses the new cert from now on. I think "prosodyctl reload" should also clean the cache from old objects from obsolete TLS connections. Perhaps prosody should compare prev and next certs: if they're the same clear cache, otherwise keep it (or something like that).
Hello, thanks for the report. Are you trying to say that HTTPS certificates are not reloaded? This is known, currently only certificates for XMPP/STARTTLS are reloaded on `prosodyctl reload`. As a work-around, mod_http can be reloaded (must be a global reload) using either the telnet console or ad-hoc commands.
ChangesHello Zash! > Are you trying to say that HTTPS certificates are not reloaded? No, I'm not. If I replace certificates and don't tell prosody anything, the certs expire and clients aren't able to connect and post anything afterwards. Current settings are: c2s_require_encryption = true s2s_require_encryption = true s2s_secure_auth = true Thus I used "prosody reload" after a cert change in order to reload https certificates. This works as far as clients were able to reconnect to the server and post stuff again. The cache, however, doesn't seem to be cleared on "reload": If clients post cached items, the old cert or connection parameter was used (since posting limit was 512KiB and the file was 496KiB, it *could* be that mod_http was used). It seems that connection parameters in conjunction with the old certificate still seem to be upheld after "reload" - what shouldn't be.
I have no idea what "cache" is referred to.
Interesting, Zash, because you already answered and didn't mention that (so you probably didn't even read my first report, I somehow solved myself?). But phrasing "cache" isn't important for fixing, because as you can read: It is somehow just necessary to restart prosody to *completely* update certificates - besides it should currently not be necessary due to the documentation of "prosody reload".
ssh: If you create a new certificate 'prosodyctl reload' isn't going to have mod_http use that new certificate. You may also need to reload mod_tls as well for it to start using the new certificate.
> I somehow solved myself? Ok, thanks. Closing
Changes