I have made sure the hostname in the pem file is the same as the tlsbind address.
However when I reload/restart asterisk and run netstat asterisk is never listening on the tls port. When I setup tcp or udp they seem to work. There is no logging in the CLI even with debug set to 10. Can anyone suggest a way of getting to the bottom of this.
Mhm, facinating because there should be a warning or even an error on the console. If you control the source code, you could add ‘ast_log(LOG_NOTICE, “\n”);’ in the file channels/chan_sip.c, just before ‘ast_tcptls_server_start’ is called. Then you go for ‘sudo make install’ on your Terminal. If that notice is not shown/reached, do the same just before ‘ast_ssl_setup’.
Which Linux distribution do you use? Which version of OpenSSL comes with it?
If you do not specify ‘tlsbindaddr’, Asterisk re-uses ‘bindaddr’, which defaults to ‘0.0.0.0’. Or do you have several interfaces on your server and Asterisk should use a specific interface?
Do you have only a single general section in your configuration file ‘sip.conf’?
As a side-note: Use tlsclientmethod only if you have to disable TLS 1.2. Avoid tlscipher=ALL because that enables anonymous and insecure cipher suites. Either do not specify tlscipher at all (then Asterisk uses $ openssl ciphers -v DEFAULT) or go for ‘tlscipher=AES128-SHA’ (which every SIP-over-TLS client has to support).
Hi, Thanks for the reply and advice. We use Ubuntu 16.04. It comes with openssl 1.02g. We’ll make that addition to the code, rebuild and come back. Indeed there is no error message at all which seemed really strange. We are just trying to get the tls interface going at present so have disabled all others. Yes we only have one [general] section in sip.conf.
We used the 172.31.34.207 address as the tlsbindaddr as that is what is the hostname of the server certificate we created , we don’t have any other interfaces on our server.
Mhm. I am using Asterisk, SIP-over-TLS, Ubuntu 16.04 LTS, and its OpenSSL as well. No issues here.
Therefore, please, insert those log statements, so the culprit can be found. Your findings might result in a better warning message in Asterisk, because there should be some kind of notice. Furthermore, please, try without ‘tlsbindaddr’ because then Asterisk is using the current/correct IP address automatically. If you want to enable IPv6 beside IPv4 (Dual Stack), you go for ‘bindaddr=::’. However, in that case, you should go for a certificate not with an IP but a domain name. For example, the certificates of Comodo are rather cheap…
If the control flow does not reach ast_ssl_setup at all, one way is to add more ast_log statements, before this is called. That way, you can find the place where Asterisk goes for another path in source code then expected. It can be time consuming task, I know, but this is the approach I would doing in a case like yours.
Another way is to run Asterisk with a debugger like GDB… that way you can break/step/next through the code without recompiling.
Yes I did that now and finally got to the bottom of it. I didnt have SSL compiled into my Asterisk build which I had several months ago. So when the setup function is called it silently exits. Should really be a warning there.
main/tcptls.c
static int __ssl_setup(struct ast_tls_config *cfg, int client)
{ #ifndef DO_SSL
cfg->enabled = 0;
return 0; #else
./configure --with-crypto --with-ssl --with-srtp
I needed to the above to get SSL support. I assumed it was default to be honest. Thanks for all your help, everything working great now.
Yes, there is a bug. As side-effect, __ssl_setup resets the value of enabled to null. Because of that, the SIP channel driver chan_sip does not emit its warning, after trying ast_ssl_setup. I look into that.
However, I am curious about your issues with configure as well. OpenSSL and libSRTP are auto-detected by Asterisk on Ubuntu 16.04 LTS. At least they should. When you run just ./configure without those parameters, what do you see when OpenSSL and libSRTP are tried to be detected?
checking for openssl/ec.h… yes
checking for SSL_OP_NO_TLSv1_1 in openssl/ssl.h… yes
checking for SSL_OP_NO_TLSv1_2 in openssl/ssl.h… yes
checking for srtp_init in -lsrtp2… no
checking for srtp_init in -lsrtp… yes
checking srtp/srtp.h usability… yes
checking srtp/srtp.h presence… yes
checking for srtp/srtp.h… yes
checking for the ability of -lsrtp to be linked in a shared object… yes
checking for crypto_policy_set_aes_cm_256_hmac_sha1_80 in -lsrtp… yes
checking for crypto_policy_set_aes_cm_192_hmac_sha1_80 in -lsrtp… no
checking for crypto_policy_set_aes_gcm_128_8_auth in -lsrtp… no
checking for srtp_shutdown in -lsrtp… yes
checking for srtp/srtp.h… (cached) yes
Mhm. Looks good. What do you think – is it possible that the packages libssl-dev and libsrtp0-dev were not installed when you configured Asterisk, the last time, before you opened this thread. I am curious, because here Asterisk is able to find those packages on a vanilla Ubuntu 16.04 LTS installation automatically.
Hi, yes its possible as I installed asterisk 14.6.1 a couple of months before posting here and was just using UDP. In the meantime I installed all sorts of packages so maybe the ssl and srtp got installed after the initial configure of asterisk. So the second time I did the configure with the extra params (./configure --with-crypto --with-ssl --with-srtp) it picked them up, and would have done even without the extra params.
OK. I reported your initial issue via ASTERISK-27394 and added your idea about a warning message for review in Gerrit-6998. Thanks for keeping up with the issue. I am sure your report and that change is going to help other users, to avoid that pitfall.