Encryption Troubleshooting Thread

I figured I’d make a thread for troubleshooting general issues with encryption and the new Letsencrypt functionality available in the Module Update “Edge” track of FreePBX Distro.

For me, I managed to get Letsencrypt to generate a certificate, and Chrome is giving the “green lock icon” seal of approval. In UCP, I can initiate a WebRTC phone call, but whenever I click the “dial” button, it rings for half a second and stops. Back before I upgraded the modules and got the certificate, I could tell Chrome to just add a security exception, and the WebRTC calling worked fine then.

I checked the Asterisk logs and saw this output:

After that, I found that Asterisk SIP Settings had some fields that weren’t filled out yet where I tell ChanSIP and ChanPJSIP to use the Letsencrypt certificate and to enable TLS over sslv2 and tlsv1, respectively. I then set those up, but I’m still getting that same error in the logs. Any ideas how to proceed from here?

I think there is something we need to change in the sip js libraries. I will defer to @billsimon until I can get back to a computer to test. He’s been through this more than me recently so might be able to give you a quick jump

So glad to hear let’s encrypt is working well for everything else!

In Admin - User Management, edit your user affiliated with an extension, go to the UCP tab here, then the WebRTC sub-tab. Here you need to pick the certificate.

Go to Settings - Advanced Settings, Asterisk built-in mini HTTP server section, and verify the HTTPS section is filled out, bind address :: or 0.0.0.0, port 8089, and the cert and key locations filled in.

Now a bit of hacking.

Download http://jssip.net/download/releases/jssip-0.7.23.js and put the file in /var/www/html/admin/modules/webrtc/ucp/assets/jssiplibs. Edit the file and change line 20429 where it says ws to wss. The result looks like this:

uri: new URI('sip', Utils.createRandomToken(8), settings.via_host, null, {transport: 'wss'}),

Now edit /var/www/html/admin/modules/webrtc/ucp/assets/js/global.js and change line 376. Change the version nummber to 0.7.23, like this:

ver = "0.7.23";

Changing that file will cause FreePBX to give the red warning on the dashboard about tampered files.

Let me know how it goes. I’m just retracing my steps from when I hacked this to work a few weeks ago.

Okay, let me know if there’s other logs you need from my end.

  1. I just rebooted the server and afterwards I was getting the “Unable to authenticate with the UCP Node Server” red banner in UCP for about 10 minutes. It seemed to clear up after I closed out all Chrome tabs running FreePBX. Maybe it didn’t like multiple tabs signed into the same UCP and extension.

  2. I also spent a few hours trying to get the Letsencrypt certificate running for iSymphony; that’s a bit of a nightmare because you have to convert the .crt and .key file into something called a Java Keystore. Needless to say I got stuck there after merging the two files with some OpenSSL command I found in an online walkthrough, and being told the resulting file wasn’t in a valid format. It’d be nice if they could just use the same certs in FreePBX as-is but I guess Java has it’s own required formats.

  3. As far as getting the phones to make TLS connections, I turned it on in Asterisk SIP settings, and set my Polycom phone to use TLS transport and pointed it to the 5161 TLS port, but it fails to connect to that even after a server reboot. My settings look like this on the FreePBX side, maybe there’s more I’m missing:


I checked User Management and it looks like it already set the Letsencrypt certificate without my intervention there. Unless it’s just showing me that it’s found the only valid one, and I still have to hit apply? I hope I wouldn’t have to do that with every user though. Anyway, here’s how it looks on my screen:

These are my Asterisk Mini HTTPS settings:

And my UCP Node settings:

I followed your instructions to download the jssip file to the directory you specified, and then edited it’s line and the line in global.js, then I rebooted the server again.

Every server reboot seems to take the UCP out of commission with the " “Unable to authenticate with the UCP Node Server” red banner. I think it goes away if I try to do a WebRTC call anyways.

After all that, I’m still getting the same error and log outputs:

Have you upgraded all modules. Ucp node was fixed a few days ago.

All this occurred on UCP Node Server 13.0.26

I do see on the edge track that there’s now “13.0.27: Better logging on failed starts” so I guess it won’t hurt to load that up.

Monitor

/var/log/asterisk/ucp_out.log

Paste Results here.

Okay, each time I refresh the UCP page, it gives me the “Unable to authenticate with the UCP Node Server” red banner, and the log output tells me that a token from the IP I’m viewing the page from was rejected:

I do have that IP set as “internal” in the Sangoma Firewall if that makes any difference. The UCP is allowed to contact “internal”.

I should mention, when I first installed the Letsencrypt-centric upgrades, I added two custom services entries to the Firewall for ucp/tcp ports 8003 and 8089, since I didn’t see them mentioned at all in “/admin/config.php?display=firewall&page=about&tab=services”

That’s OK for me to do, right? I assumed it was an oversight since these features are brand new, so you didn’t have time to build the secure ports in the default Firewall entries.

None of this matters right now.

Your token is getting rejected because you are coming from a different IP than wen you logged in. It shouldn’t suddenly start working again unless your system is very very slow.

Oh, crap. Well, we use a load balancing router which spreads our outbound connections across three different ISPs. The three you see there, .140, .30, and .18 are what we have. That explains why the red banner was seemingly going in and out at random.

I can configure session persistence so that the router will try it’s best to keep people to the same IP when using the FreePBX services. It does session persistence by default for HTTPS, but maybe it has a blind spot for these other ports.

I’ve never seen any other apparent anomalies from the load balancing though; our SIP phones always work fine. Are there other areas I should be watching out for?

Our authentication tokens are bound by IP address. Which is why you are having the issue (along with your load balancer).

There’s been some discussion about removing the bind by IP. Maybe a setting. It’s just less secure that way and if someone steals your token then they can do whatever they want with it.

@xrobau is our resident security expert so I’ll get his opinion when he wakes up

I see. If there were a way to keep the bind by IP, but still allow exceptions for specific IPs, that’d probably be a good compromise in my use case. I’ll try the session persistence for now and see if I can fix it.

Okay, setting the session persistance did get the red banner to go away. There seems to be no authentication issues now, but I’m still getting the issue where when click dial in the WebRTC phone panel, it makes the ring noise and switches to call mode for a split second, then ceases and goes back to the number entry. Here, I clicked it four times then checked the Asterisk logs:

Yup. Thats the next error. I think it’s on our end (configuration) so going to work on that next.

I was able to partially fix this error. It registers but there is no audio. All RTP traffic is going to 0.0.0.0:9. @billsimon any ideas?

I was able to figure this out by adding a pcConfig setting to calloptions. Which then worked. I did not have to modify the js lib as Bill mentioned earlier.

Hmm. The jssip lib change I wrote about earlier had to do with the way Asterisk requires “;transport=wss” on the SIP URI even though this is technically not correct syntax. I don’t see how these things are related. More research needed. :slight_smile:

edit: Oh, it might be a difference between chan_sip and pjsip. I’m using chan_sip.

I realize that but I am having 100% success without having to do that. I’m using chan_sip as well.

Asterisk seems to not require “;transport=wss” it’s working fine with “;transport=ws”

certman v13.0.16
webrtc version 13.0.18

Should have you going but there might be glitches. You might have to resave the devices. I have not checked this 100% yet.