Secure SIP with REAL certificate

[Prometheus DBA]

Hi,

I try to implement secure SIP but the only thing I can find about this is the link below from 2010, on some old 3CX version and using a selfsigned certificate. Is there an up-to-date (Version 15) manual on how to implement secure SIP with and official SSL certificate?

https://www.3cx.com/blog/voip-howto/secure-sip/

Greets,

 

[NetVu IT]

Turning on TLS is relatively simple but getting it to work is a bugger. To start with visit https://yourserver/#/app/settings/security/4/secure_sip and check the enable option. Paste your CA signed certificate into the top box and then your certificate key (Note: it's mislabelled API key) into the bottom box, save that and restart your SIP services. That should be it.

This is where I run into issues. I've been trying to get the Android 3CX Client to connect, but no way can I get it to register. So I tried Linphone to check all was okay. It wasn't, as this seems to issue an [RST, ACK] after receiving the certificate, causing the server to drop the connection.
Next up I tried Zoiper and as far as I can tell this is working fine. I see the expected flow of TCP & TLSv1.2 traffic to port 5061.
I've yet to try the 3CX client on my PC as I've got that configured against my live server; but I've got a shipment of Snom D315 handsets hopefully arriving today, so I'll give one of them a whirl.

Edit: Okay, seems I can have TLS on RTP, but not on SIP. If I set TLS for SIP transport it fails on the Windows client.

 

[Prometheus DBA]

Hi NetVu,

You say, "Turning on TLS is relatively simple but getting it to work is a bugger. To start with visit https://yourserver/#/app/settings/security/4/secure_sip and check the enable option. Paste your CA signed certificate into the top box and then your certificate key (Note: it's mislabelled API key) into the bottom box, save that and restart your SIP services. That should be it.".

Do you know if I can use the same crt and key files I find in the nginx config?

You say TLS on RTP works but SecSIP does not, but I cant even find the RTP over TLS option in 3CX. Can you point me to the right direction please?

 

[NetVu IT]

Yes, it appears you're able to use the same certificate, or at least it's let me. It doesn't validate it on saving, so there's no way of telling if has been accepted. Also, having just checked, my server seems to have dropped the certificate files after a reboot.

The options themselves are specified via provisioning (e.g. https://server/#/app/extension_editor/11/phone_provisioning) or in the 3CX Client. You're looking for SIP Transport (UDP | TCP | TLS) and RTP Mode (Normal | Allow Secure | Only Secure). In the 3CX client these are under: Configure Accounts | Account Name | Advanced Settings.

 

[Prometheus DBA]

Hi NetVu,

You are absolutely right! SecSIP and RTP over TLS s*cks. It does not work on the 3CX App (Internal and External). And the thing that bugs me most is that every piece of this puzzle is at another place... @3cx please fix this ASAP so calls can be made secure

Thank you for you help!

 

[NetVu IT]

Had a bit of an realisation last night. There are two different connection settings in the 3CX Client; one for In Office and the other for Out of Office. The reason I couldn't get Secure SIP running is that the In Office setting defaults to the IP address rather then the FQDN so, of course, the certificate isn't valid due to name mismatch. I think it should be as simple as adjusting the 3CX parameters ending in _SEC to use the FQDN. I'll test it when I get a moment and post the results.

Edit: Okay, it's not that simple. It looks like it's being set up via the provisioning template, but I've no idea how to edit the 3CX Client provisioning template. Anyone point me in the right direction?

Edit 2: Got it! On the provisioning page under the user's extension change 'Network interface for registration and provisioning' from the IP address of the server to the FQDN. Enabling SIP TLS now works for me. Well, that seemed to be harder than it should have been.

 

[Prometheus DBA]

Well, that part seemed no problem for my configuration as my internal and external FQDN are the same on all my clients. SecSIP seemed to be working, but RTP over TLS (encrypted speach) is where I struggle.

 

[NetVu IT]

I did the same with the FQDN as I couldn't figure out an easy way of presenting a valid SSL certificates for internal and external traffic.
I've not had any issues with Secure RTP as that seems to just accept all certificates, even when I'd entered the CA's certificate rather than the key. It was simply a case of setting RTP Mode provisioning to Only Secure. What's happening with your RTP?

 

[Prometheus DBA]

Ok I think I found something that works for me. My external connections all use SecSIP and SRTP now. Internally they do not. This is acceptable for my situation. Below are the staps I did;

1. I went to my 3CX server > Trunks > MyTrunk> Options, and checked the SRTP option.
2. In my 3CX server > Settings > Security > Secure SIP, and filled in the certificate information as it is used in the 3CX web server.
3. In the web portal of my trunk provider I forced encryption.

To see if all above worked, I started wireshark on my 3CX server and I clearly see all traffic between my 3CX server and the trunk provider is encrypted (Secure SIP and SRTP). Internally, between phone and 3CX server it is just unencrypted.

 

[Prometheus DBA]

In addition to my reply. I couldn't let it go, so I tried again to make the 3CX IOS Client work with Secure SIP and SRTP, but the 3CX IOS Client just won't register with these settings. The ports are not blocked in my firewall, I can see them being allowed in my firewall. Also I see the packets in wireshark arriving on the 3CX server. but nothing happens.

So I put the 3CX IOS Client settings back to SIP on UDP and normal RTP. @3cx, this is a BUG please fix this.

 

[YiannisH_3CX]

Hello @Prometheus DBA

Kindly note that on IOS and android clients, secure sip in not implemented. It can only be used with ip phones and Windows clients.
So in reality this is not a bug because it was never meant to work in the first place
You can post this as a features request to our ideas section of the forum so other users can upvote this.