[Home]

Summary:ASTERISK-26604: chan_sip: sip reload doesn't apply changes to tlscertfile, tlsciphers, etc.
Reporter:Michael Kuron (mkuron)Labels:
Date Opened:2016-11-15 15:52:03.000-0600Date Closed:2016-12-02 07:15:41.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/TCP-TLS
Versions:13.12.2 14.1.2 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Attachments:
Description:{{sip reload}} currently doesn't apply changes made to {{tlscertfile}}, {{tlsciphers}}, or any of the other TLS-related _sip.conf_ parameters unless {{tlsbindaddr}} was also changed. This means that, in order to replace the SSL certificate, you need to perform {{module reload chan_sip}}, thus disconnecting all current SIP connections.

_main/tcptls.c_ contains an explicit check for whether the bind address was changed and if it wasn't, it skips closing the old socket and creating a new one. Removing this check for TLS would solve the problem. Alternatively, one could store all TLS-related parameters inside {{ast_tcptls_session_args::tls_cfg}} and compare whether they have changed, but this would add half a dozen or more strings to that struct. Also, we would need to additionally store a hash or last-modified time stamp of all files loaded ({{tlscertfile}}, {{tlsprivkey}}, etc.) as they may have changed on-disk but still be the same file. I am not aware of any negative implications of simply unconditionally restarting the TLS socket, however.

If this problem was fixed, one could replace an SSL certificate without impacting established connections. This is particularly useful in environments using Let's Encrypt, where the certificate needs to be replaced every other month and one typically automates that process.
Comments:By: Asterisk Team (asteriskteam) 2016-11-15 15:52:04.289-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Friendly Automation (friendly-automation) 2016-12-02 07:15:42.586-0600

Change 4450 merged by Joshua Colp:
tcptls: Use new certificate upon sip reload

[https://gerrit.asterisk.org/4450|https://gerrit.asterisk.org/4450]

By: Friendly Automation (friendly-automation) 2016-12-02 07:41:23.991-0600

Change 4449 merged by zuul:
tcptls: Use new certificate upon sip reload

[https://gerrit.asterisk.org/4449|https://gerrit.asterisk.org/4449]

By: Friendly Automation (friendly-automation) 2016-12-02 07:57:25.630-0600

Change 4448 merged by Joshua Colp:
tcptls: Use new certificate upon sip reload

[https://gerrit.asterisk.org/4448|https://gerrit.asterisk.org/4448]