[asterisk-bugs] [JIRA] (ASTERISK-26604) chan_sip: sip reload doesn't apply changes to tlscertfile, tlsciphers, etc.

[George Joseph (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

George Joseph updated ASTERISK-26604:
-------------------------------------

    Target Release Version/s: 13.14.0

> chan_sip: sip reload doesn't apply changes to tlscertfile, tlsciphers, etc.
> ---------------------------------------------------------------------------
>
>                 Key: ASTERISK-26604
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26604
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/TCP-TLS
>    Affects Versions: 13.12.2, 14.1.2
>            Reporter: Michael Kuron
>            Assignee: Michael Kuron
>            Severity: Minor
>      Target Release: 13.14.0
>
>
> {{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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)