It wasn’t all tenants. Only 2.
We simply renewed the certficate at let’s encrypt, which we naturally do perodically, but it is the first time that I see TLS errors when an agent is trying to register their WebRTC.
We do however see periodic SSL errors, but I assume that these are caused by port scanners.
It is just a guess that it could be related to the allow_reoad change for the TLS transport.
As said in worked again after a restart of Asterisk, so I am just trying to find possible reasons.
WebRTC uses the HTTPS web server in Asterisk, the TLS transport and allow_reload have no effect on it. Since only 2 are impacted, it is more likely something to do with the TLS certificate such as a root authority no longer being valid and the systems in question not having up to date root certificates. You would need to examine the actual TLS negotiation, easiest being to just try to go to the Asterisk web server on a failing system and seeing what the browser says. Secondly a packet capture looking at the TLS negotiation can someones show problems.
I just got informed that our certificate actually was expred, and has now been replaced with a new one.
WebRTC is working fine, and outbound INVITEs via TLS are working as well.
We however do not receive inbound INVITEs via TLS when we are calling the assignhed numbers.
In these cases we donot see an SSL error.
I assume that it will work again if I restart.
Do you know another method to force Asterisk to reload the certificate, so we won’t loose the ongoing outbound calls?
Are you using PJSIP? That’s what I was assuming, if not then I don’t know the chan_sip behavior. You can also always use the openssl CLI command to see the details of a certificate: